Somebody is always disappointed by 940. They paid for 1000, the test says 940, and they want their missing 60 back. The 60 was never data - it was the envelope the data travels in.
Every iperf3 user eventually asks the same question: why does my gigabit network test at 940 instead of 1000? The short answer is overhead - and it is not a fault, a setting or a conspiracy. This guide does the honest maths for each link type, so you can tell a healthy result from a real problem at a glance, and then shows how to keep dated logs of your tests, because a saved result with a date on it settles arguments that memory never will.
Every packet on Ethernet carries more than your data: the Ethernet frame headers, the IP header, the TCP header, the gap between frames, and the acknowledgement traffic coming back. On a 1 Gbps wire those non-data parts add up to roughly 5 to 6 percent - permanently, by design, on every network on Earth.
So the maximum useful data rate is about 940 to 949 Mbps, and Windows file copy will show the same story in its own units: a full-speed gigabit copy runs around 110 MB/s, not 125. If your iperf3 receiver line sits at 940, your network is not 6 percent broken. It is finished - go and find a real problem somewhere else.
Trouble has a different shape. Around 94 Mbps on gigabit hardware: a link negotiated at 100 Mbps - the classic silent fallback. Wildly swinging per-second lines with heavy retransmits: loss and congestion. One direction at 940 and the other at 400: a one-sided fault, covered in our reverse mode guide.
Learn those three shapes and you can read any result in seconds: near the ceiling means healthy, stuck at a tenth means a fallback link, unstable means the path is dropping or fighting.
When a provider or vendor says your network is fine, or a user says it was fast last month, memory argues back and loses. A simple habit fixes this: after each test session, save the result with its date. In Command Prompt, run the test and send the output to a file: iperf3 -c 192.168.1.10 >> C:\iperf3\results.txt - first write the date into that file with echo %date% %time% >> C:\iperf3\results.txt, so every block of results carries its own timestamp.
Keep the server address and the test direction in the same note. Six weeks of dated entries like that will show a pattern no single test can: failing every weekday at 10 AM, fine on Sundays, dead since the day the new switch went in. Patterns are evidence. One-off screenshots are opinions.
A fairness note, because logs cut both ways. iperf3 results prove the state of your local path. If you are arguing with an internet provider, dated iperf3 logs showing a clean 940 locally plus dated internet speed tests showing the collapse together make the honest case: the fault is not inside your building - whatever is wrong sits beyond your router.
That is also why you test before complaining: if the local logs show 94 Mbps and retransmit storms, the provider is innocent this time, and the logs just saved you a very awkward phone call.
The complete iperf3 setup and live testing, step by step, in the video.
Watch Full VideoYes, for practical purposes. Ethernet, IP and TCP overhead consumes roughly 5 to 6 percent of the raw 1 Gbps, leaving about 940 to 949 Mbps for actual data. Every healthy gigabit network on Earth tests in that band with iperf3.
That depends on the path. Over Wi-Fi, 500 may be an excellent result. On a wired PC-to-server path, 500 is worth investigating: try -P 4 to see if parallel streams reach 940, test reverse with -R, and narrow it down hop by hop. A stable wired 500 with no explanation is a real finding.
Add >> followed by a file path to the end of the command, for example iperf3 -c 192.168.1.10 >> C:\iperf3\results.txt. Write the date and time into the file first with echo %date% %time% >> C:\iperf3\results.txt, so each saved test keeps its own timestamp.