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

Mohit Aron extproxy at gmail.com
Wed Oct 15 17:35:02 UTC 2008

> If you run ntp -g, it WILL roughly synchronize it in exactly the same way
> as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp,
> except once it first sets the clock, it exits.

Yes, I realize that. However, it does mean that the time will be
synchronized after a long time - the machine needs to do lots of startup
stuff when it starts and its essential that the time be approximately
correct when this happens. For example, it needs to log messages about
various things - the timestamps on these log messages cannot be out of
whack. That's why its important to update the time quickly in a single shot,
and then run something like 'ntpd -g' which can keep the time in sync in the

> Are you running on Linux or windows? If on Linux, you might want to look at
> chrony, which is much faster in converging to the right time, and
> furthermore is better at disciplining the clocks once it is running.
> If you are on Windows, chrony does not work.

I'm running on Linux. One of the links posted in this thread helped me find
a good alternative to ntpdate - which is 'sntp -r <server>'. I'll check out
chrony too, but it seems sntp will probably serve my purpose.

> The usual way of starting up machines is to use the machine's own rtc to
> start up the clock. Using a recent hwclock, this use can be quite accurate
> ( better than a second after a day's downtime). Not sure what your
> requirements are.

The issue is that when new machines are added to the cluster, their times
might be completely out of whack. So hwclock can in general not be relied
upon. Also, we use VMware based virtual machines for internal testing - such
machines can't keep their hwclock ticking while they are powered down.

- Mohit

More information about the questions mailing list