Skip to main content

iperf Network Benchmark

iperf measures achievable network bandwidth between two hosts over TCP, UDP, or SCTP, reporting throughput, jitter, loss, and retransmits. It tests the path itself, not application overhead, and needs control of both ends.

iperf, and its modern rewrite iperf3, is the standard tool for measuring network throughput between two endpoints. By generating controlled traffic and timing how much data crosses the link, it reveals the achievable bandwidth of a path, which can differ greatly from the nominal link speed because of latency, TCP window sizes, congestion, and intervening devices. It is a staple for validating new links, troubleshooting slow transfers, and verifying that a network delivers the capacity that was paid for.

What It Measures

For TCP, iperf reports achieved bandwidth and the number of retransmissions, which signal loss or congestion on the path. For UDP, it reports bandwidth, jitter (variation in packet arrival timing), and packet loss, making it useful for assessing real-time and streaming suitability such as voice and video. iperf3 also reports the TCP congestion window and round-trip-time estimates, which help diagnose why a link underperforms relative to its raw capacity.

Methodology

iperf runs in a client-server pair: one host runs in server mode and the other connects as client. The client sends a stream for a set duration; bandwidth is computed from bytes transferred over elapsed time. Key parameters include protocol (TCP, UDP, SCTP), test duration, parallel streams (to saturate high-bandwidth-delay links that a single flow cannot fill), TCP window size, UDP target rate, and packet size. For UDP, the client sends at a specified rate and the server measures what actually arrives, computing loss and jitter. Running multiple parallel streams often reveals higher aggregate throughput on long-distance, high-latency links.

How to Interpret Results

Compare measured bandwidth to the link's nominal capacity; a large shortfall on TCP often indicates an undersized window relative to the bandwidth-delay product, packet loss triggering congestion control, or a bottleneck device along the path. Use parallel streams to distinguish per-flow limits from total path capacity. For UDP, low jitter and near-zero loss indicate a link fit for voice or video. TCP retransmits and a small, oscillating congestion window point to loss or buffering issues. Always test in both directions, since paths and policies can be asymmetric.

Limitations

iperf measures raw path throughput between two cooperating hosts; it does not reflect application-layer overhead, server processing, or content delivery from real services. Results depend on endpoint CPU, NIC capability, and offload settings, so a slow host can cap throughput below the network's true limit, leading to false conclusions about the network. It requires control of both ends, which is not always possible. Use iperf to characterize network paths and diagnose link issues, and application-level tools to measure end-to-end service performance.