IPerf2 vs IPerf3: Key Differences Network Engineers Should Know

How to Install and Use IPerf2 for Accurate Bandwidth MeasurementsAccurate network bandwidth measurement is essential for diagnosing performance issues, verifying service-level agreements (SLAs), and validating network capacity. IPerf2 is a mature, widely used tool for active measurements of network throughput, jitter, and packet loss. This guide covers installation, basic and advanced usage, test design best practices, interpreting results, and troubleshooting to help you get reliable, repeatable measurements.

What is IPerf2?

IPerf2 is a command-line network testing tool that measures the maximum achievable bandwidth between two endpoints. It supports TCP and UDP tests, reverse testing, bidirectional tests, and options for tuning buffer sizes, parallel streams, and test durations. Although IPerf3 is a newer rewrite with a different protocol, IPerf2 remains popular due to its feature set, familiarity, and some behaviors that differ from IPerf3.

Key facts:

IPerf2 measures TCP and UDP throughput.
It requires both a client and a server.
Supports options like parallel streams, buffer tuning, and reverse tests.

When to use IPerf2 vs IPerf3

IPerf2 and IPerf3 are different implementations with incompatible network protocols; you cannot mix them in a single test. Use IPerf2 if:

You need compatibility with existing IPerf2-based workflows or scripts.
You require features present in IPerf2 that are missing or behave differently in IPerf3 (e.g., certain reporting formats or legacy behaviors).

Use IPerf3 for newer projects if you want a simpler protocol, JSON output, and active maintenance by the IPerf3 maintainers.

Installing IPerf2

Below are installation steps for the most common platforms: Linux (Debian/Ubuntu and RHEL/CentOS), macOS, and Windows.

Linux (Debian/Ubuntu)

Update the package lists:
```
sudo apt update 
```
Install iperf (package name iperf for IPerf2 on many distros):
```
sudo apt install iperf 
```
Verify installation:
```
iperf --version 
```

If your distribution provides iperf3 by default, install iperf2 from source or available iperf2 packages:

sudo apt install build-essential git git clone https://github.com/esnet/iperf.git cd iperf ./configure make sudo make install

RHEL / CentOS

Install EPEL if needed, then iperf:
```
sudo yum install epel-release sudo yum install iperf 
```
Or build from source using the same git steps above.

macOS

Using Homebrew:

brew install iperf

If Homebrew installs iperf3 by default, install iperf2 explicitly:

brew install iperf@2

Windows

Download an IPerf2 build (precompiled) from a trusted source (for example, project releases on GitHub or maintained binaries).
Extract the zip and place the iperf.exe in a folder on PATH, or run it from the extracted directory.
Verify:
```
iperf.exe --version 
```

Basic IPerf2 Usage

IPerf2 runs in server mode on one machine and client mode on another.

Start the server:
```
iperf -s 
```
By default the server listens on TCP port 5001. Use -p to change the port.
Run a TCP test from the client:
```
iperf -c <server_ip> 
```
Run a UDP test:
```
iperf -c <server_ip> -u -b 100M 
```
The -u flag selects UDP; -b sets the target bandwidth (for UDP tests, TCP ignores -b).
Run a reverse test (client sends data back to server):
```
iperf -c <server_ip> -r 
```
Use multiple parallel streams:
```
iperf -c <server_ip> -P 4 
```
Change test duration (default 10 seconds):
```
iperf -c <server_ip> -t 30 
```

Advanced Options and Tuning

Tuning parameters can improve measurement accuracy or emulate real-world traffic patterns.

TCP window size (socket buffer):
```
iperf -c <server_ip> -w 512K 
```
Large latency-bandwidth product paths need larger windows to fully utilize capacity. Use the formula: window >= bandwidth * RTT.

Set port number:

iperf -s -p 5201 iperf -c <server_ip> -p 5201

Change reporting interval:
```
iperf -c <server_ip> -i 1 
```

Bind client or server to a specific interface/IP:

iperf -c <server_ip> -B <client_ip> iperf -s -B <server_ip>

Set client to run continuous tests (useful for long stability tests — be cautious):
```
iperf -c <server_ip> -t 3600 
```
Test bidirectional simultaneous traffic: Run iperf in server mode with -s on both ends, then use -d:
```
iperf -c <server_ip> -d 
```

Designing Accurate Tests

Accurate measurement is more about test design than raw options. Follow these practices:

Test during controlled conditions: minimal other traffic, consistent route, and known endpoints.
Use identical hardware and software settings on both ends to avoid bottlenecks outside the network.
Run multiple iterations and take median or average values; avoid single short tests.
For high-BDP links, increase TCP window size and use parallel streams (-P) if necessary to saturate the link.
When measuring UDP, specify an appropriate bandwidth (-b) and monitor packet loss reported by iperf.
Use the same iperf version on both sides (IPerf2 with IPerf2).
Note and record RTT (ping/traceroute) and CPU utilization on endpoints during tests.

Interpreting Results

IPerf2’s output gives per-interval and summary throughput, and for UDP, packet loss and jitter.

TCP results: focus on the “Bytes” and “Mbits/sec” values in the summary. If throughput is lower than expected, check for:
- CPU limits on sender/receiver.
- Insufficient TCP window size relative to RTT.
- Link-level errors or device rate limits.
UDP results: review “lost/total datagrams” and “Jitter”. High loss or jitter indicates congestion or link issues.
Look at per-interval variations to spot transient congestion or bursts.

Common Troubleshooting

No connection: ensure firewall allows the chosen port (default 5001), and both endpoints can reach each other.
Low throughput: monitor CPU, NIC offload settings, interrupt moderation, driver issues, and check duplex/MTU mismatches.
Asymmetric results: verify that reverse paths are not limited, and check for QoS shaping or per-direction limits.
High packet loss on UDP: reduce offered bandwidth or investigate queue/queueing disciplines and bufferbloat.
Time synchronization: while not required, synchronized clocks (via NTP) make correlating logs easier.

Example Workflow (Quick Checklist)

Verify network path: ping, traceroute, check MTU.
Start server: iperf -s (on port 5001 or chosen port).
From client, run baseline TCP test: iperf -c -t 30 -i 1.
If link underutilized, increase -w or -P.
For UDP, pick -b approximately expected capacity and run: iperf -c -u -b 100M -t 30.
Repeat tests at different times and take median results.
Record CPU/utilization and any network device counters.

Alternatives and Complementary Tools

While IPerf2 is great for active throughput tests, consider these for complementary insight:

iperf3 — newer protocol, JSON output, simpler behavior.
nuttcp — similar tool with a slightly different feature set.
ping/traceroute — basic RTT and path info.
packet captures (tcpdump/wireshark) — detailed protocol-level diagnostics.
SNMP/sFlow/NetFlow — flow and utilization monitoring over time.

Security Considerations

Only run iperf server on trusted networks or behind access controls; an open iperf server can be used to generate traffic against your network.
Use firewall rules to restrict access to the iperf port(s).
Avoid running long, unsupervised tests on production systems without scheduling and notice.

Conclusion

IPerf2 remains a practical, flexible tool for accurate bandwidth measurements when used with care: match versions, design tests thoughtfully, tune buffers for high-BDP links, and repeat tests to produce reliable data. Proper interpretation of throughput, loss, and jitter — plus awareness of endpoint limitations — is essential to turning test numbers into actionable network knowledge.