What is NTP jitter in simple terms?

Jitter is the standard deviation of offset measurements over a short window. If every NTP poll reports a different offset value, jitter is high — your time-source measurement is noisy. Low jitter means the offset estimate is stable and trustworthy.

What is an acceptable NTP jitter value?

Wired LAN: below 1 ms. Wired WAN to a continental peer: 1–5 ms. Home broadband / stable residential: 2–10 ms. Wi-Fi or congested links: 10–30 ms is common. Above 50 ms, investigate the path or the source.

What causes high NTP jitter?

Four dominant causes: (1) bufferbloat on the upload path, (2) Wi-Fi retransmissions and contention, (3) overloaded NTP server (long queue before UDP processing), (4) asymmetric routing where one direction differs from the other in latency.

How do I measure NTP jitter on Linux?

Run 'chronyc sources -v' or 'chronyc sourcestats'. The 'Jitter' column on ntpq (classic ntpd) or the 'Std Dev' column on chrony report jitter per source. For a single poll: 'sntp -d <server>' shows delay variation.

Is jitter the same as latency?

No. Latency is the one-way or round-trip delay — a scalar. Jitter is the variation of that latency (or of the derived offset) across multiple measurements. A source can have high latency but low jitter (stable slow link) or low latency but high jitter (fast but variable Wi-Fi).

NTP Jitter Analysis | What It Means, Acceptable Values, How to Measure

On this page

1. What NTP jitter actually measures
2. Acceptable jitter by network type
3. What causes high jitter
4. How to measure jitter — CLI and browser
5. Reducing high jitter
6. Jitter vs offset vs drift — how they differ

1. What NTP jitter actually measures

NTP jitter is the statistical dispersion — typically the standard deviation or a smoothed variance — of successive offset measurements between a client and one of its time sources. It quantifies how noisy the path is, not how accurate the source is.

A client that polls a server eight times and sees offsets of -2, -3, -1, -2, -4, -2, -3, -2 milliseconds has low jitter (~1 ms). A client seeing -2, +18, -9, +24, -11, +6, -3, +15 ms has the same average but very high jitter — the individual measurements are unreliable, even if averaging them over time still yields a reasonable clock.

Why jitter matters for SEO-grade precision. NTP selects sources and applies exponential smoothing using jitter as an input. A source with high jitter receives less weight in the clock-filter algorithm — which is why poor-quality sources degrade accuracy even when they average to the correct offset.

2. Acceptable jitter by network type

Link / scenario	Typical jitter	Action
Wired LAN, same datacentre	< 1 ms	Healthy
Wired WAN, continental	1–5 ms	Healthy
Consumer broadband, idle	2–10 ms	Acceptable
Wi-Fi, normal activity	10–30 ms	Acceptable for non-critical
Mobile LTE/5G	15–50 ms	Watch, not for Stratum 2
Any path	> 50 ms	Investigate
Any path	> 200 ms	Source unusable as reference

Financial-trading or telecom-synchronisation workloads operate in the sub-millisecond regime and require PTP/IEEE 1588, not NTP. Everyday enterprise workloads (AD, logs, TLS) tolerate 10–30 ms jitter without operational impact.

3. What causes high jitter

Four dominant causes, in rough order of frequency:

Bufferbloat on upload. A saturated uplink queues outgoing UDP probes behind bulk TCP traffic, inflating and randomising their departure time. Use flent rrul or waveform bufferbloat to confirm.
Wi-Fi retransmissions. A lossy Wi-Fi frame is retransmitted at MAC layer, adding 5–20 ms per retry. Jitter scales with channel contention and distance to AP.
Overloaded NTP server. A Stratum 1 handling 10k+ queries per second may queue UDP packets briefly. Look for correlated jitter spikes across multiple clients pointed at the same source.
Asymmetric routing. NTP assumes symmetric one-way latency. When the forward and return paths differ (common on multi-homed networks), the offset calculation inherits the asymmetry as jitter.

4. How to measure jitter — CLI and browser

From the browser (this site)

The live tester on the home page resamples the Stratum 1 GNSS reference every 10 seconds. The jitter is implicit in how much the displayed offset value changes between successive polls — load the page and watch the offset value for 1–2 minutes.

Linux — chrony

$ chronyc sourcestats -v
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
=======================================================================
ntp.rdem-systems.com       18  10  259   -0.012     0.034      -2ms    0.8ms
pool.ntp.org               16   9  245   +0.005     0.051      +4ms    2.1ms

The Std Dev column is the jitter estimate for the offset measurements. Target: below 2 ms for a Stratum 2 client.

Linux — classic ntpd / ntpsec

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.0.2.1       .GPS.            1 u   21   64  377   14.132   -1.842   0.421

The jitter column is in milliseconds. Target: < 1 ms on a selected Stratum 1 peer.

Windows

> w32tm /query /status
Root Dispersion: 0.0156257s
Source: ntp.rdem-systems.com,0x8
Poll Interval: 10 (1024s)

Windows does not expose per-source jitter directly; Root Dispersion is a conservative upper-bound on combined jitter across the time-sync tree.

5. Reducing high jitter

Pin to a closer source. Replace distant pool servers with a regional Stratum 2, or run your own internal Stratum 2 close to clients.
Enable SQM on the router. Smart Queue Management (fq_codel, cake) eliminates bufferbloat in one configuration change.
Prefer wired to Wi-Fi on servers. Wi-Fi jitter is physical and cannot be configured away.
Increase poll interval. Counter-intuitive but effective: less frequent polls give the kernel filter more time to average out noise. Raise minpoll from 6 to 8 on NTP clients with stable upstream.
Use multiple sources. Three to five sources let chrony's intersection algorithm discard the jittery outlier and keep the clock locked to the quieter majority.

Metric	What it measures	Unit	Typical value
Offset	Difference between local clock and authoritative time	ms or µs	< 100 ms excellent
Jitter	Variability of successive offset measurements	ms	< 1 ms on LAN
Drift	Rate at which local clock falls behind over time	ppm (parts per million)	±10 ppm typical crystal
Delay / RTD	Round-trip time to source	ms	< 50 ms continental

A stable clock has low jitter, low drift, and low offset. Diagnosing time-sync issues starts by isolating which of the three is degraded: see the live offset guide and the latency benchmark guide.

Run the Live Jitter Tester →

NTP Jitter Analysis