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 (< 500 km): < 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 <server>' or 'sntp <server>' 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.

NTP Latency Benchmark | Round-Trip Delay & Server Comparison

Q: What RTD is acceptable for an NTP source?

Same region (< 500 km): < 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.

Q: 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 <server>' or 'sntp <server>' 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).

On this page

1. Round-trip delay (RTD) — what it bounds
2. Acceptable RTD by geographic distance
3. Benchmark methodology
4. Comparison of common EU NTP sources
5. Latency vs jitter vs stratum — the tradeoff
6. Browser-based latency measurement (this tester)

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.

Practical rule. A source with RTD = 10 ms can deliver offset precision down to ±5 ms (worst case) and typically ±1 ms (stable symmetric path). A source with RTD = 300 ms bounds offset precision at ±150 ms — which is why continental/intercontinental NTP is rarely used as a primary Stratum 2 reference.

2. Acceptable RTD by geographic distance

Source location relative to client	Expected RTD	Suitability
Same datacentre / same LAN	< 1 ms	Ideal for internal Stratum 2
Same city / metro	1–5 ms	Excellent
Same region (< 500 km)	5–15 ms	Very good
Same country	10–30 ms	Good
Same continent	30–80 ms	Acceptable for general use
Intercontinental	100–250 ms	Fallback only
Satellite / mobile	200–800 ms	Last 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.

Source	Location	Typical RTD (Paris)	Notes
`ntp.rdem-systems.com`	France (AS206014)	1–3 ms	Stratum 1 GNSS + PPS, NTS-capable
`time.cloudflare.com`	Anycast (nearest PoP)	2–8 ms	NTS-capable; quality depends on nearest PoP
`ntp1.ptb.de`	Braunschweig, DE	10–20 ms	German national metrology institute
`nts.netnod.se`	Stockholm, SE	25–40 ms	Stratum 1, NTS reference implementation
`time.nist.gov`	USA (anycast)	80–150 ms	Authoritative US reference, not optimal EU-side
`pool.ntp.org`	Variable (random)	2–80 ms	Volunteer-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:

Prefer a regional Stratum 2 with low stable RTD over a distant Stratum 1.
Pool 3–5 sources with different upstream topology so the intersection algorithm can discard a false ticker.
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 →