What is Jitter?

Why Jitter matters

For voice, gaming and trading, jitter often matters more than latency: a consistent 60 ms is far more usable than an average of 40 ms that regularly spikes to 200 ms, because buffers are sized for the worst case rather than the mean. Jitter usually comes from queueing on a congested link, from route flapping, or — on the server side — from CPU steal time delaying the process that should have replied. That last cause is invisible in a network trace and is the reason dedicated vCPU matters for latency-sensitive workloads. Measure it with mtr or a long iperf3 run rather than a handful of pings; a five-packet sample tells you almost nothing about variance.

Jitter in practice

When you run a latency-sensitive service, jitter is what you measure with mtr or a long iperf3 run, not a handful of pings. Watch for variance in the delay column, not just the average. If you see spikes, check for CPU steal time on the host—that is invisible in a network trace. Reduce jitter by ensuring you have dedicated vCPU, not shared resources. Get it wrong and your buffers will be sized for worst case, which means your voice, gaming, or trading traffic degrades to unusable during peaks.

What people get wrong about Jitter

People assume a low average latency means good performance. The common error is ignoring variance, thinking that 40 ms average with spikes to 200 ms is fine. Correct: jitter often matters more than latency—buffers are sized for worst case, so consistent 60 ms outperforms an average 40 ms that regularly spikes. Always measure over time.