Netperf and network performance measurement

Recommended for you: Get network issues from WhatsUp Gold. Not end users.

This paper firstly introduces some basic concepts and methods of network performance measurement, and then combined with the use of netperf tools, how to discuss the specific network performance test under different conditions.

Tang Kai (),

July 1, 2004

In the construction and management of a network system, we are more concerned about the availability of network, the network connectivity, and for its overall performance is often considered not much, or even taking into account the performance, but found no appropriate means to test the network performance.

When developing a web application, we will find that, in the actual network environment, network application effect is not very ideal, problems may arise in the process of the above development, may also have been due to the actual network environment bottleneck. Faced with this problem, the programmer will generally be nonplussed over sth., because do not have some network performance measurement tools.

In this paper, we introduce some basic concepts and methods of network performance measurement, and then combined with the use of netperf tools, how to discuss the specific network performance test under different conditions.

Network Performance Testing Overview

Five indicators of network performance measurement

Five indexes to measure the performance of the network is:

1. Usability

The first step in network performance test is to determine whether the network work normally, the simplest way is to use the Ping command. Through to the remote machine to send ICMP echo request and ICMP echo, waiting to receive reply to judge the remote machine is connected, the network is working.

The Ping command has very rich command options, such as -c can specify the number of sending echo request, -s can be specified for each transmitting Ping packet size.

Network equipment internal generally have multiple buffer pools, different buffer pool using different buffer size, packet are used to deal with different size(packet). For example, the switch usually has three types of packet buffer: a small packet, a class of the medium size group, there is a kind of the packet. In order to test network equipment, test tools must be sent in different size groups. The -s Ping command can be used on this occasion.

2. Response time

The Ping command echo request/reply a round trip time is the response time. There are many factors affect the response time, such as network load, network load, the broadcast storm, not the normal network equipment etc.

In the network is normal, normal response time record. When the reaction time users complain about the slow network, can be compared with the normal response time now the response time, if the two difference fluctuates greatly, can explain the network faults.

3. Network utilization

Network utilization rate refers to the network by the use of the time to the total time (that is, use the time + time) ratio. For example, although Ethernet is shared, but there can be only one message in the transmission. Therefore, at any moment, Ethernet or the utilization rate of 100%, or 0% utilization rate.

The calculation of a segment of the network utilization is relatively easy, but determined by a network of rate will be more complex. Therefore, the network test tool generally use the network throughput and network bandwidth capacity to identify performance between two nodes.

4. Network throughput

The network throughput is at a certain moment, between two nodes in the network, provide the residual bandwidth of network application.

The network throughput can help find the bottleneck in the network path. For example, if client and server are respectively connected to the respective 100M Ethernet, but if the two 100M Ethernet was connected to 10M Ethernet, then 10M Ethernet is the bottleneck of the network.

The network throughput is very dependent on the current network load conditions. Therefore, in order to get the correct network throughput, best in different time (day is different in different time, in a day or a week) were tested, only in this way can we get a full understanding of the network throughput.

Some web applications can run normally in the development process of the test, but in the actual network environment but not work (because no network throughput enough). This is because the test is in the idle network environment, does not take into account also exist in the actual network environment with a variety of network traffic other. Therefore, the network throughput is defined as the residual bandwidth is of practical significance.

5. Network bandwidth capacity

Unlike the throughput of the network, network bandwidth capacity refers to the maximum available bandwidth between two nodes of the network. This is determined by the ability of the network equipment Institute.

Bandwidth capacity test network with two difficulties: in the network there are other network traffic, how to know the maximum available bandwidth of the network; in the testing process, how the existing network traffic does not affect. Network test tool using packet pairs and packet trains technology to overcome such a difficulty.

Collecting network performance data in a manner

After determining the test index of network performance, we need to use the network test tool to collect performance data corresponding, respectively, have three kinds of access to data from the network:

1. Through the SNMP protocol directly to the network equipment acquisition, such as net-snmp tools

2. Data network performance interception related, typical of the tool is tcpdump

3. Automatically generate corresponding test data, such as the netperf tool used in


Netperf is a measuring tool for network performance, mainly for the transmission of TCP based or UDP. Netperf depending on the application, network performance testing can be carried out with different modes, namely bulk data transfer (bulk data transfer) model and the request / response (request/reponse) model. The test results of Netperf is a system able to quickly to another system to send data, and also a system capable of receiving data in a plurality of speed.

Netperf tools in client/server. Server is netserver, used to connect the listener from the client terminal, client terminal is netperf, used to initiate network test to server. Between client and server, first establishes a control connection, transfer the relevant test configuration information, and the test results; after the control connection establishment and transfer information of test configuration, between client and server will build a test connection, used to pass a special flow pattern, in order to test network performance.

The performance of TCP network

Because the TCP reliable transmission protocol can provide end to end, it is the network applications use a large number of. However, the establishment of the reliability is a price to pay. The TCP protocol to ensure the reliability of the measures, such as to establish and maintain the connection, transmitting the control data orderly will consume network bandwidth.

Netperf can simulate three different TCP flow models:

1) A single TCP connection, batch (bulk) transmission of large amounts of data

2) A single TCP connection, client /server request response transaction (transaction) mode

3) Multiple TCP connection, each connection in a request / response transaction mode

The performance of UDP network

UDP did not connect the burden, but UDP can not guarantee the reliability of transmission, so the use of UDP applications need to track each packet sent, packet and retransmits the lost.

Netperf can simulate the flow pattern of two UDP:

1) Unidirectional bulk transfer from client to server

2) Request / response transactions

The reliability of UDP transmission is not, in the use of the netperf to ensure that the send buffer size is not greater than the receive buffer size, otherwise the data will be lost, netperf will give erroneous results. Therefore, for the received packet statistics are not necessarily accurate, requires a combination of statistical packet transmission concluded.

The command line parameter Netperf

In the UNIX system, can be directly run the executable program to start netserver, can also make inetd or xinetd to automatically start the netserver.

When the netserver after server is started, the performance you can run the netperf at the client end to test network. Netperf to control the test through a command line parameter types and specific testing options. According to the range of different, the command line parameters of netperf can be divided into two categories: the global command line parameters, testing the local parameters, the use of - separated:

netperf [global options]-- [test-specific options]

Here we only explain those commonly used command line parameters, parameters of other readers can query the netperf man manual.

-H host : The specified remote operation of netserver server IP.

-l testlen: Specifies the length of time (in seconds) test

-t testname: Type test are specified, including TCP_STREAM, UDP_STREAM, TCP_RR, TCP_CRR, UDP_RR, below, each of them shows.

In later tests, netserver runs on, server and client through the LAN connection(100M Hub).

Netperf network performance test

Test batch (bulk) performance of network traffic

Bulk data transfer typical examples are FTP and other similar network application (i.e., a transmission of the entire file). According to the use of different transport protocol, data transmission is divided into TCP bulk transfer and UDP bulk transfer.


Netperf by default for TCP bulk transfer, namely -t TCP_STREAM. During the test, the netperf to the TCP netserver transmits the data packet to determine the mass, in the process of data transmission throughput:

 ./netperf -H -l 60
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec
 87380  16384  16384    60.00      88.00

The output from the netperf results, we can know some information below:

1) The remote system (server) using the size of 87380 bytes of socket receive buffer

2) The local system (client) used for socket send buffer size of 16384 bytes

3) To test the remote system to send the packet size is 16384 bytes

4) The test time is 60 seconds

5) The test results of throughput for 88Mbits/ seconds

By default, netperf to send test packet size is set to socket send buffer size used by the local system.

Partial parameters and test related TCP_STREAM mode as shown in the following table:

Parameters Explain
-s size Send the local system of socket and the receiving buffer size
-S size Send setup remote system socket and the receive buffer size
-m size Set the local system to send a test packet size
-M size Set the remote system to receive the test packet size
-D Set the TCP_NODELAY option to local and remote system socket

By modifying parameters above, changes and observe the results, we can determine what factors affect the throughput of the connection. For example, if a router due to lack of sufficient buffer space, the problem of packet forwarding, can increase the size of the test group (-m), to observe the changes in throughput:

 ./netperf -H -l 60 -- -m 2048
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec
 87380  16384   2048    60.00      87.62

Here, the test packet size was reduced to 2048 bytes, and the throughput is no big change (and the preceding example test packet size compared to 16K bytes). On the contrary, if the throughput is improved greatly, the intermediate network router buffer problem does exist.


UDP_STREAM is used for network performance testing of UDP bulk transfer. In particular, the test packet size greater than socket shall not send and receive buffer size, otherwise netperf will report error:

./netperf -t UDP_STREAM -H -l 60
udp_send: data send error: Message too long

In order to avoid such a situation, can limit the test packet via the command line parameter, or increase the socket send / receive buffer size. UDP_STREAM use the same TCP_STREAM form of local command line parameters, therefore, here you can use -m to modify the use of packet size test:

 ./netperf -t UDP_STREAM -H -- -m 1024
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec
 65535    1024   9.99       114127      0      93.55
 65535           9.99       114122             93.54

There are two lines of test data of UDP_STREAM results, the first row shows is to send a statistical local system, the throughput of netperf expression ability to the local socket packet transmission. But, as we know, UDP is unreliable transport protocol, the number of packets sent out is not always equal to the number of packets received.

The second row shows is receiving remote system, because client and server are directly connected together, and no other traffic in the network, so the local system to send the past packet was almost correct reception of the remote system, remote system throughput is almost equal to the transmission throughput of the local system. However, in the actual environment, socket buffer size of the remote system is different from the socket buffer local system size, but also because of the unreliability of the UDP protocol, receiving distal system throughput is significantly less than the outgoing throughput.

The test request / response (request/response) performance of network traffic

Another kind of common types of network traffic is used in the client/server structure in request/response mode. After each transaction (transaction), client sends a query packet small to server, server receives the request, after the return of big data. As shown below:


The test object TCP_RR is trading process of multiple TCP request and response, but they occur in the same TCP connection, this pattern appears frequently in the database application. Client database and server program to create a TCP connection, the connection of multiple transactions transfer database.

./netperf -t TCP_RR -H
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec
16384  87380  1        1       10.00    9502.73
16384  87380

Netperf output is composed of two rows. The first line shows the local system, the second row shows is that the remote system information. Transaction rate (transaction rate) is 9502.73 times / sec. Note that the request and response packet here each transaction's size is 1 bytes, not has great practical significance. The user can test the parameter related to the change of request and response packet size, parameter TCP_RR mode as shown in the following table:

Parameters Explain
-r req,resp Set the request and reponse packet size
-s size Send the local system of socket and the receiving buffer size
-S size Send setup remote system socket and the receive buffer size
-D Set the TCP_NODELAY option to local and remote system socket

By using the -r parameter, we can be of more practical significance test:

./netperf -t TCP_RR -H -- -r 32,1024
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec
16384  87380  32       1024    10.00    4945.97
16384  87380

It can be seen from the results, the request/reponse packet size increased, leading to the transaction rate decreased. Note: with respect to the actual system, the calculation of the transaction rate did not fully take into account the application transaction processing delay, so the results are often higher than the actual situation.


Unlike TCP_RR, TCP_CRR for every transaction to create a new TCP connection. The typical application is HTTP, each HTTP transaction is in a single TCP connection. Therefore, because of the need to constantly create new TCP connection, and at the end of the transaction after the removal of the TCP connection, exchange rate will be affected.

./netperf -t TCP_CRR -H 
TCP Connect/Request/Response TEST to
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec
131070 131070 1        1       9.99     2662.20
16384  87380

Even request/response packets using a byte, the transaction rate is significantly reduced, only 2662.20 times / sec. Partial parameters TCP_CRR and TCP_RR of the same.


The transaction process of UDP_RR using UDP packet request/response. Since there is no TCP connection the burden, so we speculated that will exchange rate has improved.

./netperf -t UDP_RR -H 
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec
65535  65535  1        1       9.99     10141.16
65535  65535

The results confirm our conjecture, exchange rate of 10141.16 times per second, a high value of TCP_RR. However, if the opposite result, namely the transaction rate would be reduced, also need not worry, because it explains in a network, a router or other network devices by using buffer space and processing technology and TCP to UDP.


In addition to netperf, there are many other network performance test tools, such as DBS, iperf, pathrate, nettest, netlogger, tcptrace, ntop etc. These tools have their own characteristics and different focus, we can according to the specific application environment, have the option of using them, so you can make these tools to play the greatest effect. Although it is open source software, but the function and business network test tool of these tools are equally strong, and also obtained the widespread application, familiar with these tools will be of great help to our practical work.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download

Posted by Nancy at June 25, 2014 - 12:08 PM