iPerf is an open-source client-server tool for active throughput testing: it generates synthetic TCP, UDP or SCTP traffic between two endpoints and reports the achievable bandwidth, and for UDP also jitter and packet loss. In network monitoring and troubleshooting, it answers a question that passive tools cannot: how much data this path can actually carry right now, under controlled load.
Two lineages exist. iperf3 is a rewrite with a cleaner code base, JSON output and a single control channel, and it is the version most people mean today. iPerf2 continues as a separately maintained branch with strong multi-threading and latency features. The two are not compatible with each other, so both ends of a test must run the same family.
How iPerf measures a path
One host runs iPerf in server mode and listens, by default on TCP port 5201 for iperf3 or port 5001 for iPerf2. The other host runs in client mode, connects, agrees on test parameters over a control connection and then sends a stream of generated data for a set time, 10 seconds by default.
Both sides count the bytes transferred in each reporting interval, usually one second, and print the results. In TCP mode the result reflects what the full stack achieves, including TCP congestion control, window size and retransmissions. In UDP mode the client sends at a fixed target rate, and the server reports how many datagrams were lost or arrived out of order and how much their arrival times varied.
Because iPerf writes generated data from memory and discards it on arrival, it removes disk and application effects from the measurement. This makes it a clean test of the network and the host network stacks, but also means the results do not automatically predict application performance.
Placement of the endpoints defines what is being measured. Running the server as close as possible to the far end of the segment under test, for example on a host directly attached to the remote switch, isolates that segment. Leaving an iPerf server permanently exposed is not advisable: iperf3 serves one test at a time, has only optional authentication, and an open server can be abused to generate heavy traffic, so test servers are usually started on demand or restricted by firewall rules.
Key options and what they change
A handful of options control almost every useful test. The table summarizes the most important iperf3 flags and their effect on results.
| Option | Meaning | Why it matters |
|---|---|---|
| -t | Test duration in seconds | Longer runs smooth out TCP ramp-up effects |
| -P | Number of parallel streams | Reveals whether one flow is window-limited |
| -R | Reverse mode, server sends | Tests the opposite direction without swapping roles |
| –bidir | Both directions at once | Exposes half-duplex or shared-medium limits |
| -u -b | UDP mode with target bitrate | Measures loss and jitter at a known rate |
| -w | Socket buffer or window size | Must cover the bandwidth-delay product |
| -J | JSON output | Enables automated collection and graphing |
UDP tests have a trap: iperf3 sends at only 1 Mbit/s by default in UDP mode, so a test without -b appears to show a perfect but very slow link. Setting the target bitrate explicitly is essential.
Reading TCP and UDP results
TCP and UDP tests answer different questions, and each produces its own set of indicators.
| Metric | TCP mode | UDP mode | Interpretation |
|---|---|---|---|
| Throughput | Achieved goodput | Received rate at set send rate | Main capacity figure |
| Retransmissions | Reported by sender | Not applicable | High values suggest loss or congestion |
| Packet loss | Hidden by retransmission | Reported directly | Critical for voice and video |
| Jitter | Not reported | Reported in milliseconds | Variation in packet arrival timing |
| Congestion window | Shown per interval on Linux | Not applicable | Reveals TCP growth and backoff |
Results should be read as achievable throughput between two specific hosts at one moment. A low figure can come from the network, from either host’s CPU or network card, or from TCP settings; a high figure proves the path is capable, not that every application will reach it.
iPerf compared with other network measurement tools
iPerf belongs to the group of active measurement tools, which create their own test traffic. It complements passive tools that observe real traffic and path tools that study individual hops.
| Tool | Measurement type | Main question answered |
|---|---|---|
| iPerf | Active, synthetic load | How much throughput can this path deliver |
| Ping | Active, small probes | Is the host reachable and what is the latency |
| Traceroute and MTR | Active, per-hop probes | Where along the path latency or loss appears |
| Wireshark | Passive packet capture | What exactly happens inside real traffic |
| NetFlow and SNMP | Passive statistics | How much real traffic uses each link over time |
| Internet speed tests | Active, to public servers | What the access line delivers to the internet |
Unlike public speed test sites, iPerf lets an engineer choose both endpoints, which makes it the right tool for testing a specific WAN link, a VPN tunnel, a wireless segment or a data center fabric.
Common mistakes when testing
- Testing through a busy production link without warning can congest it; schedule load tests or limit the bitrate.
- Single-stream TCP on long paths often under-reports capacity because of window limits; compare with several parallel streams.
- Underpowered endpoints such as small routers or virtual machines can become the bottleneck at 10 Gbit/s and above.
- Firewalls blocking the test port cause connection failures that look like network outages.
- Comparing iPerf2 and iperf3 results directly is misleading, because their defaults and reporting differ.
A good practice is to record results as part of a network baseline: the same hosts, options and time windows, repeated regularly, so that later tests can be compared with known normal values.
In everyday language
iPerf is a test that pushes as much data as possible between two computers and measures how fast it gets through. One computer waits, the other sends. After a few seconds, you see the real speed between those two points.
It is like timing how fast water flows through a specific pipe, instead of guessing from the pipe’s label. It can also show whether some water leaks along the way, which matters for calls and video.
Seen in the real world
A company connects its headquarters and a branch office with a new 500 Mbit/s site-to-site VPN, but users at the branch complain that file copies run at about 60 Mbit/s. An engineer starts an iperf3 server on a host at headquarters and runs a 30-second TCP test from a branch laptop. A single stream reaches 65 Mbit/s, while eight parallel streams reach about 470 Mbit/s.
The difference points to a per-flow limit rather than a slow link. The 42 ms round-trip time and a small default window on the file server explain it. After window settings on the server are corrected, single-stream throughput climbs above 400 Mbit/s. A UDP test at 450 Mbit/s also shows under 0.1 percent loss, so the tunnel itself was never the bottleneck.