Jitter vs latency: what’s the difference and what’s acceptable?

Latency is how long a packet takes to get from one point to another, usually shown as a round trip in milliseconds. Jitter is how much that time changes from one packet to the next. If your pings read 20, 21, 20, 22 ms, you have about 20 ms of latency and almost no jitter. If they read 5, 40, 8, 70 ms, the average looks fine and the connection feels terrible.

That’s the whole difference between jitter and latency. For calls, games and anything else real-time, a jittery connection usually hurts more than a slightly slower steady one, and most people get that backwards.

Jitter vs latency: the short version

Two catches before you compare numbers. First, ping reports round-trip time, while the voice standards below talk about one-way delay. On a symmetric path, one-way is roughly half the RTT. Second, there’s no single jitter formula. ping’s mdev is a spread around the average, while iperf3 uses the smoothed interarrival jitter from the RTP spec (RFC 1889, per its source code). Compare a tool with itself, not one tool with another.

What is a good jitter and latency? Acceptable values by use

Numbers are one-way unless marked RTT.

The sources, so you can check them: ITU-T G.114 says most applications get “essentially transparent interactivity” below 150 ms one-way and sets 400 ms as the upper bound for network planning. Cisco’s QoS design guidance (End-to-End QoS Network Design, Cisco Press, 2004) targets average one-way jitter under 30 ms for voice, because lab testing showed quality drops off when jitter consistently goes past that. Microsoft’s Teams network requirements give a tighter set for the stretch from your network edge to Microsoft: under 30 ms one-way, under 15 ms of jitter and under 0.1% loss.

So what’s a good jitter number? Under 30 ms is where call quality starts to suffer, and under 10 ms is comfortably good for anything. Gamers should watch the spikes: one 80 ms hiccup in a firefight is what you remember, not the 20 ms average.

Latency is mostly geography

Light in fiber covers roughly 200 km per millisecond. ITU-T G.114 uses 5 µs per km for planning, which works out the same. Every 100 km of cable route adds about a millisecond to the round trip, and real routes are never straight lines, so the path is always longer than the map suggests.

No setting fixes distance. You can tune a server all week and it won’t beat physics. The only real fix for high latency is to put the server closer to the people or systems it talks to, which is why picking a data center matters more than picking a CPU for a lot of workloads.

Here’s what that looks like on our own network. We run sites in Ashburn (East), Chicago (Central) and Los Angeles (West). Our Ashburn dedicated servers page lists median round trips measured with RIPE Atlas probes on local ISPs: about 7 ms from New York and 80 ms from London, but about 62 ms from Los Angeles and 89 ms from Frankfurt. Same building, very different experience depending on where the user sits. Our Ashburn vs Chicago comparison walks through how to choose by where your users are.

Latency also multiplies. A new HTTPS connection needs three or four round trips before the first byte of the page arrives, so a 20 ms difference in round-trip time can turn into 60 to 80 ms on first load. Bandwidth doesn’t help. A faster line moves more data per second; it doesn’t shorten the trip.

Jitter is mostly queues

Every router on the path has buffers. When a link is busy, packets wait in line, and the wait changes from one moment to the next. That variation is jitter. The usual causes are boring:

• Wi-Fi retries. A wireless link that drops and resends frames adds delay in bursts.
• Congested links. An ISP that runs hot every evening adds queueing delay exactly when you’re using it.
• Oversized buffers. When a home router or modem queues too much, latency balloons whenever an upload or download is running. This is called bufferbloat.
• Busy hosts. On an oversold virtual server, other customers’ load shows up as late responses from yours.

Here’s why jitter matters more than people expect. A steady 18 ms is fine for an expert advisor that trades on 15-minute bar closes. A path that averages 5 ms but spikes to 80 ms at the New York open is worse, because the spikes land exactly when prices move. Calls work the same way. Voice and video apps smooth out jitter with a buffer, and that buffer adds delay to every packet, so a jittery link makes a call feel laggy even when the average ping looks fine.

Packet loss hurts more than either

An order or an API request is often a single small message, so there’s nothing queued behind it to trigger a fast retransmit. The sender waits for a timeout instead, and on Linux the minimum retransmission timeout is 200 ms (TCP_RTO_MIN is HZ / 5 in the kernel source). One dropped packet at the wrong moment costs more than shaving a few milliseconds off the ping ever saves.

My advice: when you compare two paths or two hosts, look at loss first, then jitter, then average latency. Most people do it in the opposite order.

How to measure latency and jitter on Linux

A single ping is a snapshot. You want minutes of data from the hour you care about. Install the tools:

# Ubuntu 24.04 / Debian 12
sudo apt install mtr-tiny iperf3

# AlmaLinux 9 / Rocky Linux 9
sudo dnf install mtr iperf3

ping gives you latency and a rough jitter figure. Send 100 probes a fifth of a second apart and read the summary line:

ping -c 100 -i 0.2 example.com
# ...
# rtt min/avg/max/mdev = 18.912/19.604/24.187/0.811 ms

The average is your latency. The min-to-max gap and the mdev value are your jitter. (The numbers above only illustrate the format.) Add -6 to test over IPv6.

mtr runs repeated probes to every hop and shows where loss and delay start. This report sends 300 probes (five minutes at the default one-second interval) and adds the jitter columns:

mtr -rw -c 300 -o "LS NABWV JMX" example.com

In the mtr man page, L is loss, S sent, N newest, A average, B best, W worst, V standard deviation, J current jitter, M mean jitter and X worst jitter. Loss that shows up at a middle hop but not at the destination is usually a router deprioritizing replies to probes, not real loss. Only trust loss that carries through to the last hop.

iperf3 in UDP mode is the closest thing to a real call or game stream. Run the server on one end and the client on the other:

# on the far end (listens on port 5201 by default)
iperf3 -s

# on your side: 30 seconds of UDP at 1 Mbit/s
iperf3 -c server.example.com -u -b 1M -t 30

# same test with the server sending to you
iperf3 -c server.example.com -u -b 1M -t 30 -R

The receiver’s summary line reports Jitter and Lost/Total Datagrams. Per the iperf3 docs, -u switches to UDP, -b sets the target bitrate (UDP defaults to 1 Mbit/s), -t sets the duration and -R reverses the direction. Keep the bitrate near what your app really sends; flooding a link proves nothing. Open TCP and UDP port 5201 on the server’s firewall first.

How to measure them on Windows

Windows ping prints minimum, maximum and average but no jitter figure, so you read jitter from the spread. Run enough probes to see it:

ping -n 100 example.com

For the path, pathping example.com is the built-in answer to mtr. By default it sends 100 queries to each hop and then reports round-trip time and loss per hop, “Source to Here” and “This Node/Link”. Expect to wait about 90 seconds, longer on paths with many hops, before results appear (Microsoft’s pathping docs). Both commands take -6 to force IPv6 (ping docs).

iperf3 runs on Windows too, with the same flags. ESnet doesn’t ship Windows binaries itself; its download page points to third-party builds.

Test like you mean it

• Test at the hours that matter. Run it during your busy hour, not at 3 a.m. when every link is idle.
• Look at the tail. Compare the worst values and the loss count over a long run. The average hides everything that matters.
• Test both directions. Routes are often asymmetric. Run the same checks from the server side, not only from your desk.

What fixes latency and jitter (and what doesn’t)

Latency. Move the workload closer to its users, or to the building your orders go to. After that, look for a better route: if mtr shows your traffic going through a distant city before it comes back, a different provider or location can cut real milliseconds. Cutting round trips helps too. Reusing connections and moving to TLS 1.3, which needs one fewer handshake round trip than TLS 1.2, saves time on every new session.

Jitter. Get off Wi-Fi for anything that matters. Stop saturating your own uplink with backups during business hours. If bufferbloat is the cause, turn on smart queue management (fq_codel or CAKE) on your router and set it to your measured line speed, as bufferbloat.net recommends. Prioritizing voice or trading traffic only helps on links you control, because most of the public internet ignores your markings.

On the server side, use hardware you don’t share and a host that watches its links. Our dedicated servers run on transit from PCCW, Cogent, GTT and Zayo, with uplink load watched on every rack.

Packet loss. Find the hop where it starts with mtr, then take the result to whoever owns that hop. If it starts on your own network, check cables and Wi-Fi first.

And the things that don’t work:

• More bandwidth won’t lower latency, and it only reduces jitter if your link was actually full.
• A faster CPU won’t help a network problem. It helps when the delay is your own app.
• “Ping reducer” VPNs only help when your ISP’s route is genuinely bad. Most of the time they add a hop.
• A bigger jitter buffer hides jitter by adding latency. It’s a trade, not a fix.

A worked example: trading servers

Trading is where all three numbers show up at once. CME futures match in Aurora, Illinois, so a Chicago-metro server starts with distance on its side. A public-internet path won’t win a microsecond race against firms racked in Aurora, but an expert advisor or bot mostly needs a path that stays steady at the open and doesn’t drop packets. Our forex and trading server page has the measurements, the test method and the plans.

FAQ

Want a second opinion on your own numbers? Send us your mtr output and what you’re running, and we’ll tell you which location fits.