iPerf2 and iPerf3 share a name, a purpose, and almost nothing else. iPerf3 was a ground-up rewrite by ESnet, not an upgrade, and the two do not interoperate - an iPerf2 client cannot test against an iPerf3 server, and they do not even default to the same port (5001 vs 5201). Both are actively maintained today by different teams, which surprises people who assume "3 replaced 2." This article breaks down the real differences, with live output from iperf 2.2.1 and iperf 3.18, as part of our complete iPerf guide.
Two Tools, Not Two Versions
iPerf2 (currently maintained on SourceForge by Bob McMahon) evolved continuously from the original NLANR tool, gaining latency measurement, enhanced reporting, and serious multithreading. iPerf3 (maintained by ESnet on GitHub) was rewritten for a cleaner codebase, a scripting-friendly design, and a library API (libiperf). The rewrite deliberately dropped features iPerf2 users relied on, and iPerf2 development never stopped. Hence: two parallel tools.
The Differences That Change Your Results
iPerf2 is multithreaded: -P 8 uses multiple cores. Classic iPerf3 runs all streams in a single thread, so on 10G+ links one CPU core often becomes the bottleneck before the network does. Advantage: iPerf2 on very fast links.
An iPerf2 server accepts multiple clients at once. iPerf3 handles exactly one test at a time and tells later clients "the server is busy running a test." Advantage: iPerf2 for shared test servers.
iPerf3's -J emits complete JSON. iPerf2 offers CSV (-y) which is thinner. Advantage: iPerf3 for automation.
iPerf3 has clean reverse mode (-R) driven entirely from the client. iPerf2 instead has dual/tradeoff modes (-d / -r) that test both directions in one run, which iPerf3 dropped. Different tools for different workflows.
iPerf2 tests multicast (bind the server to a group address, set TTL with -T). iPerf3 cannot. Advantage: iPerf2, and it is the only option.
iPerf2's enhanced mode reports one-way latency, RTT, and derived metrics inline. iPerf3 reports throughput, retransmits, and cwnd, leaving latency to ping. Advantage: iPerf2 for latency-under-load.
You Can See the Philosophy in the Output
Here is real iperf 2.2.1 enhanced output (-e):
$ iperf -c 127.0.0.1 -t 5 -e
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 5001 with pid 12365 (1/0 flows/load)
Write buffer size: 131072 Byte
TCP congestion control using cubic
TOS defaults to 0x0 (dscp=0,ecn=0) (Nagle on)
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ ID] Interval Transfer Bandwidth Write/Err Rtry InF(pkts)/Cwnd(pkts)/RTT(var) NetPwr
[ 1] 0.0000-5.0161 sec 7.70 GBytes 13.2 Gbits/sec 63063/0 0 0K(0)/319K(10)/135(67) us 12206015
Congestion control algorithm, writes and errors, retries, in-flight data, cwnd in packets, RTT with variance, and a NetPwr figure - all in one line. iPerf2 packs telemetry into human-readable text. iPerf3's equivalent run prints the familiar clean Interval/Transfer/Bitrate/Retr/Cwnd block (see how to use iPerf3 for annotated output) and saves the deep detail for -J JSON, where scripts can parse it reliably.
Feature Support at a Glance
-J); iPerf2 has CSV -y-R)-d)iPerf2 only (iPerf3 has --bidir in newer builds)-e enhanced mode)Flag Collisions: The Silent Gotcha
Because the tools evolved separately, several flags mean different things, and muscle memory from one tool produces wrong tests in the other. The dangerous ones:
-b: UDP-only bandwidth in iPerf2 (and implies-uin old builds); in iPerf3 it rate-limits TCP as well, and UDP needs an explicit-u. An iPerf3 user typingiperf3 -c host -b 10Mgets a rate-limited TCP test, not a UDP test.-C: compatibility mode in iPerf2, congestion control algorithm selection in iPerf3.-T: multicast TTL in iPerf2, output line prefix in iPerf3.-Z: realtime scheduler in some iPerf2 builds, zerocopy send in iPerf3.
When reading someone else's test notes, identify the tool before interpreting the flags.
Interop in Practice
If you manage a fleet of test endpoints, standardize hard. A client that hangs while "Connecting to host..." against a server you know is up is very often an iPerf2 client aimed at an iPerf3 port or vice versa; because the port numbers differ (5001 vs 5201) the connection usually just times out or is refused, and nothing in the error says "wrong tool." Baking the tool name and version into your test scripts' output (both tools support -v) saves that half hour. Where both tools must coexist on one server, run them on their native default ports and document it; nothing conflicts since they never share a socket.
Which Should You Use?
Default to iPerf3. It is what most documentation assumes, its JSON output is far better for automation, its Retr/Cwnd columns make TCP behavior visible (invaluable when troubleshooting slow throughput), and packages are current everywhere.
Reach for iPerf2 in four specific cases: multicast testing (no alternative), a shared always-on test server that must accept concurrent clients, latency-under-load measurement with -e, and multi-10G testing where iPerf3's single thread caps out a core (or use several iPerf3 processes on different ports as a workaround). Nothing stops you installing both; they coexist happily since they use different ports and binary names.
Key Takeaways
iPerf3 is a rewrite, not an upgrade: cleaner, scriptable, single-test-at-a-time, and the right default in 2026. iPerf2 remains actively developed and wins on multithreading, multicast, concurrent clients, and inline latency stats. They cannot talk to each other, so match versions across your endpoints and note which tool produced any number you record. For the full command reference and lab-tested examples of both, start at the iPerf complete guide.
