[ntp:questions] Windows time question.

Dave Hart hart at ntp.org
Thu Apr 21 18:40:03 UTC 2011

On Thu, Apr 21, 2011 at 15:41 UTC, David J Taylor wrote:
> I would have hoped that the pool folk kept their documentation up-to-date,

It's easier to post a single configuration using "server" in ntp.conf
that works with any version of ntpd.

> so I'll post that on their list.  You didn't mention how to control the
> number of servers uses - is it just multiple "pool" entries?

I haven't researched when the "pool" directive in ntp.conf was first
introduced, but I know it's in 4.2.6.  Early in 4.2.7, the
functionality implemented changed to mirror "manycastclient"

For 4.2.6, each "pool" directive results in a single blocking lookup
of the name.  This is in contrast to "server" which uses nonblocking
lookups in a forked child process.  For each address returned by the
name lookup, 4.2.6 "pool" spins up a normal (persistent) association
unless the address is local or an association already exists for a
remote address.  Used with *.pool.ntp.org, that means each "pool"
generally spins up three associations.  From that point on, ntpd
operates as if the pool addresses had each been specified using
"server" -- in particular, servers which never respond or which stop
responding are used at least until the next ntpd restart or runtime
"unpeer" or "unconfig" via ntpdc or ntpq :config.

With 4.2.7, each "pool" directive spins up a refid POOL prototype
association, similar to the ACST prototype association for each
"manycastclient".  This prototype association contains the pool DNS
name as well as any as-yet-unused addresses left over from the prior
lookup of that DNS name.  Each poll, if there are less than maxclock
total associations, or less than minclock survivors, a solicitation
NTP packet is sent to the next address resolved from the pool name.
If the NTP server responds to this solicitation (which is a normal NTP
client request), a preemptible association is spun up for that
address.  So even with a single "pool" directive, eventually you can
expect maxclock associations or more (if needed to reach minclock
survivors).  Using multiple "pool" directives with 4.2.7 speeds up the
process, potentially overshooting maxclock by more.  When a
preemptible association is unreachable for a suitably long period, it
is removed.

http://www.eecis.udel.edu/~mills/ntp/html/discover.html has more.

Dave Hart

More information about the questions mailing list