[ntp:questions] Re: ntpd, boot time, and hot plugging
Richard B. Gilbert
rgilbert88 at comcast.net
Sun Feb 6 13:46:47 UTC 2005
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.
> 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
More information about the questions