Latency and Jitter: The Numbers Behind a Bad Video Call
Speeds and reliability

Latency and Jitter: The Numbers Behind a Bad Video Call

8 min readJun 12, 2026

The call starts well. Then one participant’s face freezes for two seconds, the audio continues without them, and the meeting carries on around a gap. The household’s speed test reads six hundred megabits. Nobody in the room believes the number, and everybody blames the connection.

Throughput and responsiveness are different properties, and only one of them appears in advertising. Latency and jitter explain most of what feels wrong on a fast connection, and both can be measured with tools that cost nothing.

What is latency?

The time a packet takes to travel to a destination and back, measured in milliseconds. It is a function of distance, the number of networks in the path, and the queuing that happens at each hop. On a fiber line the base figure is set mostly by geography.

For a video call, anything under about a hundred and fifty milliseconds is comfortable. Above two hundred and fifty, conversation starts to overlap as participants adapt to the delay without noticing they are doing it.

What is jitter?

The variation in that time from packet to packet. A connection with a steady sixty milliseconds is better for calls than one that averages forty but swings between twenty and a hundred and twenty. Jitter is what produces the robotic audio and the frozen frames.

Most speed tests do not report jitter at all, which is why a household can have an excellent score and a terrible call. Measuring it requires a tool that samples repeatedly rather than once.

What causes jitter?

Queuing, mostly. When a link is saturated, packets wait in buffers whose depth varies with the traffic, and the waiting time becomes the jitter. Wi-Fi adds its own variation, because the radio medium is shared and retransmissions are invisible to the user.

Congestion at a single hop is enough. A household with a perfectly provisioned line can still see jitter if one device is uploading continuously and filling the upstream buffer.

What is bufferbloat?

The specific failure where an oversized buffer holds packets so long that latency climbs into the hundreds of milliseconds under load. The connection is not losing data, it is holding it, and the effect on real-time traffic is worse than a small amount of loss would be.

The remedy is queue management on the router, which most modern firmware offers under names like smart queue or traffic shaping. Setting it to slightly below the plan’s speed is the usual configuration and it often transforms call quality.

Why does the call degrade when someone uploads?

Because the upstream saturates first. Residential lines have less capacity in that direction, and a backup or a photo sync can consume all of it, which queues the acknowledgements that every call depends on. The download figure is untouched and entirely irrelevant to the problem.

Limiting the upload rate of backup software to half the available upstream is the standard fix. It costs nothing and it is almost never done.

Does Wi-Fi add latency?

Yes, and variably. A strong signal on an uncongested channel adds a few milliseconds. A weak signal at the edge of coverage adds retransmissions, which can add tens of milliseconds and a large amount of jitter. The difference between a wired and a wireless call is often audible.

Where a call matters, a cable is the answer. Where it is not practical, a dedicated access point near the working room is the next best thing.

How is latency measured properly?

With a repeated ping to a stable destination, ideally the server the call actually uses, over several minutes. A single ping measures one moment; a run of a hundred shows the distribution, which is what matters for real-time traffic.

Recording the minimum, average and maximum is enough. A maximum several times the minimum is a jitter problem regardless of what the average says.

Does the plan’s speed affect latency?

Only indirectly, and mostly at the point where the line saturates. A faster line takes longer to fill, so the queuing starts later, which makes a fast connection feel responsive under light load. Once saturated, a fast line with a deep buffer can be worse than a slow one with good queue management.

This is why a household can upgrade and see no improvement in call quality. The constraint was never capacity, it was the queue.

What about satellite and mobile?

Satellite has a long path to travel, so the base latency is high regardless of throughput, and geostationary systems add several hundred milliseconds before any queuing. Low-earth-orbit systems reduce it substantially and remain higher than fiber. Mobile varies with the cell and the load.

For calls, latency matters more than bandwidth, so a modest fiber line usually beats a fast satellite one. That comparison surprises people who compare on megabits alone.

Can a VPN improve latency?

Occasionally, where the default route is poor and the VPN’s path is better. Usually not, because the tunnel adds a hop and encryption overhead. The improvement, when it happens, is a routing accident rather than a feature.

Testing with and without the tunnel is the only way to know. Where the VPN improves things consistently, the provider’s routing is worth mentioning in a support call.

Does the router’s processing add delay?

Marginally, in normal use, and significantly when a cheap router is asked to do heavy work: intrusion detection, deep packet inspection, or a large number of simultaneous connections. A router running at its processing limit introduces delay that looks exactly like network jitter.

Turning off features that are not needed is a free test. Where the delay disappears, the router was the cause and the plan was never at fault.

How should a call problem be diagnosed?

Three steps. Test wired, test at the time of day the problem occurs, and test with the backup software paused. Those three conditions isolate most cases into line, congestion or local equipment within an hour.

Then write it down. A support agent can act on a sequence of measurements with times attached, and cannot act on a description of a frozen face.

What are the thresholds worth remembering?

Under fifty milliseconds is excellent for calls and gaming. Under a hundred and fifty is good. Under three hundred is workable with occasional overlap. Jitter above thirty milliseconds is noticeable, and above a hundred it makes conversation difficult regardless of the average latency.

Those four numbers are enough to interpret any measurement a household is likely to take. They are also enough to recognise a provider’s claim that everything is within specification.

Is a higher tier ever the fix?

Rarely for latency alone, sometimes for congestion. Where the line is saturated every evening because the household’s usage exceeds the plan, more capacity delays the queue and improves everything. Where the line is idle and the calls still stutter, the problem is local and a new plan will not help.

The distinction is measurable, which is the useful part. An evening of testing either justifies the upgrade or prevents it.

Why does this subject get so little attention?

Because megabits are easy to advertise and milliseconds are not. A number in the hundreds sounds impressive; a number in the tens requires an explanation. Marketing follows the metric that sells, and the metric that matters for calls does not sell.

Households learn the difference the first time a call fails in front of a client. The lesson is expensive and the underlying knowledge is simple.

How does latency affect gaming compared with calls?

Gaming is more sensitive to jitter than to the average delay. A steady sixty milliseconds is playable; a connection that alternates between thirty and a hundred and fifty produces rubber-banding that no amount of bandwidth fixes. Calls tolerate a little more variation because the software buffers audio.

That is why gamers often report problems that a speed test cannot reproduce. The relevant measurement is the distribution, not the headline.

What is packet loss and does it matter?

It is data that never arrives, and even one percent is noticeable in real-time traffic. A call with one percent loss sounds broken in a way that a call with three hundred milliseconds of steady delay does not, because the software can compensate for delay and cannot invent missing audio.

Loss is usually a local problem: a saturated upstream, a failing cable, or a Wi-Fi link at the edge of range. Testing wired separates the last of those from the first two in a single step.

A fast connection that hesitates is worse than a slower one that does not, and only one of those properties appears on the price list. If your next call froze, would you know whether to blame the line, the router or the room?