[ntp:questions] "ntpd -q" is slow compared to ntpdate
unruh-spam at physics.ubc.ca
Tue Oct 14 18:29:34 UTC 2008
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?
>people that 'ntpd -q -g' is slow, but I haven't read about any suitable
>resolution to this issue. My own system uses 'ntpd -q -g' to synchronize
>with an Internal time server and the call to 'ntpd -q -g' takes more than 3
What internal time server?
>minutes to complete. This slows up the startup of my machine.
????? what are you doing?
>Here's the /etc/ntp.conf of my client machine (where the our local ntp
>server has the IP 10.50.33.100):
>restrict default notrust nomodify notrap noquery
You have this localclock why? It is idiotic, doubly so because of the way
you are using ntp. What the hell are are telling you machine it can use
itself as a time source for?
>server 10.50.33.100 iburst minpoll 4
>fudge 127.127.1.0 stratum 11
>I also ran a tcpdump to capture the ntp packets being exchanged between the
>client and the server. It seems the client sends a total of 13 requests to
>the server - each of which is responded to immediately. The first 9 requests
>are spaced at period of 2 seconds each. The 10th one is sent one second
>after the 9th request. The 11th one is sent 18s after then 10th. The 12th
>one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
>after the 12th one. Personally, I would have been extremely happy if 'ntpd
>-q -g' terminated after the first request was sent and the reply was
And I have absolutely no idea what you are trying to do.
>Issuing 'ntpdate 10.50.33.100' completes almost instantaneously. Before the
>ntp maintainers deprecate ntpdate, it would be wise to provide the
>equivalent functionality in ntpd. The current speed of 'ntpd -q -g' is
>unacceptably slow. I think it is also unwise to mention in the docs (e.g.,
>the man page) that ntpdate is deprecated without providing equivalent
>functionality. I've wasted a lot of time configuring our machines to use
>'ntpd -q -g' and now all that needs to be reverted back to use ntpdate. If
>ntpdate is indeed removed from a later ntp release, I'd have to just compile
>ntpdate from an older source version rather than use the dog slow 'ntpd -q
Perhaps you should learn to use ntp instead.
More information about the questions