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 15 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
ntp.viarouge.net ntp1.unistra.fr 4.5601 ms S2 S2
paris.time.system76.com ns1.univ-montp3.fr 2.0273 ms S2 S2
nts.netnod.se ntp-8.rdem-systems.com 0.808 ms S1 S2
ntp.netnod.se nts.netnod.se 0.336 ms S1 S1
nts.netnod.se ptbtime3.ptb.de 0.2561 ms S1 S1
nts.netnod.se ntp.viarouge.net 0.358 ms S1 S2
time.cloudflare.com ptbtime3.ptb.de 0.6502 ms S3 S1
time.google.com ptbtime1.ptb.de 2.2895 ms S1 S1
time.windows.com ptbtime2.ptb.de 0.8117 ms S4 S1
time.google.com ntp-8.rdem-systems.com 2.2943 ms S1 S2
time.windows.com ntp-8.rdem-systems.com 0.7547 ms S4 S2
ntp-3.rdem-systems.eu ntp-8.rdem-systems.com 1.0489 ms S2 S2
ptbtime1.ptb.de ntp-8.rdem-systems.com 0.005 ms S1 S2
time.cloudflare.com ntp-8.rdem-systems.com 0.5718 ms S3 S2
ntp.obspm.fr ntp-8.rdem-systems.com 3.9514 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.