Your speed test lies.
Measure responsiveness instead.

The lie of the big number

Every speed-test site opens with a gauge. It spins up, it lands on some impressive figure (480 down, 510 down, 940 down if you are on fibre) and that number becomes the story. The story is almost always wrong. Not dishonest, exactly. Just the wrong question, answered precisely.

Throughput is a capacity measurement: how much water the pipe can move when nothing else is happening. The problem is that real networks almost never look like "nothing else is happening." Real networks look like a family video call, a cloud backup, a Slack sync, a software update, and a kid watching cartoons, all at once. What you care about in that scene is not the total gallons per minute. You care whether your voice packet can cut the queue and arrive on time.

That second question is responsiveness, and for twenty years we have barely had a way to measure it in a browser. We have one now. It is built into macOS. You have never been told about it.

What is bufferbloat, in one paragraph

Every router and modem between your laptop and the internet has a buffer: a little bit of memory where packets wait their turn. When the link in front of the buffer is slower than the link behind it (your 40 Mbps uplink behind a gigabit LAN, say) the buffer starts to fill. Vendors made these buffers absurdly large, because dropping packets feels like a bug. But an over-large buffer holds your Zoom voice packet behind every other packet that showed up a millisecond earlier. The pipe is moving plenty of bytes. The bytes that matter are just waiting in line. That delay (measured in hundreds of milliseconds during load) is bufferbloat. It is why your speed test passes and your call falls apart.

Enter RPM: Round-trips Per Minute

In 2021, Apple's networking team proposed a plain-language metric for this: RPM, or Round-trips Per Minute. The idea is almost embarrassingly simple. While the pipe is saturated (you are downloading and uploading at full tilt) count how many full request/response round-trips you can complete in a minute. A responsive network manages thousands. A bloated one drops into the low hundreds. Same 500-Mbps pipe either way.

Apple shipped a tool for this in macOS Monterey. It is called networkQuality, it lives at /usr/bin/networkQuality, and if you open a Terminal and run it you will see something like this:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

Read that output carefully. The pipe is fat, nearly half a gigabit down. The responsiveness is medium. 540 round-trips a minute works out to about nine per second: your voice packet waits roughly 111 ms on a loaded network, versus 18 ms when idle. That gap is the entire reason your call sounds fine when nobody else is home and ruined when the whole family is streaming.

High, Medium, Low, what do those mean?

Apple buckets RPM into three human-readable categories:

• High, 2,000 RPM and up. The network is responsive. Real-time work (calls, gaming, collaborative editing) will feel crisp regardless of what else is running.
• Medium, roughly 600–2,000 RPM. The network is usable, but interactive apps will feel laggy under load. This is where most home networks sit during prime time, and it is where the complaints come from.
• Low, under 600 RPM. The buffers are full. Voice calls will drop, video will freeze, keystrokes in an SSH session will arrive in batches. No amount of extra bandwidth will fix this until the buffers drain.

Why a speed test cannot see this

A speed test measures only the easy half of the problem: idle throughput, usually in a short burst, usually over a connection your ISP has learned to prioritise. It tells you what your pipe can do when the pipe is lightly loaded, and it never asks the follow-up question about latency during load. Bufferbloat is by definition invisible to that test, because the test is the load, there is no other traffic to queue behind.

The consumer-facing symptom is familiar. The ISP tech comes out, runs the speed test, it passes, and you are told the connection is fine. The next video call still stutters. The tech did not lie. They measured the wrong thing.

The RPM test in practice

Apple's networkQuality is elegantly brutal. It opens several parallel connections to CDN endpoints, saturates them in both directions, and then times how quickly a small HTTP/2 request and response pair can complete while the saturation is happening. That is the RPM value. The capacity measurements come along for the ride, which is why the tool reports all three numbers from a single run.

The test takes about fifteen seconds. It hammers your link, so do not run it during a call. It also reveals things your ISP would rather you not see: Wi-Fi channels interfering with neighbours, a router with a firmware bug that doubles queue depth, a VPN that adds 200 ms of latency to every round-trip. You will discover, very often, that the weak link is not your ISP. It is something in your own house.

What to do when RPM is Low

There is no single fix, but the checklist is finite:

1. Test wired first. Plug an Ethernet cable into the Mac and re-run networkQuality. If RPM jumps to High, your problem is Wi-Fi, congestion, channel overlap, or distance, not the ISP.
2. Turn on Smart Queue Management. Routers that support SQM, CAKE, or fq_codel will flatten bufferbloat dramatically. A $100 router with fq_codel enabled will beat a $600 router without it.
3. Cap your upload. If SQM is unavailable, throttle your Mac's upload to about 90 % of the uplink capacity you measured. That single change prevents your own uploads from filling the buffer and starving your downloads of return-path acknowledgements.
4. Replace the ISP's modem-router combo. Many ISP-issued units are configured for throughput benchmarks, not responsiveness. Putting the ISP unit in bridge mode and running your own router in front of it is the single biggest RPM improvement most people will see.

Three stubborn myths

"More bandwidth will fix it." Sometimes, mostly no. If your uplink is already being saturated by a single backup, upgrading from 40 to 100 Mbps up will help. But if the buffer is the actual culprit, you will hit the same ceiling twice as fast and the symptoms will return. The fix is draining the queue, not enlarging the pipe in front of it.

"My ping is 12 ms, so I am fine." Ping measures idle latency: how long a packet takes when nothing else is in the way. Bufferbloat only shows up under load. An idle ping of 12 ms on a bloated link routinely turns into a 350 ms loaded ping. Run ping in one terminal and a big upload in another, and you will see it happen in real time.

"The ISP already optimised for this." Some do. Many do not. The engineering is not hard, but the commercial incentive points the other way: a network tuned for speed-test wins markets that shop on throughput gauges. Responsiveness rarely appears on a marketing page.

Where WiFi & IP Info fits in

We put the networkQuality engine one click away in the menu bar. The Pro tier's Network Quality panel runs the same Apple test, surfaces uplink / downlink capacity, reports the RPM bucket and the base-RTT baseline, and then, crucially, keeps a log. You can click "run again" once an hour for a week and see the pattern: High on weekend mornings, Medium during dinner, Low when the kids come home from school. That graph is what gets the ISP to actually do something, because reproducibility is what turns a complaint into a ticket.

Pair it with the app's Latency History chart and the Connection Log, and you can send your provider a thirty-second ticket that reads: "RPM drops from 2,400 to 410 between 18:00 and 21:00 local, correlated with a three-times-higher median RTT to your own gateway. Attaching CSV." That is a very different conversation than "my internet is slow."

The short version

Your speed test measures capacity. Capacity is real, and occasionally it is the problem. Most of the time, though, the problem is responsiveness: whether your traffic can get in and out promptly while the pipe is busy. RPM is the metric for that. Apple built a first-class tool to measure it. We put that tool in your menu bar, and we keep the history.

If you were going to remember only one sentence from this page, make it this one: bandwidth is how big the road is; responsiveness is how long you wait at the lights. Both matter. Only one of them is on your speed-test page.