Hello, > > 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 harm. 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
