Compare two NTP servers — live measurement

Two servers, 3 SNTP requests each, in alternating order drawn at random and 500 ms apart. Each shot appears as soon as it comes back. We keep the sample with the lowest round trip, the one least affected by queueing delay. The second field offers ntp-8.rdem-systems.com, one of our own servers: it serves as a reference point, and it is measured exactly like the other.

What becomes of your query: if both servers answer and their names resolve to the addresses queried, the pair and its difference join the public table below. We record nothing about you — no address, no browser, no session — and private addresses are refused.

Latest measured comparisons

The last 20 pairs queried from this page, one row per pair. The difference compares the two servers with each other. We do not publish here each server's offset against our own clock, nor the round-trip times: those values describe our measuring infrastructure, not the servers queried. They do appear in the result of YOUR comparison, just above.

DateServer 1Server 2 DifferenceStratum 1Stratum 2
ntp2.tele.dk ntp-8.rdem-systems.com 0.4056 ms S2 S2
ntp1.tele.dk ntp-8.rdem-systems.com 0.2456 ms S1 S2
ntp.viarouge.net ntp-8.rdem-systems.com 0.7255 ms S2 S2
ntp0.fau.de ntp-8.rdem-systems.com 2.896 ms S1 S2
ntp-1.rdem-systems.com ntp-8.rdem-systems.com 0.1145 ms S2 S2
time.nrc.ca ntp-8.rdem-systems.com 8.8609 ms S2 S2
ntp-pool.rdem-systems.com ntp1.tele.dk 0.1694 ms S2 S1
ntp.netnod.se ntp1.tele.dk 0.1706 ms S1 S1
ntp1.tele.dk ntp2.tele.dk 0.0551 ms S1 S2
ntp13.rdem-systems.com pool.ntp.org 0.3648 ms S2 S2
ntp13.rdem-systems.com ntp-8.rdem-systems.com 3.0041 ms S2 S2
ntp.metrology.kharkov.ua ntp1.metrology.kharkov.ua 0.7048 ms S1 S1
ntp.metrology.kharkov.ua ntp-8.rdem-systems.com 1.0894 ms S1 S2
ntp.se ntp-8.rdem-systems.com 0.7008 ms S1 S2
ntp2.cam.ac.uk ntp-8.rdem-systems.com 0.6269 ms S2 S2
ntp.switch.ch ntp-8.rdem-systems.com 0.611 ms S2 S2
ntp-4.rdem-systems.com ntp-8.rdem-systems.com 0.1244 ms S2 S2
ntp.univ-rennes2.fr ntp-8.rdem-systems.com 3.6223 ms S2 S2
ntp.viarouge.net ntp1.unistra.fr 4.5601 ms S2 S2
paris.time.system76.com ns1.univ-montp3.fr 2.0273 ms S2 S2

These rows are one-off measurements, taken from our networks at the time shown. They say nothing about a server's lasting quality: that needs a series, which is what the observatory does.

Further reading

Free NTP Tools

Three independent tools to diagnose your time synchronization:

Frequently asked questions

Why don't two NTP servers show exactly the same time?

Because they do not follow the same source and do not sit at the same point of the network. Each corrects its own drift from its own upstream, and the round trip to us does not take the same time for both. A few milliseconds between two healthy public servers is therefore normal, and does not single out a culprit.

How large a gap between two NTP servers should worry me?

The order of magnitude matters more than the exact figure. A few milliseconds are explained by the network. A few tens of milliseconds deserve a second look. Beyond one second, one of the two is no longer synchronising: that is an operational fault, not measurement noise.

How can I tell which of the two servers is more reliable?

The gap alone does not say — you need a third point of view. Look at the stratum each one announces: a server closer to its physical source has fewer intermediaries. And repeat the comparison a few minutes later: whichever moves between runs is the less stable of the two.

Does this comparison measure the time from my own computer?

No. The requests leave our servers, not your machine, and the latencies shown are those of OUR network towards those servers. Your own offset will depend on your network path, which is not ours. The RELATIVE comparison between the two servers does hold: they are queried in alternating order, under the same conditions.

How many measurements are taken, and why alternating?

Three SNTP requests per server, sent alternately. Querying one then the other in blocks would let a drift in the network masquerade as a gap between the servers; alternating spreads that noise across both.