Your Speed Test Says 500 Mbps. Your Calls Still Drop.

A speed test measures throughput. Calls fail because of packet loss, jitter and latency under load — three things it cannot see. Here is how to measure each one and what to do about it.

It is one of the most frustrating situations in home networking. Your speed test reports 500 Mbps down, 40 up, and a ping of 12 ms. By every number you have access to, your connection is excellent. And your video call just froze for the fourth time this hour.

Nothing is wrong with the speed test. It is measuring what it claims to measure. The problem is that throughput is only one of several things a real-time application depends on, and a speed test is structurally unable to show you the others.

Find out why your calls are dropping. The free connection test measures packet loss, jitter and latency under load — not just download speed. It runs in your browser and takes about a minute.

What a speed test measures, and what a call needs

Every row on the left is genuinely useful for answering "am I getting the line I pay for." None of them answers "will this carry a conversation."

Why the speed test cannot see the problem

Three properties of how speed tests work matter here.

It uses a reliable transport, which hides packet loss by design. When a packet goes missing, the protocol notices and retransmits it. The data still arrives; the transfer just takes marginally longer. A connection losing 2% of packets can still report near-line-rate throughput, because retransmission absorbs the damage before it reaches the number on your screen.

Usually that transport is TCP, but the precise mechanism is reliability rather than TCP itself. A speed test running over HTTP/3 uses QUIC, which is built on UDP — and it masks loss identically, because QUIC retransmits too. What matters is whether the protocol resends lost data, not which transport carries it.

It is a bulk transfer, not a real-time stream. A file download does not care whether a particular packet arrives now or 300 ms from now. A voice call cares enormously — audio that arrives late is discarded, because playing it would put the conversation out of sync.

It tests to a nearby server, briefly, on an otherwise idle line. Your call is to a data centre potentially thousands of kilometres away, sustained for an hour, while other devices in the house are doing their own thing.

So a speed test is a good measure of whether you are getting the line you pay for, and a poor measure of whether that line will carry a conversation. Bandwidth is not irrelevant — a genuinely saturated uplink will starve real-time traffic — but when the speed test already looks excellent, bandwidth is rarely the remaining constraint.

The three things that actually break calls

Packet loss

Real-time media deliberately runs over an unreliable channel — typically RTP over UDP — because retransmission is useless to it. A replacement audio packet arriving 300 ms late cannot be played without desynchronising the conversation, so there is nothing to resend into. A lost packet is simply gone. In a voice call each packet typically carries 20 ms of audio, so losing packets means losing fragments of speech — the choppiness everyone recognises.

Modern codecs conceal a small amount of this by interpolating across the gap, which is why light loss is often inaudible. As a practical guideline, loss under about 0.5% usually goes unnoticed, around 1% starts to become audible, and beyond roughly 2.5% conversations get genuinely difficult. Treat those as rough guidance rather than hard limits — the codec in use, the packetisation interval, and above all whether loss arrives in bursts or spread evenly all change the outcome. Forty consecutive packets vanishing is far worse than the same total spread thinly across a minute.

Video degrades differently and more visibly. Video compression encodes most frames as differences from previous frames, so one lost packet can corrupt everything that follows until the next full keyframe — which is why the picture smears or freezes for a second or two rather than glitching for 20 ms.

Because a reliable transport repairs loss before you can see it, a throughput test will not reveal it. To measure loss the way real-time traffic experiences it, you need a test that tracks individual packet delivery — which is what our connection test does over UDP.

Jitter

Jitter is variation in latency between consecutive packets. This is the metric people most often overlook, because it can be terrible while the average looks perfect:

Stable connection          average 20 ms
  20  20  21  19  20  21  20  ms

Jittery connection         average 20 ms
   4  38   6  45   8  34   6  ms

Identical averages. Completely different experience. A single ping figure — which is all a speed test reports — cannot tell these apart.

Receivers cope using a jitter buffer: hold incoming audio briefly, reorder it, play it out evenly. That works until jitter exceeds the buffer, at which point packets arrive too late to use and are discarded — appearing as loss even though the network delivered everything.

Rough thresholds: under 5 ms is good, 5–15 ms fair, above 30 ms disruptive.

Bufferbloat

This is the one that surprises people, because it is caused by something intended to help.

Network equipment has memory buffers to hold packets during momentary bursts. Many consumer routers and ISP devices ship with buffers far larger than they should be. When your uplink saturates — a cloud backup, a large upload, someone else's video call — packets queue in those oversized buffers instead of being dropped.

The signature is unmistakable once you know to look for it:

Idle                     ping   15 ms
Large upload starts      ping   15 → 40 → 120 → 300 ms
Upload finishes          ping   15 ms

Your speed test, run on an otherwise idle connection, will never see this. Your call, competing with a backup, feels like talking over a satellite link.

Watching latency change under load

You can see bufferbloat yourself in about a minute, with no special software.

Start a continuous ping. Windows:

ping -t 1.1.1.1

macOS and Linux:

ping 1.1.1.1

Leave it running, then start a large upload — a cloud sync, a big email attachment, or the upload phase of a speed test — and watch the latency column. If it climbs from tens of milliseconds into the hundreds while the upload runs and drops back the moment it finishes, you have bufferbloat.

Use 1.1.1.1 rather than 8.8.8.8 for this: Google's resolver rate-limits ICMP and can report loss that is not really there. And remember this measures ICMP, which routers sometimes treat differently from real traffic — it is a strong indicator, not a definitive measurement.

Why Zoom, Teams and Meet suffer when downloads do not

The same connection can stream 4K video flawlessly and still ruin a meeting, and the reason is deadlines.

A streaming service buffers ten or twenty seconds ahead. If a packet is lost, there is ample time to fetch it again before that part of the video is needed, so you never notice. A download has no deadline at all.

Zoom, Microsoft Teams, Google Meet, FaceTime, Discord and every VoIP system work under a deadline of roughly 150 ms end to end — beyond that, conversation stops feeling natural and people start talking over each other. There is no room to wait for a retransmission, so anything late is simply discarded. This is why "my internet is fast, Netflix is perfect, but Teams keeps freezing" is such a common and genuinely confusing combination. It is not a contradiction; those two applications are testing entirely different properties of your connection.

How to work out which one you have

Run a full connection test and read the results in this order.

Packet loss above 1%, either direction. A real fault. Which direction matters — loss on upload affects what others receive from you, loss on download affects what you receive. Next step: the guide to proving it to your ISP.

Jitter above 15 ms with acceptable average latency. Usually Wi-Fi interference, a congested local segment, or a shared medium such as cable during peak hours. Test over Ethernet — if jitter collapses to near zero, it was wireless.

Latency fine at rest, high under load. Bufferbloat. Fixable at your end: enable Smart Queue Management (SQM, fq_codel or CAKE) if your router supports it. Shaping works by keeping the queue in your router, where it can be managed, rather than in your ISP's equipment, where it cannot — so set the shaped rate somewhat below your measured line rate. Around 85–90% is a reasonable starting point, but tune it by re-testing latency under load rather than treating any figure as correct.

Everything clean but calls still break. Then measure the path rather than the endpoints — run an MTR test to find which hop degrades, and check the return path, since a fault inbound to you will not show in any outbound test.

Why the numbers disagree with your experience

There is a broader point here worth keeping.

Consumer internet marketing has been built almost entirely around one number, because bandwidth is easy to advertise and easy to compare. That number was genuinely the binding constraint twenty years ago. For most households today it is not — a 100 Mbps connection is sufficient for several simultaneous 4K streams and a video call, and upgrading to 1 Gbps does nothing whatsoever for call quality.

What determines whether real-time applications work is consistency: do packets arrive, and do they arrive on time. Those are different measurements, and they are absent from the number your ISP sells you and the number a speed test reports.

Which is the entire reason a tool like this exists. Measure loss, jitter and latency under load — not just throughput — and the mystery of "fast internet that does not work" usually resolves within a few minutes.

A short checklist

1. Run a full connection test over Ethernet, with nothing else using the connection.
2. Repeat it over Wi-Fi. A large difference means your problem is wireless, not your ISP.
3. Repeat it while a large upload runs. A large difference means bufferbloat.
4. If loss appears in all three, run an MTR to locate which hop is responsible.
5. If the outbound path is clean, test the return path before contacting anyone.

Each step eliminates one layer. By the end you should have enough evidence to narrow the fault down to your device, your Wi-Fi, your router, your ISP's access network, or the wider internet path — and measurements to support whichever conclusion you reach.

Frequently asked questions

Why do my calls drop when my internet speed is fine?

Because speed and call quality measure different things. A call needs packets to arrive consistently and on time; a speed test only measures how much data moves in bulk. Packet loss, jitter and latency under load all break calls while leaving throughput untouched.

Can a speed test detect packet loss?

Generally not. Speed tests run over reliable transports that retransmit lost packets automatically, so the loss is repaired before it reaches the reported figure. You need a test that measures individual packet delivery, such as a UDP-based connection test.

Why does Teams or Zoom freeze when streaming works perfectly?

Streaming buffers many seconds ahead, so a lost packet can be fetched again long before it is needed. Live calls work to a deadline of roughly 150 ms, which leaves no time to recover anything. The same connection can comfortably serve one and fail the other.

What is bufferbloat and how do I test for it?

Oversized buffers in routers and ISP equipment queue packets instead of dropping them, so latency climbs sharply whenever the link is busy. To test: start a continuous ping, begin a large upload, and watch whether latency rises from tens of milliseconds into the hundreds, then recovers when the upload ends.

How much jitter is acceptable for video calls?

Under 5 ms is good, 5–15 ms is usually fine, and above 30 ms is disruptive. Jitter matters independently of average latency — a connection can show an excellent average ping and still be unusable if the individual timings vary widely.

Is Wi-Fi or my ISP more likely to be the problem?

Test both. Run the same measurement over Ethernet and over Wi-Fi; if the numbers improve substantially on a cable, the fault is wireless and your ISP is not involved. Only when a wired test still shows loss is it worth opening a ticket.