[ntp:questions] "ntpd -q" is slow compared to ntpdate
Richard B. Gilbert
rgilbert88 at comcast.net
Wed Oct 15 01:52:33 UTC 2008
Rick Jones wrote:
> Garrett Wollman <wollman at bimajority.org> wrote:
>> If you care about having reasonably correct timestamps in your logs,
>> you need to get a reasonably correct time established at boot time
>> before anything important starts.
> Would it be fair to say that "today" anyway, having the time be within
> a (large fraction of a) second (IIRC that is the precision of most
> system logs still today?) be sufficient?
>> Once the system time is validated, the rest of the system may be
>> permitted to start, possibly including a long-running ntpd. You
>> don't want that initial step happening after anything else has been
>> started, and the only way to convey this information to traditional
>> /etc/rc scripts is to have the program exit.
> And people (not just performance geeks :) are indeed concerned about
> the speed at which a system is up and running. Adding minutes to that
> is right out. Where in the realm of added seconds things are is a
> very fertile area for discussion.
>> That is how most systems use ntpdate(1) now, and that is why
>> distributors are so resistant to change (the well-known problems of
>> ntpdate notwithstanding).
>> What they probably actually want is a flag that says "delay
>> daemonizing until the first time the clock is set".
> But still want things to happen "quickly" for some relative definition
> of quickly that probably does not encompass the length of time most
> (and I do mean the term affectionately) time geeks would wait.
Much of the pain can be alleviated by not rebooting. I dunno about
Vista but W/XP can run for weeks or even months between reboots. If you
must shut down to save electricity or something, you'll just have to
start the machines a few minutes before they need to have the correct time.
More information about the questions