Real-Time Synchronization Test
Testing your system...
🖥️ Your System
--:--:--.---
Local Time
🌐 NTP Reference
--:--:--.---
Server Time
✓ Excellent Synchronization
Offset: 0ms |
Latency: --ms
Your system clock is spot-on! Curious how we contribute to global NTP accuracy?
Your NTP server is not responding or shows significant drift. We can help.
What This Tester Measures
📊 NTP Jitter
Standard deviation of offset over a short window — the signature of an unstable path or overloaded source. Read the analysis →
⏱️ Live Clock Offset
Real-time delta between your system clock and our NTS-secured NTP infrastructure, measured over HTTPS and refreshed every 10 seconds. Interpretation guide →
🕰️ Clock Drift Detection
Watch the offset evolve across successive polls to expose frequency drift of the local crystal. Why PCs drift →
Is Your NTP Secure?
Classic NTP has zero authentication. NTS (Network Time Security) fixes that with TLS 1.3 cryptographic protection.
Not here to measure? Use the right tool for your use-case:
Our infrastructure services — Beyond time synchronization, RDEM Systems also provides off-site business backup for business-critical data protection.
About ntp-tester.eu — A free NTP testing platform maintained by RDEM Systems. Tests run from our own AS206014 infrastructure, with time references secured via NTS and synchronized to public Stratum 1 sources, including the Paris Observatory's. Hosted on Proxmox VE clusters.
About the author
Frequently asked questions
What is NTP jitter and what value is acceptable?
NTP jitter is the variation (standard deviation) of offset measurements between a client and its time source over a short window. On a wired LAN, expect jitter below 1 ms; on a stable home broadband link, below 5 ms; on congested or Wi-Fi paths, 10–30 ms is common. Jitter above 50 ms typically indicates a problematic path or a source under load. Our live tester shows jitter in real time alongside offset and round-trip delay.
How do I measure live NTP offset from the browser?
This tester fetches a timestamp over HTTPS from our NTP infrastructure (our web server, synchronized over NTS with our Stratum 2 servers, which follow public Stratum 1 servers including the Paris Observatory's), estimates the one-way latency as half the round-trip, and computes the offset between your browser clock and that timestamp. Because the measurement runs in the browser over HTTP, its precision is limited by the network: a few milliseconds at best, tens of milliseconds on a busy path. A value below 100 ms is excellent, 100–1000 ms is acceptable but worth checking, and above 1 s indicates a broken NTP service. The measurement refreshes every 10 seconds to expose drift.
What does NTP round-trip delay (RTD) tell me?
Round-trip delay is the elapsed time between sending the NTP request and receiving the response. It bounds the worst-case offset uncertainty: the NTP algorithm assumes one-way latency is roughly RTD/2, so a high RTD reduces the precision of the offset estimate. For accurate clocks, prefer sources with stable, low RTD over distant sources with variable delay.
How do I benchmark NTP latency across multiple servers?
The simplest CLI method is 'chronyc sourcestats' (Linux) which shows offset, frequency, skew, standard deviation and measurement count per source. For one-shot probing, 'ntpdate -q <server>' or 'sntp <server>' print a single offset and delay measurement. From the browser, this tester exposes the round-trip delay for its own Stratum 1 reference — compare against ping to identify NTP-specific path quality.
Why does my PC clock drift even with NTP enabled?
Between synchronisations, the system clock runs on the CPU crystal whose frequency varies with temperature (typically ±10 ppm → ~1 s / day). NTP corrects this drift at each poll. If drift is visible, the poll interval is too long, the source is unreliable, or NTP was interrupted (sleep/hibernate, network lost). Check continuous sync with our live offset display — stable < 100 ms confirms NTP is actually working.