Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »

The first IPerf test you should perform is UDP transmission. Your target must be able to transmit UDP packets reliably and with acceptable throughput. Also, your target must be able to transmit packets that have the maximum UDP packet length, which is 1472 bytes (make sure to have the correct Transmit buffer size).

Test: Transmit UDP packet (1472 bytes) using NDIT

Selecting the UDPc test tab in the main NDIT window. The UDPc test tab appears:

Figure - UDPc test tab



Expected ResultsThere are three options for this test. The first is the size of the datagram (either a single 1472 or a sweep of multiple packets that are 64, 128, 256, 512, 1024 and 1472 bytes in size). The second option is the number of times the test is repeated. The third is the test duration (in seconds), which is located in the General Options tab.

  • Highest throughput possible.

    Although it is difficult to estimate the achievable throughput with a particular device, it is possible to compare with other drivers sharing roughly the same quantity of network buffers or processor speed.

    The table below shows an example of performance results for different devices and configurations:

    Development Board

    Device 1

    Device 2

    CPU Speed

    72 MHz

    70 MHz

    CPU Architecture

    ARM® Cortex-M3™

    ARM® Cortex-M4™

    Tx Buffers

    4

    3

    Tx Descr.

    4

    3

    64 byte Datagram

    Socket Call

    44253

    29994

    Throughput (Mbps)

    2.265

    1.535

    1472 byte Datagram

    Socket Call

    31245

    29991

    Throughput (Mbps)

    36.794

    35.317

    Tweaking the task priorities might help increasing the throughput out the network driver.

  • Few transitory errors.

    Transitory errors are errors that temporarily prevent the transmission of packets. Transitory errors are often recoverable. These errors include:

  • Trying to receive on a socket where the host has disconnected prematurely.
  • Trying to receive on a socket before the network initialization is completed.
  • Trying to receive on a socket that is in use by another process.

    To solve these issues, make sure that you use valid parameters for your tests. Make sure that the resources you use are still valid, and not already used by another task.

  • Ability to send packets with a size equal to the MTU.

    To find out the MTU size for your network type, enter the following command in the command shell in Windows:

    netsh interface ipv4 show subinterfaces

    The results you should get is something like this:

    Listing - netsh Subinterfaces
    Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\user01>netsh interface ipv4 show subinterfaces
       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1500                5          0          0  Wireless Network Connection
      1500                5          0          0  Local Area Connection
      1500                1  693970658   90284509  Local Area Connection 2



    In the above example, the MTU size is set to 1500 for all the network interfaces. For this reason, we use 1472 bytes as the length for the payload in our UDP test. Since the MAC-IP-UDP headers account for 28 bytes that leaves 1472 bytes left for the payload.

    In subsequent TCP tests, we use a value of 1460 or multiple of that value to set buffer sizes, window sizes, and so on. Since the size of the TCP header is slightly larger than the UDP header, this yields a smaller payload.

  • Comparable results for the target directly connected, or on a network.
  • No buffer leaks.

    See IPerf Test Case for more details.

  • Logging performance results (with the target directly connected, and networked).
  • No labels