[ntp:questions] The libntp resumee...

Kay Hayen 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
> paths!

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. 

Best regards,
Kay Hayen

More information about the questions mailing list