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

[Richard B. Gilbert]

Brad Knowles wrote:

> At 4:53 AM +0000 2005-02-06, Tom Smith wrote:
>
>>  Maybe a large part of your ntpdate time was printing out the messages.
>
>
>     Could be.  I doubt that could make it go from 0.7 seconds to 14 
> seconds, but it might have added a bit.
> <snip>


>
>     I know what you want to use it for.
>
>     You want a guaranteed less-than-one-second "good enough" answer 
> for doing any necessary large-scale changes to the clock, afterwards 
> you can start up various somewhat time-sensitive applications while 
> the system can start getting into the detailed long-term clock 
> maintenance "in the background".
>
>
>     Problem is, the things you can do in order to get the upper limit 
> down below one second are the same sorts of things which tend to give 
> you really nasty failure modes.
>
How is this different from setting the correct time by hand from your 
cell phone or wrist watch?   Doing it by hand is clumsy, slow, and, at 
best, only accurate to within a second or so (unless your reflexes are 
far faster than mine).  What nasty failure modes would that induce?  
What additional failure modes would doing it with ntpd induce?

I'm suggesting that ntpd query the usual suspects using iburst and then 
unconditionally set (not slew) the clock.  Assuming that you have a more 
or less accurate drift file, and use it, why would that not give a fast 
startup and a time accurate to within, say, twenty milliseconds?   The 
time budget would be something like eight seconds to send four queries, 
get responses, and make initial time and frequency settings.   Compared 
with 214 seconds to remove 107 milliseconds of a 127 millisecond offset, 
that looks pretty good when you are in a hurry to get you system back on 
line.