Netperf Command

[Vernon]

Netperfis a benchmark that can be used to measure the performance ofmany different types of networking. It provides tests for bothunidirectional throughput, and end-to-end latency. The environmentscurrently measureable by netperf include:

Here are some of the netperf services available via this page:Download Netperf Clone or downloadvarious revisions of the Netperf benchmark.Netperf Numbers Submit and Retrieve Netperf results from the Netperf Database.Netperf Training View the Netperf manual or whitepapers on using Netperf.Netperf Feedback Providefeedback on the benchmark or the pages.Other Resources The network performance world does not live on netperf alone.Happy Benchmarking!

The three key measures of network performance are latency (the time required to transfer data across the network), throughput (the amount of data or number of data packets that can be delivered on an IP network in a predefined timeframe) and jitter or delay jitter (the changes and their duration in delay that occur during transfers).

In this blog post, I will show you how to measure throughput using NetPerf and iPerf, two open source network performance benchmark tools that support both UDP and TCP protocols. Each tool provides in addition other information: NetPerf for example provides tests for end-to-end latency (round-trip times or RTT) and is a good replacement for Ping, iPerf provides packet loss and delay jitter, useful to troubleshoot network performance. Choosing one or the other tool depends on your use-case and the test you are planning to achieve. Note that for the same input parameters, the tools can report different bandwidths, as they are not designed the same.

I will use the default parameters and run each test for 5 minutes (300 seconds). For a good report, it is recommended to run the tests multiple times, at different times of the day, with different parameters.

NetPerf and iPerf have a client and server functionality, and must be installed both on the server and the client from where you are conducting network performance tests. For each tool I will provide the most common parameters, and conduct tests between a client (1GB MEM) and a server (1GB MEM) and in my LAN (Local Area Network), and between a client and a remote server (in a WAN).

$ netperf -H HOST -l 300 -t TCP_STREAM

MIGRATED TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) () port 0 AF_INET : histogram : spin interval

Recv Send Send

Socket Socket Message Elapsed

Size Size Size Time Throughput

bytes bytes bytes secs. 10^6bits/sec

UDP does not provide an end to end control flow, when testing UDP throughput make sure you specify the size of the packet to be sent by the client. Always read the receive rate on the server, since UDP is an unreliable protocol, the reported send rate can be much higher than the actual receive rate.

I am working on Ubuntu 12.10 and I just installed netperf by apt-get install netperf. Then I tried to start netperf server by running netserver and I got Unable to start netserver with 'IN(6)ADDR_ANY' port '12865' and family AF_UNSPEC

While netserver's behavior seems to be somewhat unusual on Ubuntu, I think that you may find the netserver service to be already running.

If you run a ps -ef grep netserver, you may find the process already running and you should be able to perform netperf queries against it.

As described in a previous blog post, when we run latency tests at Google in a cloud environment, our tool of choice is PerfKit Benchmarker (PKB). This open-source tool allows you to run benchmarks on various cloud providers while automatically setting up and tearing down the virtual infrastructure required for those benchmarks.

These commands run intra-zone latency benchmarks between two machines in a single zone in a single region. Intra-zone benchmarks like this are useful for showing very low latencies, in microseconds, between machines that work together closely. We'll get to our favorite options and method to run these commands later in this post.

To explain, this is largely an artifact of the different intervals the two tools used by default. Ping uses an interval of 1 transaction per second while netperf issues the next transaction immediately when the previous transaction is complete.

For ping, use the -i flag to set the interval, given in seconds or fractions of a second. On Linux systems, this has a granularity of 1 millisecond, and rounds down. For example, if you use an interval of 0.00299 seconds, this rounds down to 0.002 seconds, or 2 milliseconds. If you request an interval smaller than 1 millisecond, ping rounds down to 0 and sends requests as quickly as possible.

For netperf TCP_RR, we can enable some options for fine-grained intervals by compiling it with the --enable-spin flag. Then, use the -w flag, which sets the interval time, and the -b flag, which sets the number of transactions sent per interval. This approach allows you to set intervals with much finer granularity, by spinning in a tight loop until the next interval instead of waiting for a timer; this keeps the cpu fully awake. Of course, this precision comes at the cost of much higher CPU utilization as the CPU is spinning while waiting.

Generally, we recommend using netperf over ping for latency tests. This isn't due to any lower reported latency at default settings, though. As a whole, netperf allows greater flexibility with its options and we prefer using TCP over ICMP. TCP is a more common use case and thus tends to be more representative of real-world applications. That being said, the difference between similarly configured runs with these tools is much less across longer path lengths.

Also, remember that interval time and other tool settings should be recorded and reported when performing latency tests, especially at lower latencies, because these intervals make a material difference.

Notice that the netperf TCP_RR benchmarks run with no additional interval setting. This is because by default netperf inserts no added intervals between request/response transactions; this induces more accurate and consistent results.

Also, the CPU utilization mechanism in a virtual guest environment, i.e., a virtual machine may not reflect the actual utilization as in a bare metal environment because much of the networking processing happens outside the context of the virtual machine. Thus, as per the below documentation link by Hewlett-Packard: -

If one is looking to measure the added overhead of a virtualization mechanism, rather than rely on CPU utilization, one can rely instead on netperf _RR tests - path-lengths and overheads can be a significant fraction of the latency, so increases in overhead should appear as decreases in transaction rate. Whatever you do, DO NOT rely on the throughput of a _STREAM test. Achieving link-rate can be done via a multitude of options that mask overhead rather than eliminate it.

The -H option expects to take a hostname as an argument. And the -p option expects to take a port number as an argument. As written the "-p" will be interpreted as a hostname. And when I tried it at least will fail. I assume you've omitted some of the command line?

The -T option will bind where netperf and netserver will run (in this case on vCPU 1 on the netperf side and vCPU 1 on the netserver side) but it will not necessarily control where at least some of the network stack processing will take place. So, in your 64-vCPU setup, the interrupts for the networking traffic and perhaps the stack will run on a different vCPU. In your 1-vCPU setup, everything will be on the one vCPU. It is quite conceivable you are seeing the effects of cache-to-cache transfers in the 64-vCPU case leading to lower transaction/s rates.

I've installed netperf 2.6 in two sites and trying to run the netperf benchmark, but All I'm getting is zero Throughput... Does anyone knows how to use netperf properly? (I was following the official documentation)

A netperf test has two "connections." The first is the "control connection" over which information about the test setup and result is exchanged. For the benchmarking itself a "data connection" is used. The control connection will use the control port you've specified with the global "-p" option. The data connection will by default use a port number chosen by the networking stack where the netserver runs.

You can specify an explicit port number for the data connection with a test-specific "-P" option. So, if you opened a second port number, 9992, you would start the netserver as before, and then your netperf command would become:

The ethernet speed assigned to bond0 and bond1 is same as server i.e. 1 GB and 3 GB respectively

Let us start our test

Installed netperf on both the machines

NOTE: I would recommend to disable the firewall on both server and client for the monitoring purpose as at times your firewall might stop netperf from sending traffic to client machine

On Server

In this section the proposed TCP and UDP performance testtools are described that has been used. In general these are programs written inthe C language and / or C++. The tools, described in the followingsubsections, have been used. Also the modifications, when applied, are mentionedthere.

The Netperf toolis in principle a TCP and UDP benchmark. However, no shapingalgorithms have been implemented. Therefore, the value of the UDP testtype is limited, because due to the lack of shaping, the sender will oftenoverflow the receiver, because sending is more easier than receiving. In factvarious TCP and UDP traffic types can be defined. See themanual for more information.

In fact netserver is a true serverin the sense that all relevant data should be specified via thenetperf client. This feature makesnetserver also suited to bestarted from the Unix inetd net services daemon, such that inprinciple all security features, supplied by the TCP wrapper tool, arealso in effect here.

3a8082e126