[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.
> Terje

More information about the questions mailing list