One test says 620 Mbps. Another, with one extra flag, says 940. Neither is lying - they are answering slightly different questions, and knowing which question you asked is the skill.
iperf3 prints more than one number, and beginners often grab the wrong one. This guide walks through the output line by line: the per-second rows, the sender and receiver summary, the retransmit counter, and what changes when you add -P for parallel streams. By the end you will know which figure to quote - and when a low single-stream number is the honest truth about a user's real experience.
Ignore the per-second rows at first - they show stability, not the verdict. The verdict is the summary at the end, and there are two versions of it. Sender counts what the sending PC pushed out. Receiver counts what actually arrived. For TCP tests, quote the receiver line. Data that left but never landed is not speed anyone can use.
If the two lines are close, the path is clean. If the sender is much higher than the receiver, packets are dying on the way - and iperf3 usually tells you that too, in the next column.
Many iperf3 builds show a Retr column for TCP tests: how many packets had to be sent again because they were lost. A handful over a long test is normal background noise. Hundreds or thousands means the path is dropping data - a failing cable, a duplex mismatch, a sick switch port, or congestion.
A test can show decent Mbps and still be a bad path if retransmits are high, because real applications feel every loss as a pause. Speed and health are two readings, not one.
A normal iperf3 test uses one TCP stream - one connection, like one file copy. With iperf3 -c 192.168.1.10 -P 4, the client runs four streams at once and the SUM lines add them up.
Why bother? A single stream can be limited by things that are not the wire: one busy CPU core, TCP behaviour over distance, or a per-connection limit somewhere in the chain. If one stream gives 620 Mbps but four streams give 940, the path is a full gigabit path - the limit was per-connection. If four streams still total 620, the path itself is the limit, and you go hunting hardware. Same test, two different diagnoses - that is the real value of -P.
Here is the honest part people skip. If the user's complaint is one file copy is slow, the single-stream result is the one that matches their life, because their copy is one stream. Quoting the 940 SUM at them would be technically true and practically dishonest.
Use parallel streams to find out where a limit lives. Use the single stream to describe what the user gets. And if single-stream is low but the SUM is full speed, the fix is usually in settings, drivers or the application - not in new cables.
The complete iperf3 setup and live testing, step by step, in the video.
Watch Full VideoThe receiver line for TCP tests. It is the rate at which data actually arrived at the other PC. The sender line can flatter the result because it counts everything the PC transmitted, including packets that were lost and had to be resent.
Probably not faulty - limited per connection. The wire and switch can clearly carry gigabit. Something is capping one stream: CPU load on an endpoint, TCP window behaviour over the path, or a per-flow limit. For most office uses the path is healthy; for a single big transfer, that per-stream number is still the user's real speed.
The default 10 seconds is fine for a quick verdict. For a number you will act on - replacing hardware, arguing with a vendor - run 30 seconds with -t 30, repeat it twice, and test at a realistic time of day. A busy-hour reading is worth more than a midnight one.