Jitter — Why Calls Break When Your Ping Looks Fine

Jitter is variation in packet timing, and it ruins real-time applications while leaving every number people usually check looking healthy. What it is, what causes it, and how to measure yours.

Your ping is 30 ms. Your speed test is excellent. Packet loss reads zero. And your calls still break up, or the game still feels wrong in a way you cannot quite describe.

The number nobody checked is jitter — how consistently packets arrive. It is the metric most likely to explain a connection that measures well and behaves badly, and it is absent from almost every consumer speed test.

Measure it directly

The connection test reports jitter alongside loss and latency, in both directions.

Run the connection test →

What jitter is

Latency is how long one packet takes. Jitter is how much that time varies between consecutive packets.

Two connections, both averaging 30 ms:

Steady        30  31  29  30  31  30  29  30  ms     jitter ≈ 1 ms
Jittery        8  55  12  70  15  48  11  62  ms     jitter ≈ 25 ms

Identical averages. Completely different to use.

The first is predictable. The second delivers packets in an erratic order in time, and every application that needs a steady stream has to cope with it somehow.

Two things worth knowing before you compare numbers between tools. Different tools calculate jitter differently — some average the difference between consecutive packets, some report a standard deviation, some follow the IPDV definition in RFC 3393 — so the same connection can legitimately produce different figures. And network jitter is not the same as what your conferencing application reports: a diagnostic measures the network path, while Teams or Zoom reports what its media stack experienced after buffering, reordering and scheduling. NetworkTests showing 8 ms while Teams reports 20 ms does not mean either is wrong.

Why it breaks things that loss does not

Real-time audio and video cannot wait. A voice packet that arrives late is worthless — the moment it was meant to fill has passed.

Receivers handle this with a jitter buffer: hold incoming audio briefly, then play it out at a steady rate, using the buffer to absorb variation. The trade-off is direct. A larger buffer tolerates more jitter but adds delay to the conversation; a smaller buffer keeps latency low but discards anything arriving outside its window.

That last part is the important bit, and it is why jitter is so often misdiagnosed:

Packets that arrive too late for the application's playback deadline may be discarded or treated as unusable, and some applications count these as loss — even though the network delivered every one of them.

So Teams or Zoom reports 3% loss, the network shows 0%, and both are telling the truth. The packets arrived; they arrived too late to use. Chasing network loss in that situation finds nothing, because there is nothing there to find.

Practical jitter guidelines

These are practical guidelines, not universal pass/fail thresholds — different applications use different jitter buffers, and tolerance varies with them. Distribution matters as much as the figure: jitter arriving as occasional large spikes is worse than the same average spread evenly, because a spike overruns the buffer while steady small variation does not.

What causes it

In rough order of how often it turns out to be the answer.

Wi-Fi

One of the most common causes for home users, and the reason "try a cable" is the first question worth asking.

Wi-Fi is a shared medium. Devices contend for airtime rather than transmitting whenever they like, so every device waits its turn — Wi-Fi 6 schedules that contention more efficiently with OFDMA, but does not remove it — and that wait varies constantly with how busy the channel is, including from neighbours' networks you cannot see or control. Wireless also retransmits lost frames invisibly below the application, which delays some packets and not others. That is jitter, generated by design.

A strong signal does not prevent it. Signal strength governs whether frames get through; contention governs when they get sent. Full bars on a congested channel still produces jitter.

Bufferbloat

When a link saturates, oversized buffers queue packets rather than dropping them. Latency climbs while the queue drains and falls when it empties, and that swing is jitter — often severe, and correlated with someone starting a large upload.

If your jitter is fine when idle and terrible during transfers, bufferbloat is a strong suspect — and it is fixable at your end.

Congestion somewhere on the path

Queueing at any congested link produces variable delay, and it typically follows a daily pattern — fine at 10am, poor at 9pm. If the same pattern repeats across several days, record the time of each test and compare results to more than one destination; that turns an observation into something worth documenting for your ISP.

Route changes

Networks load-balance across multiple paths, and packets taking different routes arrive with different delays. This shows up as latency alternating between two clusters rather than varying randomly:

Stable route   25  26  24  25  26  25  24  ms
Two paths      20  61  21  62  19  60  21  ms

Two distinct clusters point at path selection or load balancing rather than random noise — the bimodal pattern visible in an MTR.

Your own machine

Worth ruling out before blaming the network. A CPU pinned by endpoint protection or a background build delays packet processing at the endpoint, producing artifacts that can closely resemble network jitter. Check resource usage during a bad call.

Power saving

Wireless adapters and mobile radios sleep between transmissions to save battery. Power-saving behaviour can add variable wake-up delay, particularly on mobile and battery-powered devices. On laptops this is worth checking in the adapter's advanced properties if jitter is high on Wi-Fi but the channel looks quiet.

Measuring yours

Three runs, about ten minutes, and the comparison is what tells you the answer.

1. Wired, idle. Run the connection test over Ethernet with nothing else running. This is your connection at its best.

2. Wired, under load. Start a large upload and repeat. If jitter multiplies, that is bufferbloat.

3. Wi-Fi, idle. Repeat on wireless. If jitter appears that was not there on the cable, wireless is your problem.

That sequence changes one major variable at a time, which is what makes it possible to isolate the cause in three tests.

For a continuous view, a long ping shows the shape rather than a summary:

Windows          ping -n 100 1.1.1.1
macOS / Linux    ping -c 100 1.1.1.1

Watch the spread between minimum and maximum, and whether the variation is steady or spiky. The summary line's mdev (Linux) or the min/avg/max range will reveal obvious variability, but treat it as a rough indicator only — it is not the same calculation a jitter measurement uses, so the numbers will not match.

Fixing it

In descending order of how much difference it usually makes:

Use Ethernet where practical. Unwelcome advice, and still one of the simplest ways to remove airtime contention and wireless retransmission as sources of jitter. If a cable is genuinely impossible, use 5 GHz or 6 GHz, move closer to the access point, and pick a clear channel.

Enable SQM on your router if jitter rises under load. This is the fix that most often turns an unusable evening connection into a fine one, and it costs nothing — see the bufferbloat guide.

Stop competing traffic during calls. Cloud backups and game updates are the usual culprits.

Check for interference on 2.4 GHz, where neighbouring networks and non-Wi-Fi devices both contend. Moving to 5 GHz resolves a lot of otherwise unexplained spikes.

Disable adapter power saving if wireless jitter persists on a quiet channel.

What generally does not help: more bandwidth. Jitter is a timing property, and a faster link does not automatically make delivery more even — if the cause is Wi-Fi contention, route instability or queueing, extra capacity changes nothing. The exception is when you are genuinely saturating the line, in which case more headroom does reduce the queueing that was causing it. This is the same reason upgrading your plan rarely fixes call quality.

Frequently asked questions

What is jitter in networking?

Variation in the delay between consecutive packets. If packets take 30 ms, then 31, then 29, jitter is low. If they take 8 ms, then 70, then 15, jitter is high even though the average is unchanged.

What is a good jitter value?

Lower is generally better. As a practical guideline, under 5 ms is excellent, 5–15 ms is usually comfortable for calls and gaming, and sustained or bursty variation above roughly 20–30 ms becomes noticeable in sensitive real-time applications. Treat these as guidelines rather than hard limits — application buffering differs.

Why do my calls break up when my internet speed is fine?

Because speed and timing are different properties. Calls need small packets arriving consistently; a speed test measures bulk throughput over a reliable transport that repairs problems automatically. Jitter and loss both break calls while leaving throughput untouched.

Is jitter the same as packet loss?

No, but they are easily confused. Jitter is variable timing; loss is packets that never arrive. They connect because a packet arriving outside the jitter buffer's window is typically discarded by the receiver, and most applications then report it as loss even though the network delivered it.

Does Wi-Fi cause jitter?

Wi-Fi can be a major source of jitter, because devices share airtime and wireless retransmissions introduce variable delay. A strong signal does not prevent this — contention and signal strength are different things. Running the same test wired and wireless is the simplest way to find out whether it is contributing.

Can I have low ping but high jitter?

Yes, and it is a common combination. Ping usually reports an average, while jitter describes how much that average moves. A 20 ms mean made of measurements ranging from 5 ms to 60 ms produces a connection that feels far less stable than the ping figure suggests.

Why is my jitter high only when I upload?

That points at queueing, usually bufferbloat. Compare idle latency against latency during a sustained upload; if the difference is large and disappears when the transfer stops, enabling SQM or shaping on the router is the fix.

How do I reduce jitter?

Use Ethernet where possible, enable Smart Queue Management if jitter rises under load, stop large background transfers during calls, and move off 2.4 GHz. More bandwidth does not help, because jitter is about timing rather than capacity.

Why is my jitter high only in the evening?

That pattern points to congestion — either in your ISP's local segment or at an interconnect — rather than a fault at your end. If it reproduces across several evenings, it is worth reporting with timestamped evidence.