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

Unruh unruh-spam at physics.ubc.ca
Mon Oct 20 02:36:33 UTC 2008


extproxy at gmail.com (Mohit Aron) writes:

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

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

It is clearly an alternative for ntpdate. It is just not an alternative
that you find acceptable. 

When you set up ntpdate and then ntpd it is not at all clear that ntpd will
actually keep it on time. If the frequency is out, ntpd will take about
three hours to bring it back into line, and the time will also drift off
during that time. Ie, just because at t=0 the time is correct does not mean
that at t=1hr it still will be. Now it should not be out by too much, but
it depends on what you accept as "too much" Ie, if you are happy with 20ms
then everything is undoubtedly fine. If you need microseconds it may be
a concern.




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

Time is of real concern to you, and the ntp forum is NOT "every forum
that's out there". You have strong views. You have spent a lot of time
here. It has been suggested that there is a vehicle for you to get directly
to the developers, and you now say it is too much to raise it in a forum
where you have direct access to the developers?

It is NOT a requirement. It was a suggestion about how you might be able to
have an influence. 






>- Mohit




More information about the questions mailing list