Reading a Speed Test Properly: Mbps, Latency, Jitter and Packet Loss
A speed test gives you four numbers, and most people read only one of them. The download figure is the least useful of the four for almost everything a household actually does. Latency, jitter and packet loss — and especially what happens to latency when the connection is busy — determine whether a video call holds together, and they are barely related to the megabits per second on the front of your bill.
The four numbers, and what each one means
Throughput, in Mbps
How much data the connection can move per second when it is fully loaded. Note that this is megabits, not megabytes: divide by eight to get the file-transfer figure your browser shows. A 1 Gbps connection moves about 125 MB per second at best.
Throughput is what matters for large transfers — a game download, a cloud backup, a 4K stream — and almost nothing else. It is a capacity measurement, and capacity is only a constraint when you are using all of it.
Latency, in milliseconds
How long a packet takes to reach a destination and come back. This is the number that governs interactivity. Every request your browser makes, every keystroke in a remote session, every audio frame in a call waits one round trip.
Latency has a hard physical floor. Light in fibre travels at roughly two-thirds of its vacuum speed, so a round trip from Toronto to a server in Frankfurt cannot be much under about 80 ms no matter what you pay. What you can control is everything above that floor.
Jitter, in milliseconds
The variation in latency between consecutive packets. Real-time protocols cope with delay by buffering, but they can only buffer for the variation they expect. High jitter forces a bigger buffer, which adds delay, or produces the choppy, robotic audio that everyone recognises. A connection with 40 ms latency and 2 ms jitter is far better for a call than one with 20 ms latency and 30 ms jitter.
Packet loss, as a percentage
The share of packets that never arrive. TCP hides loss by retransmitting, at the cost of latency and throughput. Real-time media usually does not retransmit — a late audio packet is useless — so loss becomes audible directly. Sustained loss above about 1% is worth investigating; loss that appears only when the link is busy is a congestion symptom, not a line fault.
Bufferbloat: the number your speed test probably hides
Here is the failure mode that explains most “the internet is fast but the call keeps breaking up” complaints.
Network equipment has memory buffers to smooth out bursts. For two decades, manufacturers made those buffers as large as possible, on the assumption that dropping a packet is always worse than delaying it. The result is what the Bufferbloat project defines as “the undesirable latency that comes from a router or other network equipment buffering too much data”.
When someone starts a large upload, the bottleneck — usually your own modem or router, at the point where the fast home network meets the slower access link — fills its oversized buffer with that upload’s packets. Your video call’s next audio frame arrives, joins the back of a queue holding several seconds of data, and waits. Idle latency of 15 ms becomes loaded latency of 800 ms. Nothing is lost; everything is late.
Raising your plan speed does not fix this. It makes the buffer fill slightly more slowly and then behave exactly the same way.
What fixes it
Active queue management. Rather than accepting a queue of arbitrary length, an AQM algorithm watches how long packets are dwelling in the buffer and signals congestion early, so senders back off before the queue grows. The two you will meet by name are both IETF-documented:
- CoDel, Controlled Delay, specified in RFC 8289, which measures the minimum queueing delay over a time window and starts dropping when it stays too high.
- fq_codel, specified in RFC 8290, which combines CoDel with fair queueing so one bulk transfer cannot monopolise the link at the expense of a latency-sensitive flow.
CAKE — Common Applications Kept Enhanced — is the Bufferbloat project’s successor, folding shaping, fair queueing and AQM into a single configuration. It has no RFC, but it has been in the mainline Linux kernel since version 4.19 and is exposed in OpenWrt and several consumer firmwares under headings like “SQM” or “Smart Queue Management”. Enabling it, and setting the shaper slightly below your measured line rate so the queue forms in your router rather than in your ISP’s equipment, is often the single largest quality improvement available to a home network.
Responsiveness: measuring latency when the link is busy
Idle ping is close to useless as a quality metric, because nobody experiences their network idle. The IETF’s IP Performance Measurement working group has been developing a test for exactly this: “Responsiveness under Working Conditions”, currently an active Internet-Draft (draft-ietf-ippm-responsiveness) authored by Christoph Paasch, Randall Meyer and Stuart Cheshire of Apple with Will Hawkins of the University of Cincinnati.
It defines RPM, Round-trips Per Minute: sixty divided by the round-trip time in seconds, measured while the connection is saturated. Higher is better, deliberately, so that the good direction matches the good direction of a speed figure. A link with 100 ms loaded round-trip time scores 600 RPM; one with 1 second scores 60. Apple ships this as networkQuality on macOS, and several web-based tests now report loaded latency or an equivalent grade. If your test tool offers a “latency under load” or “bufferbloat” grade, that number is worth more than the download figure above it.
Why a 1 Gbps plan does not make web pages load faster
Loading a page is not one large transfer. It is dozens of small ones — DNS lookups, TLS handshakes, individual assets — each of which costs at least one round trip before a single byte of content moves. Round trips are latency, not bandwidth.
Cloudflare’s engineering write-up on making home internet faster summarises the research neatly. Google’s 2010 study found that going from 1 Mbps to 2 Mbps improved page load time by nearly 40%, while going from 5 Mbps to 6 Mbps improved it by less than 5%. Later MIT work using FCC data moved that point of diminishing returns up to roughly 20 Mbps. Cloudflare’s own measurements show the latency side of the equation is not saturating at all: for every 200 ms of latency removed, page load time falls by more than a second.
Above roughly 100 Mbps, extra megabits buy you shorter large downloads and nothing else. They do not make a page render sooner, a call clearer, or a game more responsive.
How to run a test that means something
- Test wired. Plug into the router with Ethernet. A Wi-Fi test measures your Wi-Fi, and on a gigabit plan that is usually what you are actually measuring.
- If you must test on Wi-Fi, stand next to the router and use the 5 or 6 GHz network, so you separate the radio link from the access link.
- Close everything else. One device, nothing syncing, no one else streaming, or you are measuring the leftovers.
- Test more than once, at more than one time of day. Shared-medium access networks behave differently at 9 pm than at 9 am. Three runs on a weekday evening tell you more than one run at noon.
- Record all four numbers, plus loaded latency. A single download figure with no context cannot support any conclusion.
- Test to a nearby server for line quality, and a distant one for reality. Your ISP’s own on-net server flatters the connection; it excludes exactly the transit path where problems usually live.
What to do about it
Run one test wired, one on Wi-Fi in the room that annoys you, and compare. If wired is fine and wireless is not, your problem is radio, not your plan. If both are fine while idle but latency climbs into the hundreds of milliseconds when someone uploads, you have bufferbloat, and enabling SQM or CAKE on the router will do more for your household than doubling your speed tier. And if the download number is already comfortably above 100 Mbps, stop optimising it — the money is better spent on latency, on wiring, or on nothing at all.