Private browser-based analyzer
iperf3 Result Analyzer
Paste iperf3 JSON or terminal output to compare sender and receiver throughput, retransmits, packet loss and nominal-link efficiency.
Prefer JSON when you can
Run iperf3 -c SERVER_IP --json for machine-readable TCP output. Repeat with -R because upload and download paths can behave differently. For multi-gigabit testing, parallel streams such as -P 4 can reveal whether one TCP stream is the limiting factor.
How to read efficiency
Efficiency is receiver throughput divided by the nominal link rate. A healthy 1GbE large-stream TCP test often lands around 90–94%, but that is a diagnostic starting point rather than a universal pass mark. Wi-Fi, WAN latency, encryption, CPU limits, small buffers and retransmissions can reduce it.
iperf3 measures the network path, not SMB/NFS file-copy speed. Storage, filesystem metadata, signing and antivirus can make application transfers slower.
Use repeatable tests
- Use the same server, cable, switch port, duration and stream count.
- Record both directions and at least three runs.
- For UDP, choose a target bitrate deliberately and inspect packet loss and jitter.
- Save raw output; a screenshot alone can hide command options.
Our EQi12 network report combines controller identity, link behavior and SMB copies; use this analyzer for standardized iperf3 evidence alongside those application tests.
Frequently asked questions
What is a good iperf3 result for Gigabit Ethernet?
A healthy 1GbE TCP test typically shows 900–940Mbps receiver throughput (90–94% efficiency) with zero or near-zero retransmits. Anything below 800Mbps usually indicates a cabling, driver, or configuration issue worth investigating.
Why is my reverse (-R) test slower than the forward test?
The reverse direction tests the server’s upload path and the client’s download path. Asymmetric hardware, different NIC drivers, or a slow server CPU can cause the reverse direction to underperform. Always test both directions.
How many parallel streams should I use?
Start with one stream to measure single-connection performance. For multi-gigabit links (2.5GbE, 10GbE), use -P 4 or more to see whether a single TCP stream is the bottleneck. If parallel streams significantly increase throughput, the limit is per-stream, not the link itself.
Does iperf3 measure file-copy speed?
No. iperf3 measures raw network throughput between two endpoints. Real file-copy speed (SMB, NFS) is typically 10–30% slower due to filesystem metadata, protocol overhead, antivirus scanning, and storage speed. Use iperf3 to verify the network path, then test actual file copies separately.
What does a high retransmit count mean?
Retransmits indicate packets that were lost or corrupted and had to be resent. A few retransmits over a 10-second test are normal. Hundreds or thousands suggest a bad cable, faulty switch port, duplex mismatch, or network congestion.
Should I use TCP or UDP for testing?
Use TCP for most home-network testing—it reflects real-world file transfers and streaming. Use UDP to test raw link capacity, jitter, and packet loss at a specific bitrate. UDP tests require setting a target bitrate with -b.