...
| Table of Contents |
|---|
Along with the reception of UDP traffic, you should test your device driver for TCP traffic. The following are two tests that measure the driver performance under different conditions.
Test 1: Receive TCP Test with using NDIT
To achieve the best possible throughput, you might have to increase the number of receive descriptors and receive buffers. On the other hand, it is also possible to reserve too many buffers for reception. To find out the ideal number of descriptors and buffers, there are two things you need to measure.
...
For example, the bandwidth of a test station-target link is 32.461 Mbps as found by the Receive UDP test. The measured RTT is 0.9 millisecond. It gives us a BDP of 28315 bits (32.461 Mbps x 0.9 ms) or 3539 bytes. Rounding up this result to a multiple of the MSS value gives us 4380 bytes. If the combined size of the receive buffers cannot hold the BDP, the receive buffers must be increased in order to have optimal performances. It is important to increase the number of receive descriptors (RxDescNbr) accordingly.
| Panel | |
|---|---|
|
...
|
...
| |
|
There are four options for the TCP receive test:
Rx Window Size
The size of the receive socket window on the target host.
...
#define NET_TCP_CFG_RX_WIN_SIZE_OCTET (RxDescNbr * 1460)u
Expected Results
- Driver throughput should be optimized.
- Few transitory errors.
See the section on transitory errors on for more information.
- No retransmission.
See the section on retransmission on for more details.
- The messages “Window update”, “Zero window” and “Window probe” are acceptable.
These messages are part of a flow control mechanism that prevents the receiver from getting more packets that it can actually handle, or for the transmitter to wait indefinitely for acknowledgement to resume the transmission.
- No buffer leaks.
See section “Buffer leaks” for more details.
- Logging performance results (with the target directly connected, and networked).