My connection idles at 30 ms and collapses to 662 ms under load

Every speed test I have ever run on this connection reported it as healthy: roughly 40 Mbps down, roughly 54 Mbps up, latency around 30 ms. The networkQuality tool that ships with macOS reports the same throughput and then adds one figure the others omit, which is what latency does while the link is actually busy. On this line that figure is 640 ms, against 30.6 ms when idle. The connection is 21 times less responsive under the conditions it is used in than under the conditions it is tested in.

21×

Run the test

It is already installed. No download, no browser tab, no account.

networkQuality -s

The -s flag runs the uplink and downlink phases sequentially rather than together, which takes longer but keeps the two measurements from contaminating each other. Each run takes under a minute.

What three runs produced

I ran it three times back to back, on 5 GHz Wi-Fi, with nothing else on the network actively transferring.

Run	Down (Mbps)	Up (Mbps)	Idle latency	Uplink loaded	Downlink loaded
1	41.681	58.736	30.841 ms	590.758 ms	405.672 ms
2	40.812	51.553	30.489 ms	668.164 ms	535.196 ms
3	39.617	51.843	30.457 ms	662.071 ms	322.213 ms
Mean	40.70	54.04	30.60 ms	640.33 ms	421.03 ms

The idle figure is the interesting one before you even look at the load numbers. Across three runs it moved by 0.384 ms total, from 30.457 to 30.841. That is a remarkably stable measurement, and it is the number a conventional speed test would show you.

Now the loaded figures. The uplink mean is 640 ms with a spread of 77 ms between the best and worst run. The downlink mean is 421 ms with a spread of 213 ms, which is half the mean again. The line is not merely slow when busy, it is unpredictably slow when busy.

What the numbers are actually measuring

Throughput asks how much data fits through the pipe per second. Responsiveness asks how long a new, small request waits when the pipe is already full. Those are different questions and a connection can be excellent at one and dreadful at the other.

The mechanism is buffering. Somewhere between this laptop and the far end there is equipment with a queue, and that queue is larger than it needs to be. When a bulk transfer saturates the link, the queue fills with that transfer’s packets. A new request, a DNS lookup, a video call keyframe, a keystroke in an SSH session, arrives at the back of a queue that now takes half a second to drain. Nothing is dropped, nothing is broken, and every byte arrives correctly. It just arrives late.

30.60 ms

This is why Apple reports the result as RPM, round-trips per minute, rather than as milliseconds. Idle, this connection manages about 1960 round trips per minute. Under upload load it manages 93. Expressed as a rate, the collapse is obvious in a way that “30 ms versus 640 ms” somehow is not.

Why the uplink is worse than the downlink

On this line the uplink degrades further than the downlink: 640 ms against 421 ms, despite the uplink having more headroom on paper at 54 Mbps against 40.7 Mbps.

That ordering is common and it makes sense once you know where the buffers are. Downstream congestion happens in provider equipment, which tends to be better provisioned and more actively managed. Upstream congestion happens in the customer premises equipment, in the router or modem sitting in the room, which is where undersized processors and oversized default buffers usually live. The device you own is the one adding most of the delay.

The practical version of this: a large file upload, a cloud backup, or a video call’s outbound stream will damage everything else you are doing more than an equivalent download will.

What this predicts about daily use

A 640 ms responsiveness figure is not abstract. It maps onto specific, recognisable failures.

A video call degrades when someone else in the house starts an upload, even though the bandwidth figures suggest there is plenty spare. A web page that needs six sequential requests to render takes six times the loaded latency, so nearly four seconds of waiting on a connection that benchmarks at 40 Mbps. An SSH session becomes unusable during a file transfer. Each of these is the same measurement showing up in a different place.

None of them would be predicted by the throughput number, which is why the throughput number on its own is close to useless as a description of how a connection feels.

Caveats worth stating

This is one connection, in one apartment in Hyderabad, over Wi-Fi rather than Ethernet. The Wi-Fi hop itself contributes some latency and some variance, and a wired test on the same line would likely produce a lower idle figure and possibly a different loaded one. Three runs is enough to establish that the collapse is real and roughly consistent; it is not enough to characterise the distribution of the loaded figure, which is clearly wide.

The test also cannot tell you where the oversized buffer lives. It measures the end-to-end result. Establishing whether the fault is in the router, the modem or upstream requires testing from different points on the network, which is a different piece of work.

What three runs do establish is that the number every speed test shows, and the number that describes how the connection behaves when you are using it, differ here by a factor of 21. That gap is measurable in under a minute with software that is already on the machine.

What would actually fix it

A responsiveness figure this poor has one broad category of cause and one broad category of remedy.

The cause is a queue somewhere that is larger than it needs to be. When a bulk transfer saturates the link, that queue fills, and every subsequent packet waits behind a backlog that takes hundreds of milliseconds to drain. Nothing is lost, everything arrives, and everything arrives late.

The remedy is active queue management: an algorithm that keeps the queue deliberately short, dropping or marking packets early to signal senders to slow down rather than accepting an unbounded backlog. fq_codel and CAKE are the two commonly available implementations, and routers running OpenWrt, or several consumer models with Smart Queue Management in their settings, offer one of them.

Turning it on costs a few percent of peak throughput and typically improves loaded responsiveness by an order of magnitude. On a connection like this one, where throughput is adequate and responsiveness is not, that is an obviously favourable trade.

Establishing where the queue is

The test measures end to end and cannot attribute the delay. Narrowing it down takes two additional measurements.

# Latency to your own router, while the link is busy
ping -c 20 $(route -n get default | awk '/gateway/ {print $2}')

Run that during a large upload. If latency to your own router climbs into the hundreds of milliseconds, the queue is in your own equipment and you can do something about it. If it stays low while networkQuality still reports poor responsiveness, the queue is upstream and the remedy is a conversation with your provider rather than a setting.

Wi-Fi contributes too, and separating it means testing wired:

route get default | grep interface

A materially better result over Ethernet points at the wireless link, where interference, channel width and distance all add latency that has nothing to do with the line.

The measurement worth repeating

One point this article has stated repeatedly deserves the summary. The idle figure on this connection was stable to within 0.4 ms across three runs. The loaded figures varied by up to 213 ms. Those are not the same kind of measurement, and treating them the same way produces confident conclusions from a single unstable sample.

Idle latency: measure once. Loaded responsiveness: measure at least three times, at more than one time of day, and report the spread rather than the mean alone.