<-  Overview Network Tools   |   Table of Contents   |   Network Monitoring Tools  ->

Network Test Tools

In this section the proposed TCP and UDP performance test tools are described that has been used. In general these are programs written in the C language and / or C++. The tools, described in the following subsections, have been used. Also the modifications, when applied, are mentioned there.

Netperf

Description

The Netperf tool is in principle a TCP and UDP benchmark. However, no shaping algorithms have been implemented. Therefore, the value of the UDP test type is limited, because due to the lack of shaping, the sender will often overflow the receiver, because sending is more easier than receiving. In fact various TCP and UDP traffic types can be defined. See the manual for more information.

The Netperf toolkit consists of two components:

netserver
The network performance benchmark server.
netperf
The network performance benchmark client.

In fact netserver is a true server in the sense that all relevant data should be specified via the netperf client. This feature makes netserver also suited to be started from the Unix inetd net services daemon, such that in principle all security features, supplied by the TCP wrapper tool, are also in effect here.

Between the netserver daemon and the netperf client always two socket connections will be opened:

The advantage of this procedure clearly is that the netserver daemon can be completely controlled by the netperf client. However, the disadvantage is that it is not possible to specify directly the port of the data socket which may be for instance a disadvantage for port-based TOS-bit settings.

When desired also IPv6 support can be enabled during the Netperf compilation. To be able to do this, it is required that the getaddrinfo() system calls are supported at your system.

Modifications

To Netperf Version 2.2p12 the most important following modifications have been executed:

Download

Installation

After unpacking the tar-gzip archive the appropriate directives in the makefile, contained in the archive should be edited. Concerning these make directives, there is one remark to me made: the netserver program uses a log file that is defined in the LOG_FILE directive. Default that file is located in the /tmp directory. However, that implies that one user is blocking the usage of netserver for all other users, because they are not allowed to overwrite the log file opened by the first user. Therefore, a better strategy in this situation is to use a user dependent log file. When used from inetd, the default log file is fine.

Runtime Example

In the following example a TCP stream test has been defined from host gwgsara3 to host gwgsara2 with a duration of 10 seconds and with 256 Kbyte socket and buffer sizes. The server is listening at port 22113. All options besides the port option are specified at the client. The socket and windows sizes options are stream type specific and should therefore be specified after the argument --.

Start the server at host gwgsara2:

gwgsara2[12:06]~:110> netserver -p 22113
Starting netserver at port 22113

Start the client at host gwgsara3:

gwgsara3[12:06]~:104> netperf -H gwgsara2 -p 22113 -l 10 -- \
?                             -m 256K,256K -M 256K,256K \
?                             -s 256K,256K -S 256K,256K
TCP STREAM TEST to gwgsara2
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

524288 524288 262144    10.00     718.62

Iperf

Description

Also the Iperf tool is a TCP and UDP benchmark. Because shaping has been implemented in Iperf, the tool is also usable for UDP. A.o. other protocols also Multi-Cast has been supported. See also the User Docs for more information

In contradiction to Netperf, the Also the Iperf toolkit consist of a combined server / client program named iperf. This implies that, in contradiction to Netperf, the server site options should be specified directly to the server version of the program. All server oriented output will not send back to the client either, but remain at the server console. This also implies that only a test socket will be opened and no control socket.

This approach has the advantages that:

However, there are also some disadvantages:

Dedicated scripts have been developed to deal with these problems. They are suited to be used in automated tests.

Iperf also supports the following features that Netperf does not have:

Modifications

To Iperf Version 1.7.0 (with IPv6 support) a.o. the following changes have been made from which some are extensions of the functionality and others are bug fixes:

Download

Runtime Example

In the following example a TCP stream test has been defined from host gwgsara3 to host gwgsara2 with a duration of 10 seconds and with 256 Kbyte socket and buffer sizes. The server is listening at port 22113. The server options should be specified here also at the server. Also the output is listed at the server host gwgsara2.

Start the server at host gwgsara2:

gwgsara2[17:46]~:101> iperf -s -p 22113 -l 256K -w 256K
------------------------------------------------------------
Server listening on TCP port 22113
TCP window size:  512 KByte (WARNING: requested  256 KByte)
------------------------------------------------------------
[  6] local 145.146.0.1 port 22113 connected with 145.146.0.2 port 41871
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0-10.0 sec   882 MBytes   740 Mbits/sec

Start the client at host gwgsara3:

gwgsara3[17:46]~:101> iperf -c gwgsara2 -p 22113 -l 256K -w 256K
------------------------------------------------------------
Client connecting to gwgsara2, TCP port 22113
TCP window size:  512 KByte (WARNING: requested  256 KByte)
------------------------------------------------------------
[  3] local 145.146.0.2 port 41871 connected with 145.146.0.1 port 22113
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   882 MBytes   739 Mbits/sec

UDPmon

Description

The UDPmon toolkit consists of several programs used for investigating the end-to-end performance of networks. The programs use the socket interface in a simple way and do not require root privileges. They are usually used in server - client pairs.

For our set of network test tools we are especially interested in the udp_bw_resp / udp_bw_mon combination which gives and estimate of the bandwidth found in the route between two end nodes, using a large number of UDP packets.

Below a citation follows from the description of the UDP bandwidth measurements by R.E. Hughes-Jones where the functionality of these two programs has been explained.

With these two programs the bandwidth of the bottleneck, or the network section that limits the bandwidth in the route between the test nodes may be determined by measuring the times taken to send and receive a burst of frames send from a requesting node to a responding node.

The test uses UDP/IP frames. The tests starts with the requesting node sending a "clear statistics" message to the responder. On reception of the OK acknowledgment, the requesting node sends a series of "data" packets separated with a given fixed time interval between the packets. At the end, the requesting node asks for the statistics collected by the responding node. Packet loss for the control messages are handled by suitable time-outs and retries in the requesting node. The transmit throughput is found using the amount of data sent and the time taken; the receive throughput is calculated from the amount of data received and the time from the first data packet to the last data packet received.

Packet loss is measured by the remote or responding node by checking that sequence numbers in the packets increase correctly, this also detects out-of-order packets. The numbers of packets seen, the number missed as indicated the sequence number check, and the number out-of-order are reported at the end of each test.

So far the citation.

Modifications

To the udp_bw_resp and udp_bw_mon programs from the UDPmon toolkit, some modifications have been add that will also partly be supported in future releases:

Download

The current distribution can be downloaded from the UDPmon site, maintained by R.E. Hughes-Jones.

Runtime Example

The characteristics contained in the time-stamp information can be nicely demonstrated in graphical form. In the plot listed below, the receiving time relative to the first packet has been plotted as function of sequence number of the packet for 5000 UDP packets from host gwgsara3 to host gwgsara5. The packet size was 1200 byte. When a packet got lost its receiving time was set to zero. From this plot there follows that about the first 2400 packets have been received without lost, while the linear line is indicating that these packets were arriving with about the same relative arrival time after the previous packets. After the first 2400 packets there were packets getting lost, presumably because the critical available amount of memory in the network could not buffer the packets anymore. In the document, from which the plot below has been taken, this property has been used to make an estimation of this critical available amount of network equipment memory.

Time seq. gwgsara3 => gwgsara5 (1200 byte)
The relative receiving time as function of the packet sequence number for the UDP stream gwgsara3 => gwgsara5. The packet size was 1200 byte.


<-  Overview Network Tools   |   Table of Contents   |   Network Monitoring Tools  ->