IPerf Test Case
- Former user (Deleted)
- WES Admin
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 the figure below, 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:
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.No Retransmission
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 the listing below, and can be found in net_cfg.h.
Net Configuration: #define NET_DBG_CFG_INFO_EN DEF_DISABLED #define NET_DBG_CFG_STATUS_EN DEF_DISABLED #define NET_DBG_CFG_MEM_CLR_EN DEF_DISABLED #define NET_DBG_CFG_TEST_EN DEF_DISABLED #define NET_ERR_CFG_ARG_CHK_EXT_EN DEF_DISABLED #define NET_ERR_CFG_ARG_CHK_DBG_EN DEF_DISABLED #define NET_CTR_CFG_STAT_EN DEF_DISABLED #define NET_CTR_CFG_ERR_EN DEF_DISABLED #define NET_IF_CFG_LOOPBACK_EN DEF_DISABLED #define NET_ICMP_CFG_TX_SRC_QUENCH_EN DEF_DISABLED
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.
The listing below shows an example of task priorities and stack sizes for a typical device performance measurement application.
/* ********************************************************************************************** * TASK PRIORITIES ********************************************************************************************** */ #define IPERF_OS_CFG_TASK_PRIO 11u #define APP_TASK_START_PRIO 13u #define NDIT_TASK_TERMINAL_PRIO 15u #define NDIT_TASK_MULTICAST_PRIO 12u #define NDIT_TASK_SERVER_PRIO 16u #define NET_OS_CFG_IF_TX_DEALLOC_TASK_PRIO 2u #define NET_OS_CFG_TMR_TASK_PRIO 15u #define NET_OS_CFG_IF_RX_TASK_PRIO 18u #define NDIT_MCAST_TASK_PRIO 20u /* ********************************************************************************************** * TASK STACK SIZES * Size of the task stacks (# of OS_STK entries) ********************************************************************************************** */ #define APP_TASK_START_STK_SIZE 128u #define NDIT_TASK_TERMINAL_STK_SIZE 512u #define IPERF_OS_CFG_TASK_STK_SIZE 512u #define NDIT_TASK_SERVER_STK_SIZE 512u #define NDIT_MCAST_TASK_STK_SIZE 512u #define NET_OS_CFG_TMR_TASK_STK_SIZE 512u #define NET_OS_CFG_IF_TX_DEALLOC_TASK_STK_SIZE 128u #define NET_OS_CFG_IF_RX_TASK_STK_SIZE 512u