Why Speedtest.net Can't Help You Here
Online speed tests measure one thing: the path between your device and the test provider's nearest server. That tells you about your internet connection — it tells you nothing about the switch, cable, Wi-Fi link, or WAN circuit between two machines on your own network. If the file server feels slow from the office floor, Speedtest.net is testing the wrong path entirely.
To measure a specific link, you need a tool at both ends of it: one machine acting as the server, one as the client, with controlled traffic between them.
Why Copying a File Is Not a Speed Test
The classic move — drag a big file across and watch the transfer dialog — produces numbers that are almost meaningless for network diagnosis:
Disk I/O is in the path — you are benchmarking the slowest of the source disk, the destination disk, and the network.
Protocol overhead varies — SMB tuning, encryption, and signing can halve apparent speed without the network being at fault.
Caching distorts everything — operating systems cache aggressively, so repeat runs of the same copy report very different numbers.
A proper throughput tool sends generated traffic straight from memory to the network stack, isolating the thing you actually want to measure.
The Proper Method: Server and Client
Every serious throughput tool — iperf3, ntttcp, Litmus — works the same way:
Start a server on the machine at the far end of the link you care about.
Run a client on the near machine, pointed at the server's IP address.
Read the results — sustained throughput, plus (with the right tool) latency, jitter, and packet loss.
Here is the whole process with Litmus, which is free and runs natively on Windows and Linux:
On the remote machine (server):
Linux: download litmus-x64, then run: ./litmus-x64 -s
Windows: run Litmus.exe and start it in server mode
On your machine (client):
Run a 60-second test: ./litmus-x64 -c 192.168.1.100 -t 60
Or test both directions at once: ./litmus-x64 -c 192.168.1.100 --bidir
Litmus reports throughput (average, min, max), idle and loaded latency, jitter, per-packet loss, and a CRC32 integrity check — then grades the link A–F and can generate a PDF report with --report.
What Good Results Look Like
Gigabit wired LAN — expect roughly 940 Mbps of TCP throughput; that is the practical ceiling once protocol overhead is paid. Latency should sit under 1 ms.
Wi-Fi — far more variable; large gaps between the link rate your laptop claims and measured throughput are normal, but big jitter or loss numbers are not.
WAN links — compare measured throughput against what you are paying for, and watch loaded latency: a link that holds its latency under full load is a healthy link.
If you see throughput well below expectation, the usual suspects are a duplex mismatch, a cable negotiated down to 100 Mbps, an overloaded uplink, or Wi-Fi where you assumed wire.
Make It Repeatable
One-off numbers are anecdotes. The value comes from testing the same link the same way over time — after changes, before handovers, during disputes. Litmus supports JSON output and headless mode on Linux, so scheduled tests via cron are a one-liner, and the --certify mode runs a full TCP/UDP test matrix with a PDF report you can file as evidence.
Download Litmus free from our tools page, and you can have your first answer in the next five minutes.
Written by Ewan Macpherson
Founder & Lead Network Consultant
Ewan has spent over 15 years designing, building, and operating enterprise networks across Australia. More about the team.
Need Help With Your Network?
Our experts are ready to help you tackle your network infrastructure challenges.
Get in Touch