[ntp:questions] Re: ntpd, boot time, and hot plugging

[David L. Mills]

Terje,

Ick. replace my -g with -q. Mea stromboli.

Dave

David L. Mills wrote:

> Terje,
> 
> I am baffled by your comments. Your "perfect ntpdate replacement" 
> described is precisely what ntpd -g does.
> 
> Dave
> 
> 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
>>