Ping and jitter

Ping tells you how long a packet takes. Jitter tells you how much that time wobbles. A steady 40 ms can feel better than a 25 ms average that jumps around.

The short answer

Ping is the round-trip time (RTT) of a small test packet: how long it takes to reach a host and come back [1][5]. Jitter is how much that delay varies from packet to packet. The IETF calls it delay variation and defines it from the difference in delay between packets [2][3]. Our assessment: for online games and calls a low, steady delay beats a low average with spikes. The Linux ping tool shows variation as "mdev" [5].

How it works

1. What ping measures. The tool sends an ICMP echo request and waits for the echo reply, on IPv4 and IPv6 [5]. RFC 2681 defines round-trip delay as a metric for packets across Internet paths [1]. By default ping prints the network round-trip time. With the option -U it prints the full user-to-user latency [5].
2. Ping in a game is not always the same number. Valve defines latency or ping as the time between the client sending a command, the server responding and the client receiving that response [6]. A game's ping display can therefore differ from ICMP ping. We have not measured by how much.
3. What jitter measures. RFC 3393 defines IP packet delay variation from the difference in one-way delay of selected packets, and it works with synchronised and unsynchronised clocks [2]. RFC 5481 prefers the term "delay variation", because "jitter" is used for many other kinds of signal variation [3]. It describes two common forms: variation against the previous packet and variation against a reference [3].
4. The RTP estimator. RFC 3550 smooths the packet-spacing difference D with J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16 [4]. Own calculation: if J is 0 and one packet arrives 16 ms off its expected spacing, J becomes 1 ms. A single spike hardly moves the estimate; a steady wobble does.
5. mdev in ping. The Linux manual defines mdev as the population standard deviation, roughly how far each RTT sits from the mean. The higher it is, the more the RTT varies. High variability slows bulk transfers and gives middling to poor VoIP quality [5].
6. Where to measure. The manual suggests testing from the local host outward, then gateways, then hosts further away [5]. It also warns that ping loads the network and should not run from automated scripts during normal operation [5].

A practical example

Your game stutters, but the speed test looks fine. Test step by step and keep each run short:

ping -c 30 <router-address>
ping -c 30 <game-server-address>

Compare the last line of both runs: rtt min/avg/max/mdev. If the router run already shows a high mdev, look at your Wi-Fi or cabling first. If only the server run does, the problem sits further out, for example at your provider or at the server [5]. Some hosts rate-limit or ignore ICMP, so a missing reply is not proof of a broken route (our assessment). Our inventory (as of 14 to 16 Oct 2026) lists a UniFi router and firewall; we have no ping measurements of our network on record, so we show none.

Checklist

• Run ping first against your router, then against the target [5].
• Read avg and mdev, not just min [5].
• Use enough packets, at least a few dozen, so that spikes show up (our suggestion).
• Test again while someone streams or downloads (see our entry on bufferbloat).
• Keep ping short and manual; it loads the network [5].
• Note date, time and wired or Wi-Fi next to each result.