IPerf Test Case

IPerf Test Case

Once the target answers to ping requests on a switched network, you should perform additional IPerf tests with the target connected directly to the test station, and on a network. It is best to perform standard tests, and log the results into a device driver test result document.

Buffer leaks

For each IPerf test, make sure that your driver does not have any buffer leaks. If the driver performance decrease over time, or if the driver suddenly stops, you might have a buffer leak.

Buffer leaks can happen in many cases. The root cause of a buffer leak is when the program loses track of memory allocation pointers. Assigning a newly allocated buffer to a pointer without deallocating the previous memory block that the pointer associated with will also cause a buffer leak. If no other pointer refers to that memory location, then there is no way it can be deallocated in the future, and that memory block will remain unusable unless the system is reset.

Transmit buffer leaks can be detected by having the target transmit a large buffer to the test station using TCP. A good example would be an FTP test. If a given buffer is not transmitted because it has leaked, the test station will request its retransmission by the target. This operation should fail since the leaked buffer is lost.

In Figure 8-6, the test station (192.168.5.110) requests the retransmission of a lost segment and the target (192.168.5.217) fails to retransmit it:

1. 1. Transmission Buffer Leak Example

No retransmission

Retransmissions should never happen unless they are requested by the communication protocol. Erroneous retransmissions can happen if a transmitted buffer remains assigned to a descriptor, and the buffer is not deallocated.

While performing performance tests on the target, you should use Wireshark or another packet capture tool to monitoring the trafic. Unrequested packets retransmission can be detected by searching for frames marked with “[This frame is a (suspected) retransmission]” in Wireshark.

Advertised window size

The total memory available for the reception buffer should always be equal to or greater than the window size advertised by the target. If it is not the case, the test station might send too many packets before waiting for an acknowledge message, and the target might lose packets. Loosing those packets will trigger a retransmission of the lost packets, and thus slow down the data transfer.

Performance results

You should log your driver performance in the driver document. This document is used as a reference for support requests, so it’s very important to log performance when you write or update a driver. The performance data that you should log is described in the following sections.

Certain TCP/IP features reduce performance, so you should disable these features before logging the results. The µC/TCP-IP configuration switches for these features are shown in Listing 8-5, and can be found in net_cfg.h.

1. 1. Net Configuration for optimal performances

Task Priorities

In order to obtain the best possible performance for your tests, you should use appropriate task priorities.

When setting up task priorities, we recommend that tasks that use μC/TCP-IP’s services be given higher priorities than μC/TCP-IP’s internal tasks. However, application tasks that use μC/TCP-IP should voluntarily relinquish the CPU on a regular basis. For example, they can delay or suspend the tasks, or wait on μC/TCP-IP services. The purpose is to reduce starvation issues when an application task sends a substantial amount of data.

We recommend that you configure the network interface Transmit De-allocation task with a higher priority than all application tasks that use μC/TCP-IP network services; but configure the Timer task and network interface Receive task with lower priorities than almost other application tasks.

Listing 8-6 shows an example of task priorities and stack sizes for a typical device performance measurement application.

1. 1. Example of task priorities and stack sizes