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

Mohit Aron extproxy at gmail.com
Sun Oct 19 22:15:35 UTC 2008

> Mohit> I don't think '-g' option to ntpd is a practical solution - since it
> Mohit> takes way too long to set the local time. Given this, people will
> Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
> Mohit> before actually running ntpd.
> Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
> http://support.ntp.org/bin/view/Support/StartingNTP .
> Just because ntpd -g is not right for *your* application doesn't mean it is
> wrong for everybody.
> And in the instances I run, 'ntpd -g' has the machine sync'd and moving
> along fine in about 11 seconds.

An 11s delay during startup is also unsatisfactory. I've read the links
you've posted, and I realize that 'sntp -r <server>' might be an appropriate
replacement for ntpdate (if that binary were to go away). Ideally I'd prefer
that ntpdate just stays - in script form if nothing else. I'm merely
responding to your comment that 'ntpd -q -g' was chosen as a viable
replacement for 'ntpdate'.

> - list each of your target goals
> - identify various implementation choices
> - identify the cost of implementing each target goal
> - identify the cost of *not* being able to implement each target goal

I believe I've already done this in one of my priori emails on this thread.
Anyways, here it goes again.

My company sells a distributed platform where one machine acts as a time
server for the rest of the machines. These other machines (that act as ntp
clients) can be removed/replaced and it is highly desirable that these come
up again quickly on startup and synchronize their time with the server
machine. To do the time synchronization, we run 'ntpdate' to do a quick
one-shot update of time, and then 'ntpd'  so that it takes care of
continuously synchronizing the time in the background. One of the admins
looked at the ntpd man page and decided to replace 'ntpdate' with 'ntpd -g
-q' - we started seeing 3 minute delays in starting up. I don't understand
why you only see 11s, but even if we were to see that, that'll still be a

All I'm suggesting is that the ntpd man page should be fixed since it is
clearly wrong when it says that 'ntpd -q' is an alternative for ntpdate.

> If your company would join the NTP Forum (see my .sig) you'd have the
> ability to discuss things like this to make sure you were on the right
> track, and if new functionality was needed you'd have a better avenue to
> get
> that implemented, too.

We are a small company and we don't have the bandwidth to join every forum
that's out there. I've raised the issue on this thread, and it seems others
are in agreement. I've also seen other threads that point out the same thing
(that 'ntpd -q' is too slow compared to ntpdate, and that deprecating
ntpdate is going to be a hassle). I hope the ntp maintainers find this
enough to guide their decisions than to require everyone to join a formal

- Mohit

More information about the questions mailing list