Most arguments between a subscriber and a provider are really arguments about measurement. The customer has a screenshot showing 40 Mbps; the provider has a line that syncs at 300. Both can be telling the truth, because a speed test measures the whole path from a particular device through a particular Wi-Fi link to a particular server, and any one of those can be the limit. Here is how to run a test whose result is worth arguing about — and what the numbers mean once you have them.
The method
- Use a cable. Connect a laptop or desktop directly to the router or ONT with Ethernet. Wi-Fi is the single most common bottleneck and it is not what you are trying to measure. If the machine only has Wi-Fi, say so when you report the result.
- Check the port can carry the plan. A gigabit plan cannot be demonstrated through a 100 Mbps network port, an old cable, or a USB adapter that negotiates at 100 Mbps. Confirm the link speed in your operating system’s network settings before blaming the line.
- Quiet the network. Pause backups and downloads, disconnect what you can. One busy device elsewhere in the house can halve the result — and if it is uploading, it will drag the download down with it.
- Pick a nearby server and keep it. Comparisons are only meaningful against the same server. Note which one you used.
- Run it three times, at three times of day. One test is an anecdote. A morning, afternoon and 9 PM set is evidence — and the shape of that curve is what distinguishes evening congestion from a genuinely faulty line.
- Record everything. Time, date, server, wired or wireless, and all four numbers below. A support ticket with that in it gets a different response from one that says “internet slow”.
What the numbers actually mean
Download and upload throughput
Measured in megabits per second (Mbps). The most common source of confusion is the unit: file managers and browsers usually report megabytes per second (MB/s), and there are eight bits in a byte. A genuine 100 Mbps connection delivers a maximum of about 12.5 MB/s, and in practice a little less once protocol overhead is accounted for. A download running at 11 MB/s on a 100 Mbps line is a connection working correctly, not one running at a tenth of its rating.
Note also that speed tests generally open several parallel connections. That is the right way to measure a link’s capacity, but it means a single-stream download from one distant server may legitimately be much slower than your test result without anything being wrong locally.
Latency (ping, round-trip time)
How long a packet takes to reach a destination and come back, in milliseconds. Latency is bounded by physics — light in fibre travels at roughly two-thirds of its speed in vacuum, which is about 5 microseconds per kilometre each way — so distance sets a floor no amount of bandwidth can lift. Within a city, single-digit to low-teens milliseconds is a healthy figure on fibre; a few tens of milliseconds to servers elsewhere in India; over a hundred to servers on another continent, and that last one is not your provider’s fault.
Latency, not bandwidth, is what makes browsing feel snappy and video calls feel natural. Doubling a 200 Mbps plan to 400 changes almost nothing about how a web page loads; halving latency changes it a great deal.
Jitter
The variation in latency from packet to packet. A connection with a steady 30 ms round-trip is far better for real-time media than one averaging 15 ms but swinging between 5 and 60. Voice and video applications hide jitter by holding incoming audio in a buffer before playing it, which trades delay for smoothness; when jitter exceeds what the buffer can absorb, you get the familiar robotic, chopped speech. Under about 5 ms is excellent; consistently above 30 ms will be audible.
Packet loss
The percentage of packets that never arrive. This is the most damaging of the four and the least reported. TCP hides loss by retransmitting, which shows up as sluggishness rather than as an error, and real-time protocols cannot retransmit at all — lost audio is simply gone. Anything sustained above roughly 1% will be noticeable on calls; above 2–3% makes them unusable. Zero is the target on a wired fibre connection.
Tools worth knowing
- Browser speed tests — fine for throughput and rough latency, and universally understood by support desks. Prefer one that also reports loaded latency.
- ping — built into every operating system. Run a long one (a few hundred packets) to a nearby address and read the summary line: it gives you minimum, average, maximum and loss in a single shot.
- mtr / traceroute — shows every hop along the path and the loss at each. Invaluable for locating where a problem is. One caveat that trips people up: routers often deprioritise replies to traceroute probes, so an intermediate hop showing loss while the final destination shows none is normal and is not a fault.
- iperf3 — measures throughput between two machines you control, removing the public internet from the equation entirely. The right tool for proving whether a problem is inside your network or outside it.
Reading the results honestly
A few patterns and what they usually mean:
- Wired fast, Wi-Fi slow. Your Wi-Fi is the limit — not the line. Worth reading what actually improves a Wi-Fi network, because it is rarely a faster plan.
- Fast all day, slow at 9 PM. Congestion on a shared segment.
- Local server fast, everything international slow. Transit or peering, not your access line.
- Throughput fine, calls bad. Look at jitter, packet loss and loaded latency. Throughput was never the problem.
- Slow and flat at every hour. A line or provisioning fault. This is the one to escalate.
On that last case, it is worth knowing that TRAI’s broadband quality-of-service benchmark expects a subscriber to receive at least 80% of the subscribed speed measured from the ISP node to the user. Consistently receiving a third of what you pay for, on a wired test, repeated across days, is not a normal outcome — and a log of timestamped results is what turns that from an opinion into a complaint.