Netperf – Network Bandwidth Testing: A Comprehensive Guide

Table of Contents#

1. What is Netperf?
2. How Netperf Works
3. Installation
4. Basic Netperf Commands
5. Advanced Usage
6. Common Testing Practices
7. Netperf vs. iperf3
8. Best Practices
9. Troubleshooting Common Issues
10. FAQ
11. Conclusion
12. References

What is Netperf?#

Netperf is an open-source benchmarking tool originally developed by Hewlett-Packard (HP) and now maintained by Hewlett Packard Enterprise (HPE) under the MIT license. It measures network performance between two endpoints and supports both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), simulating various real-world traffic patterns, such as:

• Bulk data transfer (e.g., large file transfers).
• Request/response workloads (e.g., client-server database queries).
• Stream-based communication (e.g., video streaming).

Key Features:#

• Protocol Support: TCP (including TCP_STREAM, TCP_RR for request/response) and UDP (UDP_STREAM, UDP_RR).
• Metrics: Measures throughput (Mbps), latency (round-trip time), and transaction rates.
• Flexibility: Customizable buffer sizes, test durations, and traffic patterns.
• Lightweight: Minimal resource overhead, making it suitable for production environments.

How Netperf Works#

Netperf operates in a client-server model:

• Server (netserver): Runs on the target machine and listens for incoming test requests on a default port (12865).
• Client (netperf): Runs on the source machine, connects to the netserver, and initiates the test.

Core Concepts:#

• Test Modes: Defines the traffic pattern (e.g., TCP_STREAM for bulk TCP transfer, UDP_RR for UDP request/response).
• Control vs. Data Connections: Netperf uses a control connection to set up tests and a separate data connection to transfer test traffic, ensuring minimal interference with results.
• Metrics Calculation: Throughput is measured as data transferred per second; latency is derived from round-trip time (RTT) for request/response tests.

Installation#

Netperf is available for Linux, macOS, and Windows (via WSL or Cygwin). Below are installation steps for common operating systems:

Linux (Debian/Ubuntu)#

sudo apt update && sudo apt install netperf -y

Linux (RHEL/Rocky Linux/AlmaLinux)#

# For RHEL 7/CentOS 7 (EOL June 2024):
# First install EPEL repository
sudo yum install epel-release -y
# Then install netperf
sudo yum install netperf -y
 
# For RHEL 8-9, Rocky Linux 8-9, AlmaLinux 8-9:
# Netperf is not available in EPEL for RHEL 8+; compile from source (see below)

macOS (via Homebrew)#

brew install netperf

Windows (WSL or Cygwin)#

• WSL: Install Ubuntu via Microsoft Store, then use the Debian/Ubuntu command above.
• Cygwin: Install from Cygwin’s package manager (search for netperf).

Compiling from Source (Advanced)#

For the latest version, compile from source:

wget https://github.com/HewlettPackard/netperf/archive/refs/tags/netperf-2.7.0.tar.gz
tar -xzf netperf-2.7.0.tar.gz
cd netperf-netperf-2.7.0
./autogen.sh
./configure
make
sudo make install

Basic Netperf Commands#

Before running tests, start the netserver on the target machine:

# On the server (target machine)
netserver
# Output: Starting netserver with host 'INADDR_ANY' port '12865' and family AF_UNSPEC

1. TCP Bulk Transfer (TCP_STREAM)#

Measures maximum TCP throughput (e.g., large file transfers).
Syntax:

netperf -H <server_ip> -t TCP_STREAM -l <test_duration_seconds>

Example: Test TCP throughput to a server at 192.168.1.100 for 60 seconds:

netperf -H 192.168.1.100 -t TCP_STREAM -l 60

Sample Output:

MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.100 (192.168.1.100) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    60.00      943.25

• Throughput: ~943 Mbps (megabits per second).

2. UDP Bulk Transfer (UDP_STREAM)#

Measures UDP throughput; packet loss must be calculated by comparing sender and receiver message counts (UDP is connectionless, so loss is common in congested networks).
Syntax:

netperf -H <server_ip> -t UDP_STREAM -l <test_duration_seconds>

Example: Test UDP throughput to 192.168.1.100 for 30 seconds:

netperf -H 192.168.1.100 -t UDP_STREAM -l 30

Sample Output:

MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.100 (192.168.1.100) port 0 AF_INET
Socket  Message  Elapsed      Messages                
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  65535   1470    30.00      208333      0      81.67   
  65535   1470    30.00      206250      0      80.85   

• Throughput: 80 Mbps with 0 errors (no local system call errors, e.g., socket overflow).

3. TCP Request/Response (TCP_RR)#

Simulates client-server request/response workloads (e.g., API calls, database queries). Measures transactions per second (TPS) and latency.
Syntax:

netperf -H <server_ip> -t TCP_RR -l <test_duration_seconds>

Example: Test TCP request/response to 192.168.1.100 for 20 seconds:

netperf -H 192.168.1.100 -t TCP_RR -l 20

Sample Output:

MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.100 (192.168.1.100) port 0 AF_INET
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       20.00    4567.89  

• Transaction Rate: ~4568 TPS (transactions per second).

4. UDP Request/Response (UDP_RR)#

Similar to TCP_RR but for UDP, useful for testing request/response patterns like DNS. For stream-based applications like VoIP or video conferencing, use UDP_STREAM.
Syntax:

netperf -H <server_ip> -t UDP_RR -l <test_duration_seconds>

Advanced Usage#

Custom Buffer Sizes#

Adjust send/receive buffer sizes to simulate real-world application behavior (e.g., small buffers for IoT devices, large buffers for video streaming).
Flags:

• -s <buffer_size>: Sets both send and receive buffer sizes for the local system (bytes).
• -S <buffer_size>: Sets both send and receive buffer sizes for the remote system (bytes).

Example: TCP_STREAM with 64KB local buffers and 128KB remote buffers:

netperf -H 192.168.1.100 -t TCP_STREAM -l 60 -s 65536 -S 131072

Multiple Concurrent Streams#

Test network performance under load by running multiple parallel streams. Use -P 0 to suppress the test result header output (for easier parsing in scripts) and run netperf in the background.

Example: 4 parallel TCP_STREAM tests:

for i in {1..4}; do
  netperf -H 192.168.1.100 -t TCP_STREAM -l 60 -P 0 &
done
wait  # Wait for all tests to complete

Output Formatting#

Generate machine-readable output (e.g., CSV) for analysis using the -O flag with pre-defined keywords:

netperf -H 192.168.1.100 -t TCP_STREAM -l 60 -O "THROUGHPUT,THROUGHPUT_UNITS" --

For verbose output (debugging):

netperf -H 192.168.1.100 -t TCP_STREAM -l 10 -v 2

Common Testing Practices#

1. Baseline Testing#

Establish a baseline under ideal conditions (no other traffic) to compare against future tests. Example:

# Baseline TCP throughput at 2 AM (low network usage)
netperf -H 192.168.1.100 -t TCP_STREAM -l 300  # 5-minute test

2. LAN vs. WAN Testing#

• LAN: Focus on maximum throughput (e.g., TCP_STREAM with large buffers).
• WAN: Prioritize latency (e.g., UDP_RR with small request sizes) and throughput (e.g., UDP_STREAM for stream-based applications).

3. Load Testing#

Simulate peak traffic by combining multiple streams and varying buffer sizes to identify bottlenecks (e.g., router limits, CPU constraints).

Netperf vs. iperf3: Which Tool Should You Use?#

Both Netperf and iperf3 are popular network performance benchmarking tools, but they serve slightly different purposes:

When to use Netperf:

• Measuring round-trip latency (TCP_RR, UDP_RR)
• Testing request/response workloads (API calls, database queries)
• Needing CPU utilization and service demand metrics
• Running tests with confidence intervals

When to use iperf3:

• Simple throughput testing
• Quick bandwidth verification
• Testing with parallel streams (-P flag)
• When you need a tool with broader community support

For comprehensive network testing, consider using both tools together to cross-verify results.

Best Practices#

1. Isolate the Network#

• Run tests during off-peak hours to avoid interference from other traffic.
• Use dedicated test machines to prevent CPU/memory bottlenecks on the client/server.

2. Test Duration#

• Bulk transfers: 60–300 seconds (to account for TCP slow start and stabilize results).
• Request/response: 30–60 seconds (to capture transaction rate variability).

3. Validate Results#

• Run tests 3–5 times and average results to minimize variance.
• Cross-verify with other tools (e.g., iperf3, tcptrace) for consistency.

4. Security#

• Restrict netserver access using firewall rules (e.g., sudo ufw allow 12865/tcp on Ubuntu, sudo firewall-cmd --add-port=12865/tcp on RHEL/Rocky Linux).
• Consider using iptables for fine-grained control: sudo iptables -A INPUT -p tcp --dport 12865 -s <client_ip> -j ACCEPT
• Stop netserver after testing to avoid exposing the port.

5. Calibrate Buffer Sizes#

Match buffer sizes to real applications (e.g., 1KB for IoT, 64KB for file transfers). Use ss -i to check default OS buffer sizes.

Troubleshooting Common Issues#

1. Connection Refused#

Issue: netperf: connect to host <server_ip> port 12865: Connection refused Fix: Ensure netserver is running on the target machine and port 12865 is open (check firewall rules).

2. Low Throughput#

Possible Causes:

• Small buffer sizes: Increase with -s and -S.
• CPU bottleneck: Check top/htop on client/server; ensure test machines have sufficient cores.
• Network congestion: Test during off-peak hours or use QoS to prioritize test traffic.

3. High UDP Packet Loss#

Fix:

• Reduce UDP send rate (use smaller message sizes with -m).
• Check MTU settings (e.g., ifconfig); fragmentation increases loss.

4. Inconsistent Results#

Fix:

• Run tests multiple times and average.
• Disable background processes (e.g., backups, updates) on test machines.

FAQ#

What is Netperf used for?#

Netperf is used to measure network performance, including throughput (bandwidth), latency (round-trip time), and transaction rates. It's commonly used by network administrators, DevOps engineers, and developers to diagnose bottlenecks, validate SLAs, and optimize network infrastructure.

Is Netperf still maintained?#

Yes, Netperf is still maintained. The latest version is 2.7.0, available on GitHub. While development is slower than newer tools, it remains a reliable choice for network benchmarking, especially for latency testing.

How do I measure network latency with Netperf?#

Use the TCP_RR or UDP_RR test modes:

netperf -H <server_ip> -t TCP_RR -l 30

This measures round-trip time for TCP request/response transactions. For more detailed latency statistics, use the -o flag:

netperf -H <server_ip> -t TCP_RR -- -o min_latency,max_latency,mean_latency

What is the difference between Netperf and iperf?#

Netperf excels at latency testing (TCP_RR/UDP_RR) and provides CPU utilization metrics. iperf3 is simpler for basic throughput testing and has broader community support. Use Netperf for request/response workloads and iperf3 for bulk transfer testing.

Can I run Netperf without installing netserver?#

Yes, you can use the -N flag to run limited tests without a control connection:

netperf -H <server_ip> -N -t TCP_STREAM

However, this limits test options and prevents retrieving remote metrics.

How do I test network performance between two cloud instances?#

1. Install Netperf on both instances
2. Start netserver on the target instance
3. Run netperf from the source instance:

netperf -H <target_ip> -t TCP_STREAM -l 60

For latency testing, use TCP_RR instead of TCP_STREAM.

Conclusion#

Netperf is a versatile tool for network bandwidth testing, offering deep insights into TCP/UDP performance. By mastering its basic and advanced features, you can diagnose bottlenecks, validate network SLAs, and optimize application performance. Remember to follow best practices like isolating tests, calibrating buffer sizes, and cross-verifying results to ensure accuracy.

Whether you’re testing a local LAN or a global WAN, Netperf provides the granular data needed to make informed network decisions. For comprehensive testing, consider combining Netperf with complementary tools like iperf3 to cover both throughput and latency testing needs.

References#

• Netperf Official GitHub Repository
• Netperf Man Page (Debian)
• Netperf Homepage
• Google Cloud: Using Netperf and Ping to Measure Network Latency
• Measuring Network Throughput using NetPerf & iPerf
• RFC 2544: Benchmarking Methodology for Network Interconnect Devices