Guides
What Is Jitter?
Jitter describes changing network delay. Learn how measurement methods, application statistics and controlled comparisons help explain timing problems.
Jitter is variation in network delay or in the spacing of arriving packets. It differs from average latency, throughput in Mbps and packet loss. Uneven delivery can affect a call or game, but broken audio and low frame rates can also come from the application or device. A symptom alone does not establish network jitter.
Why the average is not enough
As a teaching example, delays of 30, 30 and 30 ms and delays of 10, 10 and 70 ms both average 30 ms. Their maximum-minus-minimum ranges are 0 and 60 ms. These invented sequences illustrate variation; they are neither measurements of your connection nor a universal jitter formula. RTP media reports use a smoothed measure of differences between packet spacing at the receiver and sender. Variation in ping round-trip times includes both directions and need not equal one-way media jitter.
How to interpret a jitter reading
- Check the definition, unit, measurement method, destination and observation period. Compare a time series measured under similar conditions, including network load, rather than unrelated single numbers.
- A jitter buffer can smooth uneven arrivals by holding packets before playback. That can add playback delay. Packets arriving too late for playback have not necessarily been lost in the network.
- There is no universal 5, 15 or 30 ms boundary guaranteeing good or bad results in every application. Assess variation alongside latency, packet loss and the actual session quality.
- Queues under load, wireless contention or retransmissions can contribute to variation. Router age, evening timing or the presence of Wi-Fi does not identify a cause by itself.
What VMAXCHECK measures
VMAXCHECK uses M-Lab NDT for bulk TCP download and upload measurements and a server-reported TCP round-trip latency estimate. It does not display a separate jitter value. Repeating speed tests does not turn their latency readings into the received jitter of your call or game. The test server and traffic can differ from the application path. A speed test creates traffic, so run it outside important calls.
Four useful comparisons
- First save the symptom time, device, application, server or participant, connection type and current load. Record the application statistics over the affected period and relevant router events before restarting anything.
- Compare Wi-Fi and supported Ethernet on the same device with the same application, destination and measurement method at nearby times. A position change is another separate comparison. Improvement is a clue about changed conditions, not proof of a specific radio fault.
- Using the same statistics, compare a quiet connection with the periods before, during and after a permitted upload or download of your own. Record its direction and rate; change one factor and keep these load checks outside important calls.
- Compare another time, device or permitted destination one factor at a time. Then check the real application again. If a restart is justified, save the evidence first and follow the model-specific instructions. Keep security protections and managed-network rules in place.
Example: received jitter in Microsoft Teams
During an existing Teams call or meeting, open More actions > Settings > Call health. Labels may be translated. Microsoft says the statistics update every 15 seconds. Under Audio, observe Received jitter together with packet loss and round-trip time over the problem period. Microsoft lists under 30 ms as a typical Teams value; this is guidance for that service, not a guarantee for every call or game. Share relevant time ranges and statistics privately with support.
Common questions
- Does a low ping rule out jitter? No. A low average does not describe the full variation or packet loss, and an unrelated ping target does not represent the application.
- Does an evening pattern prove an ISP problem? No. Compare device, destination and your own load under equivalent conditions before drawing conclusions.
- Will a faster plan fix it? More capacity can reduce queuing when your own traffic fills the connection. It does not guarantee low jitter on every path or fix device processing. Gather evidence before buying equipment or changing a plan.