Hello Harlan, you wrote:
> If you use iburst in your config files and have a "good" value in the > ntp.drift file, ntpd should sync up and be ready to go in about 11 seconds. > > Please see: > > https://support.ntp.org/bin/view/Support/ConfiguringNTP > > and > > https://support.ntp.org/bin/view/Support/StartingNTP I wasn't aware of "ntp-wait" yet. Seems to do (almost) what we might want: Quote : ---- If you have services (like some database servers) that require that the time is never "stepped" backwards, run: ntp-wait -v as late as possible in the boot sequence, before starting these time-sensitive services. ---- In effect that is what we want to do before the start of our application. But it doesn't solve the problem fully for us. We would want on our "other hosts" to have it check remote ntpd. That way we would have: External NTPs <-> Entry Hosts <-> Other Hosts The "entry hosts" would do simply local ntp-wait before starting the application, but otherwise behave as normal. They only need to iburst and then use default poll values. The "other hosts" would do 2 ntp-wait on the 2 entry hosts. Only once either of them finishes, the ntpd is started and boot sequence continued. Et voila, our simultaneous initialization problems would be gone. Checking the man page of ntp-wait on my Debian Testing here (4.2.4p4) it seems we would have to enable the query of remote hosts first, but that sounds like a rather simple patch. The fundamental issue is that the "iburst" of the "other" hosts gets done before it is entirely useful (the entry hosts are only just synchronizing at best) and a remote ntp-wait could solve that. Best regards, Kay Hayen PS: Addressing the support suggestion too. We will consider it definitely. So far only our customers have had such contracts for their operational use. But as we start to provide a NTP monitoring middleware as well, the situation will be entirely different. There we don't control the NTP setup at all, but only monitor it and raise alarms that will frequently result in support questions to us. We would like to have a partner for these, I presume. I will raise the issue in a meeting next week. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions