Hello David, Am Sonntag, 7. September 2008 10:36:35 schrieb David Woolley: > Kay Hayen wrote: > > We could alternatively want to change ntpd in a way that the iburst lasts > > until a sufficient synchronization was achieved. But it appears to be > > more simply to delay the iburst by delaying the ntpd start until > > sufficient conditions are met. > > That's not going to be desirable. Although you might only use it on > your internal severs, it will soon get round on the grapevine that it is > a good thing to do, which will result in servers that are down or denied > to the client, or the networks of ex-servers getting bombarded with > large numbers of requests, whereas I believe the standard behaviour is > to back off under those circumstances.
Which is why I assume that the project won't accept patches that make ntp-wait work with remote hosts. Anybody correct me if I am wrong, because we would gladly contribute such patches. In the mean time, we can use the new libntpq to achieve the same effect. The use of ntp-wait on external servers would be pointless and harmful. It only makes sense to us, because we sort of _know_ that our startup process is in a race of all machines at the same time, because of the joint reboot, joint power up after (simulated) power failure. I think the 11 seconds that Harlan mentioned are something we definitely want to have, but fail to meet the preconditions on the "other" hosts, due to the lack of a waiting step. But if have measures in place to make sure that our "entry" servers are themselves synchronized themselves before bursting on them with our "other" hosts, then it will be all graceful I guess. If done correctly (async to other boot tasks), the delay in starting our application could become difficult to notice. And using the new-born libntpq with remote hosts, an implementation of ntp-wait for remote servers will be rather trivial to make. Well, to sum it up. I think I got a plan now. Best regards, Kay Hayen _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
