[ntp:questions] [pool.ntp.org] 87 servers so far /web server configuration / some other small things
David L. Mills
mills at udel.edu
Tue Sep 23 16:17:33 UTC 2003
There already is a mechanism in ntpd to semi-automatically select which
stratum to favor if multiple strata are found. It is used with the
manycast scheme, where a client broadcast lights up a herd of potential
servers and the client needs to do some intelligent selection. Left
without any scheme of course, the client would latch on the three
lowest-stratum that survive the mitigation algorithms. The scheme uses
the experimental tos command with arguments:
minclock <value> sets the minimum number of servers surviving the
mitigation algorithms, normally three.
minsane <value> sets the minimum number of servers required to declare a
synchronized condition, normally one.
floor <value> sets the lowest stratum server used, normally one.
ceiling <value> sets the maximum stratum server used, normally fourteen.
cohort <value> sets a switch: 0 include servers at the same stratum as
the client, 1 do not include servers at the same stratum, normally set
Obviously, these are experimental and fixed by configuration at the
moment. The intent is to explore ways to make these values dynamic with
respect to the available server population, network ambient conditions,
etc. However, the same issues that come up in the pool strategy come up
in the manycast strategy, except the manycast strategy has the
additional feature of expanding ring search based on multicast
In the pool scheme the analog of expanding ring search could be based on
domain name. Ring zero is the set of servers in the same state, ring one
in the same country, and so on. I kinda like this approach or something
likee it, since support for the manycast thing is already in ntpd and it
might not be too hard to completely automate it in the pool scheme, as
well as the manycast scheme, or even both at the same time.
Tim Shoppa wrote:
> 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