[ntp:questions] [pool.ntp.org] 87 servers so far /web server configuration / some other small things

Tim Shoppa shoppa at trailing-edge.com
Wed Sep 17 13:00:11 UTC 2003

Brad Knowles <brad.knowles at skynet.be> wrote in message news:<mailman.14.1063740460.1857.questions at ntp.org>...
> >  An interesting debate was started by Tim Shoppa on the
> >  timekeepers at fortytwo.ch mailing list about the quality of the pool.ntp.org
> >  time service.  While I still think that anybody who really cares about
> >  accuracy should not be using the pool in his ntp.conf file, but should
> >  manually pick his servers, the concerns that the zone should be quicker to
> >  drop obvious falsetickers and unreachable servers are valid.  I will play
> >  around with a nameserver containing the whole pool, ntpq, and a database
> >  backend to store the pool information to see how I can automate the
> >  monitoring further.  I won't promise a date here, though - everybody knows
> >  that 24h/day are just too little time to do everything we want...
> 	Problem is, we need this kind of monitoring to be done at many 
> sites across the 'net.  Your view of how reachable or poorly 
> operating a particular server is may have little bearing on how 
> someone else might view that same server -- all due to network 
> issues.  To get a proper overall view, this needs to be done at 
> multiple sites so that we can try to average out network effects.

I started the discussion with trying to figure out how to force pool.ntp.org
into a more tree-like hierarchy with a smallish number of Stratum 1's feeding
a larger number of Stratum 2's that were publicly available.  While that's
a fine goal, that's not how pool.ntp.org works, and I eventually
became convinced that the centralized administration to *force* that to happen
is probably not the right way to go.  (It should still be encouraged, of

With respect to server quality... Trying to outsmart ntpd's highly
evolved falseticker determiniation is a Bad Thing.  Using
statistics gathered via ntpdc from a broad set of pool.ntp.org clients
will indeed be more useful than single-central-point monitoring.

Right now my thinking is heavily influenced by Minar's 1999 NTP survey,
but trying to take it a step further and evaluating quality locally rather
than from a central point.  (Minar and the other referenced surveys had
the advantage of a relatively fat pipe to everywhere around the world).


More information about the questions mailing list