Hi, Hal--
First, thanks for working on ntpd.
On Nov 17, 2009, at 5:01 PM, Hal Murray wrote:
The current ntpd tries to get 10 ntp servers. The current DNS for
things
like 0.pool.ntp.org returns 5 addresses so that's all that ntpd uses.
Is 10 a good number for ntpd to use? If not, what should it be?
Falseticker detection using the Marzullo's algorithm / "NTP Interval
Intersection" algorithm wants at least 4 timesources; 5 is a perfectly
reasonable # to use for standard polling interval of 1024 seconds. I
set up 3 peers and four different upstream sources when I was running
a set of four timeservers (1 internal, and 3 as stratum-2s in the NTP
pool), and that did fine for years, even if an upstream server or two
disappeared or changed IPs.
Would things be better for the pool project if their DNS servers
could return
more addresses and ntpd would only use 5?
There are two main cases to consider: end-user machines, which do not
provide time sync to anything else, and NTP servers which provide time
to many other machines-- they might be in the pool, published as
public stratum-1/2 NTP sources, or private within a company, ISP, or
whatever.
People who intend to run a NTP server can and will fiddle and adjust
as they see fit, so the main issue to get right is the legions of
client machines, WAN routers, firewall boxes, etc which are setup once
and never touched again by a human. IMHO, trying to make a 1-line
ntp.conf like:
pool pool.ntp.org # or maybe vendor.pool.ntp.org
...work as well as possible is likely to provide the most benefit.
Is the pool project happy having a knob so they can select how many
servers a
system using the pool config line actually gets to use? (If you
want to
change to 4 or 6, just change the number of servers that you return
when
answering a DNS query.)
Sure. Set it up to look for a reasonable default # of NTP
timesources, but let the user over-ride the default if they think they
know better. If the default is well-chosen, people generally won't
need to fiddle. 4 is the lower bounds, but 5 or 6 might be a little
more robust. I don't think there is any noticeable benefit to going
much larger than that.
What you said in subsequent mail:
Various enhancements are possible. I don't think anybody is working
on them.
One would be to occasionally (daily?) replace the least-good server
with
another one from the pool. If all clients implemented that, it
would be
possible to take a server out of the pool in a day or so.
...this would also be highly useful, because it would handle the case
where a server drops out, moves to a new IP, etc, without needing a
human to notice and bounce ntpd.
The pool command has been in ntpd for quite a while. It works in
the normal
case, but it doesn't (yet) work if the DNS lookup doesn't get an
answer when
ntpd reads the config file. (If that happens, ntpd sets up a separate
process to retry the DNS lookup occasionally. That process didn't
get the
pool vs server info.)
Perhaps I'm not being patient enough, but in the machine fleets I
manage, if two ntpds are running (one the child process supposedly
there to retry DNS lookups), the second one never goes away and ntpd
never starts sync'ing time, even if I wait for days. If it matters,
the most common case is running version=ntpd [email protected], but this
has been seen with older versions as well...
Regards,
--
-Chuck
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
