[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 mailing list