[time] Accuracy goal of the pool?

Rob Janssen rob
Sun Nov 5 11:13:13 UTC 2006


Michael Zimmermann wrote:
> Greetings,
>
> in the archives I found some discussion earlier this year
> (Subject was  "Effect of a DSL connection") where systemic
> offsets of one or two msec where discussed.
>
> But when I started to use the de.pool.ntp.org for my internet servers,
> I immediatedly got a Stratum 1 with a constant offset of 50 msec.
> Its pool-statistics showed this server to be consistantly 'acceptable'.
> And because of his S 1 that server started to dominate all others.

I don't think a stratum 1 server is dominating others.  At least not in
recent versions of ntpd.  It may be in older or substandard NTP
implementations, which unfortunately a very widespread.

But that aside, I think the current monitoring server lacks the capability
to get good data on the offset of each server.  What it does is to poll
each server once every couple of hours, and put the single response
that it gets (or does not get) into the statistics.  This means the offset
shown on the www.pool.ntp.org pages is more indicative of the random
network delay between the polling server and the time servers in the
pool, than of the actual accuracy of those servers.

For example, my server is always within 1ms and usually within a
few microseconds (locked by three radio receivers, one of which is
a GPS receiver with PPS output which usually is the selected reference).
However, when I look in the plots I see offsets of usually several
ms and peaks of up to a few hundred ms.  However, when looking at
a few servers at work that are locked to local clocks and my server, I
see that this offset is not really there.

So when you would want to have some much closer ruling about offset,
there would need to be a better monitoring system first.  It would
probably best be some distributed system where many servers take
statistics for a couple of peers (preferably close on the net) using the
normal ntpd mechanisms, and the statistics are collected by a central
server for pool server selection.

Without such a mechanism, perfectly valid pool members will drop
out of the pool because of random network delays.  But of course it
would be quite some work to set it up.

I agree with you that the pool is not for millisecond-fanatics.  But 
compared
to wristwatch time, it does a good job.  Anyone caring for accuracy on
a LAN should setup one or two servers synchronized to the pool and
to eachother, and reference all their internal systems from there.  This
does not only reduce traffic to the pool, it also makes the systems on the
LAN run synchronized to eachother, which is much more important than
exact synchronization to the real time.

Rob


More information about the pool mailing list