[ntp:questions] Re: ntpd, boot time, and hot plugging
Brad Knowles
brad at stop.mail-abuse.org
Sun Feb 6 20:12:37 UTC 2005
At 8:08 PM +0100 2005-02-06, Brad Knowles quoted "Richard B. Gilbert"
<rgilbert88 at comcast.net>:
>> 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.
>
> I don't think that setting a hard eight second limit would be wise.
> If nothing else, there are potentially serious delays that can be caused
> while waiting for DNS queries to be answered.
Thinking about this a bit more, there are factors which influence
the startup time for ntpd (and ntpdate) which are beyond our control.
The best I think we could do would be to identify a lower bound on
the accuracy/precision that you would be willing to accept, and an
upper bound on the amount of time you'd like to be spent trying to
achieve that.
It's easy enough to figure out that if you reach the
accuracy/precision lower boundary before you reach the time limit,
you could either go ahead and set the time, or continue to try to get
more accuracy/precision up until you do reach the time limit. That's
easy.
The hard part is figuring out what to do if you reach the time
limit before you reach the accuracy/precision limit? Do you take the
risk of going ahead and setting the clock to a value which could turn
out to be catastrophic? Or do you wait until you have reached the
specified accuracy/precision limit?
I think that ntpd has achieved the best overall balance between
these two issues that it could reasonably do so far, and while I
think we may be able to tune this further (perhaps by using an async
resolver, among other things), I don't know how much more improvement
we can make in this area.
The introduction of the new "tos" control by Dr. Mills will give
you more thermonuclear foot-shooting room. However, I am not at all
convinced that it should actually be used by applications where those
few additional seconds of startup time are critical, for the reasons
previously discussed -- if you're that sensitive to startup time,
then you're almost certainly also more sensitive to time
accuracy/precision, and you're in precisely the situation where you
should avoid scratching that itch.
--
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the questions
mailing list