EN FR Home

NTP Latency Benchmark

Round-trip delay, server comparison and measurement methodology

1. Round-trip delay (RTD) — what it bounds

RTD is the interval between sending an NTP request and receiving the response, measured at the client. NTP derives one-way latency as RTD/2 — a symmetric-path assumption that is approximately true over wired networks.

Why it matters for accuracy: the offset calculation trusts that one-way latency in both directions is equal. If the true latencies are L_out and L_in, the offset error from asymmetry is |L_out − L_in| / 2. The RTD bounds the worst-case asymmetry: at most RTD/2 of offset error.

2. Acceptable RTD by geographic distance

Source location relative to clientExpected RTDSuitability
Same datacentre / same LAN< 1 msIdeal for internal Stratum 2
Same city / metro1–5 msExcellent
Same region (< 500 km)5–15 msVery good
Same country10–30 msGood
Same continent30–80 msAcceptable for general use
Intercontinental100–250 msFallback only
Satellite / mobile200–800 msLast resort

3. Benchmark methodology

Three complementary techniques, from lightest to most rigorous:

3.1 Single-shot probe

One UDP roundtrip. Fast, but a single sample reflects instantaneous jitter and may mislead.

$ sntp time.rdem-systems.com
+0.000234 +/- 0.001450 ntp.rdem-systems.com 172.104.143.97 s1 no-leap

$ ntpdate -q ntp.rdem-systems.com
server 172.104.143.97, stratum 1, offset +0.000234, delay 0.01821

3.2 Multi-sample averaged probe

10–60 samples over a minute; report mean, median and standard deviation. More reliable.

# Using nping (nmap suite) as a generic NTP probe
$ nping --udp --dest-port 123 --count 30 --delay 1s ntp.rdem-systems.com

# Or the chrony dedicated helper
$ chronyd -Q 'server ntp.rdem-systems.com iburst minpoll 2 maxpoll 2'

3.3 Continuous monitoring (the reference method)

Add the source to your chrony/ntp.conf and observe offset, jitter and RTD over hours. This is the only way to catch rush-hour degradation and weekly patterns.

$ chronyc sourcestats -v

4. Comparison of common EU NTP sources

Typical RTDs measured from Paris (April 2026, wired fibre, 1-minute window averaged). Your mileage will vary with your ISP and time of day.

SourceLocationTypical RTD (Paris)Notes
ntp.rdem-systems.comFrance (AS206014)1–3 msStratum 1 GNSS + PPS, NTS-capable
time.cloudflare.comAnycast (nearest PoP)2–8 msNTS-capable; quality depends on nearest PoP
ntp1.ptb.deBraunschweig, DE10–20 msGerman national metrology institute
nts.netnod.seStockholm, SE25–40 msStratum 1, NTS reference implementation
time.nist.govUSA (anycast)80–150 msAuthoritative US reference, not optimal EU-side
pool.ntp.orgVariable (random)2–80 msVolunteer-based, unpredictable per query

5. Latency vs jitter vs stratum — the tradeoff

When choosing an NTP source, three properties compete:

  • Stratum — lower is better (closer to the atomic reference).
  • RTD — lower is better (tighter offset bound).
  • Jitter — lower is better (more reliable measurement).

These rarely align perfectly. A public Stratum 1 on another continent has excellent stratum but poor RTD. A regional Stratum 2 has better RTD but inherits the upstream's accuracy. The conventional wisdom:

  1. Prefer a regional Stratum 2 with low stable RTD over a distant Stratum 1.
  2. Pool 3–5 sources with different upstream topology so the intersection algorithm can discard a false ticker.
  3. For regulated workloads, terminate on an authenticated source (NTS) to guarantee the stratum claim is not spoofed.

6. Browser-based latency measurement (this tester)

The home-page tester reports the network RTD under "Latency" — the HTTPS round-trip to our Stratum 1 GNSS reference. While not as precise as native UDP NTP (HTTPS adds TLS handshake overhead), it gives a useful first-order estimate without installing anything.

Use it as a baseline: if the browser reports 200 ms to our Paris server from a Paris ISP, either your connection is bufferbloated or our server is receiving a transient spike of traffic. Re-test in 1 minute to confirm.

Run the Latency Benchmark →

Beyond latency? Use the right tool:

Frequently asked questions

What is NTP round-trip delay (RTD)?

RTD is the elapsed time between sending an NTP request and receiving the response, measured at the client. NTP uses RTD to estimate one-way latency (RTD / 2) and thus bound the uncertainty of its offset calculation. Low RTD means precise offset; high RTD means a loose bound.

How does RTD affect NTP accuracy?

The offset calculation assumes symmetric one-way latency. In practice, the uncertainty of the offset is roughly RTD/2. A 10 ms RTD gives ±5 ms worst-case offset error; a 300 ms RTD gives ±150 ms. For accurate time, choose sources with low AND stable RTD — not just low RTT.

What RTD is acceptable for an NTP source?

Same region (&lt; 500 km): &lt; 10 ms. Same continent: 10–50 ms. Intercontinental: 100–250 ms. Above 300 ms indicates a poorly chosen source or a degraded path. Prefer 3–5 regional sources over a single continental one.

How do I benchmark NTP latency across multiple servers?

Linux CLI: 'chronyc sourcestats -v' shows offset, frequency, skew and standard deviation per configured source. For ad-hoc probing: 'ntpdate -q &lt;server&gt;' or 'sntp &lt;server&gt;' print a single-shot RTD and offset. For EU servers, typical RTDs from Paris: 1–3 ms (ntp.rdem-systems.com), 4–10 ms (Cloudflare time.cloudflare.com), 15–30 ms (NIST servers via Atlantic).

Is low latency to NTP more important than low jitter?

Jitter is more important than raw latency, because NTP algorithms compensate for fixed latency but amplify variable latency. A stable 50 ms link outperforms a jittery 5 ms link for time-sync accuracy. Optimise for low AND stable — not just low.