The test says the network is fast, but the user still cannot pull files down at speed. You may have measured the road in the wrong direction.
Direction is the most quietly misunderstood part of iperf3. In a normal test, the client sends and the server receives - so the number describes the path from the client to the server. But a user opening files from a server lives in the opposite direction: the server sends, the user receives. The -R flag flips the test so you measure that real direction - and the two directions do not always agree.
With iperf3 -c 192.168.1.10 -R, the client still starts and controls the test - but now the server sends the data and the client receives it. Nothing moves physically; you keep sitting at the client PC. The flag simply reverses who fills the pipe.
That makes -R the download test. If a user says pulling files from the server is slow, this is the number that speaks for their experience, not the default one.
A network path is not perfectly symmetric. Each direction crosses the same cables, but the sending and receiving hardware differs at each end, and faults are often one-sided: a damaged cable pair, a port negotiating badly in one direction, a network card with a failing transmit side, or congestion created by other traffic flowing one way.
Wi-Fi makes asymmetry normal - a laptop's small radio sends weaker than the access point's, so upload and download genuinely differ. On wired gigabit, though, a big gap is a clue, not a shrug.
Run both tests back to back, same machines, same minute: iperf3 -c 192.168.1.10 then iperf3 -c 192.168.1.10 -R. Read the receiver line of each. For a longer, steadier look add -t 30 to both.
Write the two numbers down with the direction labelled - "PC to server" and "server to PC". Unlabelled screenshots of a single direction are how the wrong part gets replaced. If only one direction is sick, swap the cable and the switch port first: they are the cheapest one-sided suspects, and they are guilty surprisingly often.
Fast up, slow down, on a wired link usually points at the server's sending side or the return path: the server's cable, its switch port, its network card, or a busy server disk masquerading as a network problem during real copies - though note iperf3 itself does not touch the disk, so a slow -R with a fast forward test is genuinely network-shaped.
Slow in both directions at the same ceiling, like a flat 94 Mbps, is different: that is a link negotiated at 100 Mbps, and no flag will fix it. Direction testing separates these two stories in under a minute - which is exactly why it belongs in every test routine.
The complete iperf3 setup and live testing, step by step, in the video.
Watch Full VideoNo settings change. The server just sends instead of receives for that one test, under the client's control. You run the same server command, iperf3 -s, and add -R only on the client side.
You most likely measured the upload direction from the user's PC. Run the same test again with -R. If the reverse result is low, you have reproduced the user's problem and can start swapping the one-sided suspects - cable, switch port, server network card.
Close, yes - both should land near 940 Mbps on a healthy wired path. Small differences are normal. A large, repeatable gap in one direction is evidence worth chasing, especially when it matches a user's complaint.