[ntp:questions] The libntp resumee...
kayhayen at gmx.de
Sun Sep 7 05:50:21 UTC 2008
> > Now speaking about our system, not the middleware, with connections as
> > follows:
> > External NTPs <-> 2 entry hosts <-> 8 other hosts.
> What do you mean by "entry hosts"?
From our 10 machines, only 2 have connection to the "external" NTP servers.
The "entry hosts" are these and servers of the "other" 8 ones.
> > And iburst and minpoll=maxpoll=5 to improve the results.
> Use the default values of minpoll and maxpoll! Ntpd will adjust the
> polling interval within those limits. Ntpd is far smarter than you or
> I. It will normally start by using minpoll and increase the interval
> after it has initial synchronization. If network conditions deteriorate
> it will decrease the poll interval and increase it as conditions
> improve. IOW it will use the optimum poll interval for the conditions
> then obtaining. If you configured seven servers, you might observe ntpd
> using seven DIFFERENT poll intervals, one for each server because seven
> different servers will be reached by at least seven different network
Well, to my knowledge we did it because we observed improved convergence
behaviour on the 8 "other hosts", and particularily because it was not
working before. At the time they do an "iburst", none of the entry machines
may be running an ntpd yet, nor may it have completed its own iburst yet.
They all boot at the same time, so that would be why the low poll value is
used. As our system runs in isolated environments where people have full
control, polling this frequent (still only ever 32 seconds) is not a big
We have requirements to be able to run the software in x seconds after reboot
or else our customers acceptance tests fail. The requirement makes sense as
we are talking here about availability of service or not. Obviously the time
should be as small as possible.
For the servers behind the "entry hosts" I don't see how we could let ntpd
have its way when it's too slow.
Our requirements are abnormal, admitted. We require "equal" time on all 10
machines and that very fast.
I somehow think we should have something with ntpdate before ntpd is run. It
would waits for reachability of "ntpd" on the entry hosts and does an ntpdate
before running the local ntpd with an iburst that will then have less work to
do. (We shouldn't use a drift file in that case I presume, but due to issues
with the old middleware NTP supervision, we can't anyway.)
Then we could be faster and be robust against boot order variations.
More information about the questions