Jitter is the variation in packet delay between consecutive packets of the same flow, measured as how much the one-way delay of each packet deviates from that of its neighbors or from the average. In network monitoring, jitter sits beside latency and packet loss as one of the three core indicators of path quality, and it is the metric that most directly predicts whether real-time traffic such as voice, video conferencing and online gaming will sound and look smooth.
A network can have a high but stable delay and still deliver excellent voice quality, while a network with low average delay but large, unpredictable swings can make calls choppy. That is why monitoring tools, service level agreements and VoIP platforms report jitter as a separate number rather than folding it into latency.
How jitter arises in a packet network
Jitter arises because packets of one flow do not experience identical conditions on their way through the network. The dominant cause is variable queuing delay: when a router or switch interface is busy, arriving packets wait in a buffer, and the waiting time changes from one packet to the next as competing traffic rises and falls.
Other contributors include route changes that move a flow onto a path with a different length, serialization delay on slow links when a small voice packet waits behind a large data frame, contention on shared wireless media, and processing on the endpoints themselves. Bursty applications such as backups or software updates are a classic trigger, because they fill buffers in short waves.
The table below lists the common sources of delay variation and the conditions under which each becomes significant.
| Source | Mechanism | When it dominates |
|---|---|---|
| Queuing | Packets wait in interface buffers | Congested uplinks and WAN edges |
| Serialization | Small packets wait behind large frames | Links below about 2 Mbit/s |
| Wi-Fi contention | Retries and channel access backoff | Busy or noisy radio channels |
| Route changes | Path length changes mid-flow | Routing convergence and load balancing |
| Host processing | CPU scheduling and power saving | Virtual machines and mobile devices |
How jitter is measured and calculated
There is no single universal jitter formula, so a value is only meaningful when the measurement method is known. The most widely used definition comes from RTP, specified in RFC 3550, which computes interarrival jitter as a running average of the difference in transit time between consecutive packets, smoothed with a gain of 1/16. VoIP phones, session border controllers and RTCP reports use this method.
Network performance standards use a more formal term, packet delay variation (PDV), defined in RFC 3393 and ITU-T Y.1540. PDV can be expressed as the difference between consecutive delays (IPDV) or as the spread of delays relative to the minimum delay, often reported as a high percentile such as the 99th.
The following table compares the main measurement approaches a monitoring engineer meets in practice.
| Method | What it reports | Typical source |
|---|---|---|
| RTP interarrival jitter | Smoothed consecutive transit difference | VoIP endpoints and RTCP |
| IPDV | Delay difference between packet pairs | Active test probes |
| PDV percentile | Delay spread above the minimum | SLA and carrier reports |
| Standard deviation of RTT | Statistical spread of round-trip time | Ping-based tools and MTR |
Ping-based figures are convenient but only approximate, because round-trip time mixes the forward and return paths and many routers deprioritize ICMP replies. True one-way jitter requires synchronized clocks or a method that cancels clock offset, such as the consecutive-difference calculation used by RTP and by tools like iPerf in UDP mode.
Jitter compared with latency and packet loss
Jitter, latency and packet loss describe different properties of the same path and must be read together. Latency is how long a packet takes, jitter is how much that time varies, and packet loss is how many packets never arrive or arrive too late to be useful.
| Metric | Question it answers | Typical unit | Main effect on voice |
|---|---|---|---|
| Latency | How long does delivery take | Milliseconds | Talk-over and awkward pauses |
| Jitter | How much does delay vary | Milliseconds | Choppy or robotic audio |
| Packet loss | How many packets are missing | Percent | Gaps and clipped words |
The metrics are linked through the jitter buffer. A receiving endpoint holds incoming packets briefly so it can play them at an even pace. A larger buffer absorbs more jitter but adds latency, and any packet that arrives after its playout time is discarded, so excessive jitter turns into effective packet loss even when the network delivered every packet.
Acceptable jitter levels for real-time traffic
Acceptable jitter depends on the application and on how well its buffer adapts. A widely used rule of thumb for VoIP is below 30 ms, with one-way latency below about 150 ms and packet loss below 1 percent. Adaptive buffers in modern codecs can tolerate more, but quality degrades quickly once jitter regularly exceeds the buffer depth.
| Application | Comfortable jitter | Tolerance and notes |
|---|---|---|
| Voice calls | Below 30 ms | Adaptive buffers usually 20-60 ms |
| Video conferencing | Below 30 ms | Lip sync suffers as jitter grows |
| Online gaming | Below 20 ms | Felt as rubber-banding and lag spikes |
| Buffered video streaming | Largely irrelevant | Seconds of buffer hide variation |
| Bulk file transfer | Not critical | Affects throughput only indirectly |
These figures are planning guidelines rather than hard limits. Industrial control, financial trading and time synchronization systems often need jitter in the microsecond range and rely on specialized hardware timestamping to measure it.
Reducing jitter and avoiding measurement mistakes
The most effective remedy is quality of service (QoS): marking real-time packets with DSCP Expedited Forwarding and placing them in a priority queue so they never wait behind bulk traffic. Other measures include adding capacity at congested edges, enabling traffic shaping before a slower provider link, moving voice devices off congested Wi-Fi and limiting bufferbloat with active queue management such as fq_codel or CAKE.
Measurement errors are as common as network problems. Engineers who compare results should keep the following pitfalls in mind:
- Averaging over long intervals hides short bursts; five-minute averages can look clean while calls break every few seconds.
- Mixing methods produces misleading comparisons, because RTP jitter and a 99th percentile PDV are not the same number.
- Testing with ICMP only can show jitter caused by router control planes rather than by the forwarding path.
- Ignoring direction misses asymmetric problems, such as an upload queue that only affects outbound audio.
- Measuring without load shows the idle network; jitter often appears only when the link is busy.
A sound monitoring practice combines passive data from RTCP and flow records with active synthetic tests that send small UDP packets at a fixed rate, and compares the results against a recorded network baseline.
Put simply
Imagine a friend reading a story to you over the phone, one word per packet. If every word takes exactly the same time to reach you, the story sounds natural even if there is a small delay. If some words arrive quickly and others arrive late, the story sounds broken and uneven. That unevenness is jitter.
Your phone or computer tries to fix it by waiting a little before playing the sound, collecting words so it can play them smoothly. This works until the delays become too uneven. Low and steady delay is what makes calls sound good, which is why network teams watch jitter so closely.
In practice
A regional office with forty employees moves its telephones to a cloud VoIP service. Calls sound fine in the morning, but every afternoon users complain of robotic voices. The monitoring dashboard shows average latency of 35 ms all day, which seems healthy, yet the RTCP reports from the phones show jitter rising from 4 ms to over 70 ms between 2 and 4 p.m.
Flow data reveals that a scheduled backup to an offsite server saturates the 50 Mbit/s upload link during that window, filling the router queue. The network team marks voice traffic with DSCP Expedited Forwarding, creates a priority queue on the WAN interface and shapes the backup to 35 Mbit/s. Afternoon jitter drops below 8 ms, the complaints stop, and the team adds a jitter alert at 30 ms so that a similar problem is detected before users notice it.