[ntp:questions] "ntpd -q" is slow compared to ntpdate

Garrett Wollman wollman at bimajority.org
Tue Oct 14 21:55:25 UTC 2008

In article <iy5Jk.1480$fF3.1275 at edtnps83>,
Unruh  <unruh-spam at physics.ubc.ca> wrote:
>extproxy at gmail.com (Mohit Aron) writes:
>>I've ready in numerous places that ntpdate is going to be deprecated and
>>that one should use 'ntpd -q -g' instead. I have also read complaints by
>That does not help if the time difference is less than 128ms, as then ntp
>will simply use its algorithm ( which is very slow) to get the right time.
>But why in the world are you using the -q? Just let ntpd run and discipline
>your clock! Why in theworld do you want it to exit?

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.  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

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".

Garrett A. Wollman   | The real tragedy of human existence is not that we are
wollman at csail.mit.edu| nasty by nature, but that a cruel structural asymmetry
Opinions not those   | grants to rare events of meanness such power to shape
of MIT or CSAIL.     | our history. - S.J. Gould, Ten Thousand Acts of Kindness

More information about the questions mailing list