Why Ookla doesn't predict Zoom call quality

Most people understand "broadband speed" the way we understand mileage on a car: a single number, bigger is better. When the ISP says "500 Mbps" and Ookla agrees, the contract feels honored. So when a Zoom call breaks five minutes after that test, there's a kind of cognitive dissonance — the test said it was fine.

The test wasn't lying. It just wasn't testing what you actually use the connection for.

An Ookla speed test runs roughly 8–32 parallel TCP connections to a nearby server, pushes as much data as possible through them for about ten seconds, and reports the peak throughput it observed. The number you see is a brag-worthy snapshot of "how fast can this link get if absolutely nothing else is going on."

It's the equivalent of asking how fast a sprinter can run for 100 metres with the wind at their back. Useful, but it doesn't tell you whether they can deliver a 30-minute presentation.

Real-time communication apps — Zoom, Microsoft Teams, Google Meet, FaceTime, Discord voice — don't run sprints. They run an entirely different protocol with fundamentally different demands.

A typical 720p video call generates a steady stream of small UDP packets at a fixed cadence — usually around 100–600 kbps, depending on the codec and resolution. That's less than 1% of your "500 Mbps" link.

But three things matter much more than the bandwidth:

• Jitter — the variance in packet inter-arrival time. If 50 ms of audio takes 50 ms to arrive most of the time but occasionally takes 200 ms, you hear robotic, garbled audio. Above ~30 ms of jitter, every major RTC platform starts complaining.
• Packet loss — the fraction of UDP packets that don't arrive. Above 1% loss, Zoom and Teams start showing "unstable connection" warnings. Above 2%, calls become unintelligible.
• Bufferbloat — extra latency added when the link is busy. A modem buffer that adds 200 ms of delay under load won't show up on a quiet Ookla test, but it will turn your real-time conversation into walkie-talkie territory.

None of these metrics appear in your Ookla result. None.

Here's a scenario that plays out millions of times a day:

"My ISP gives me 500 Mbps down, 100 up. Ookla agrees. But every Zoom call after 4pm is unwatchable."

What's actually happening: your kids are streaming Netflix, your spouse is uploading a Dropbox sync, you've got a backup running, and your router's outbound buffer is filling up. The buffer holds roughly 800 KB of pending packets — about 200 ms worth of upstream bandwidth — and every voice packet from your meeting has to queue behind that backlog.

200 ms of bufferbloat on a 50 ms link is catastrophic for a call. Your voice arrives 200 ms late. Their voice arrives 200 ms late on the way back. You start talking over each other. Audio drops out. Eventually someone says "hey, your connection is unstable."

Ookla never sees this because Ookla runs on an idle link with the wind at its back.

Because it's the only number ISPs can advertise. Bufferbloat depends on the modem you bought, the QoS settings on your router, the satellite hops in your mesh, and the exact pattern of background traffic in your house at 4pm. The ISP can't put any of that on a billboard.

So they sell you peak Mbps. The marketing department wins. Your video call still glitches.

If you want to know how a call will go, you need to measure four things on a loaded link, the way Zoom uses it:

1. Loaded latency — round-trip time while data is moving, not while idle.
2. Jitter — variance in arrival time, not just average.
3. Packet loss — at the UDP level, not TCP retransmits.
4. Bufferbloat — loaded RTT minus idle RTT. The number your router can't admit to.

This is what StabilityPulse measures. We open a real WebRTC peer connection through a relay — the same kind Zoom and Meet use — and stream a synthetic video for 30 seconds. The four numbers above appear in your browser, scored 0–100, with a separate readiness verdict for Zoom, Teams, and Meet.

We didn't invent this. RTC engineers have been measuring it this way for a decade. We just built a version your IT team and your dad can both run in 30 seconds without installing anything.

Run the test once on Ethernet, once on Wi-Fi. The two scores will likely surprise you. The fix is usually cheaper than upgrading your plan.