[ntp:questions] Re: ntpd, boot time, and hot plugging
David L. Mills
mills at udel.edu
Fri Feb 4 16:58:22 UTC 2005
I am baffled by your comments. Your "perfect ntpdate replacement"
described is precisely what ntpd -g does.
Terje Mathisen wrote:
> Wolfgang S. Rupprecht wrote:
>> Brad Knowles <brad at stop.mail-abuse.org> writes:
>>> If you want to make that delay shorter, I guess you could
>>> package Stratum 1 refclocks with every machine.
>> I'd be waiting for minutes if I waited till ntpd decided it had a
>> "good enough" estimate of the Motorola Oncore's time. Ntpd *could*
>> have its first time estimate accurate to well under 1ms in half a
>> second on average. The problem is, it won't tell you the time or step
>> the system clock until it filters the crap out of the refclock signal.
>> Ntpd has a hard act to follow. The old ntpdate program was a near
>> ideal solution from the perspective of booting. It did its job
>> quickly and got off the pot.
> Except the few times when it messed up horribly:
> I had one of the my GPS-based stratum 1 server go bad on me a few years
> ago, and found out the hard way that _one_ critical server in our
> infrastructure had been configured to use this particular server as the
> only ntpdate reference:
> It was rebooted during the time interval before the failing ntp/gps
> server was located and turned off, with the result that this unix db
> machine came up with a wildly wrong date.
> After ntpdate had run, ntpd was started, but even though it had been
> configured with four server lines, only the temporarily broken server
> used by ntpdate was sufficiently close to be accepted, all the others
> were deemed falsetickers.
> A perfect ntpdate replacement needs to locate all or most of all the
> configured servers, and run at least a couple of packets to each server,
> and wait until a plurality have agreed on what the time is. This can be
> handled in an absolute minimum of about 3-5 seconds without polling each
> server more often than every two seconds.
> If you configure fewer servers, then you'd need more packets to each
> server before a sufficient reach value could be achieved for the set of
> servers that agree.
> The same goes in case of one or more falsetickers of course: They must
> be detected and filtered out, which requires more packets to all the
> servers than if they all agree.
> Prof. Mills' latest tweak, allowing you to tune (i.e. reduce) the
> required quality of the initial time estimate could be used to balance
> your need for believable time vs time to achieve first sync.
More information about the questions