[ntp:questions] "ntpd -q" is slow compared to ntpdate
unruh-spam at physics.ubc.ca
Wed Oct 15 17:01:09 UTC 2008
extproxy at gmail.com (Mohit Aron) writes:
>Thanks to everyone for responding on this thread. I'll attempt to answer the
>questions asked by others on my original mail. It'll be great if people can
>write constructively rather than using keywords like 'idiotic' etc which
>serve no useful purpose and only motivate me to just ignore your email.
>* There were some questions on why my ntp.conf uses the local time source
>127.127.1.0. This question is irrelevant to this discussion, which focuses
>on why 'ntpd -q -g' is slow. Anyways, the reason this was added was because
>if the server at 10.50.33.100 is down, then we found that ntpd would hang -
>but if the lines concerning 127.127.1.0 was there, the ntpd would still make
>progress if the external NTP server was down.
>* Someone suggested just running 'ntpd' and not the oneshot 'ntpd -q -g'.
>Again, not relevant to this discussion. But the answer is that the machine
>needs to start with the clock roughly synchronized - its ok to be running
>'ntpd' in the background later.
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.
>* There were some questions on what I'm trying to do here. Basically we sell
>a distributed platform containing multiple machines arrange in a
>master-slave architecture. The slaves need to be sync'd with the master when
>they start up. Slow bootup times are unacceptable - specially wasting 3
>minutes just to synchronize clocks is not ok. So the slaves need to quickly
>update the clock to roughly the same time as the master, and then later its
>ok for them to run ntp in the background. Since this is a custom
>environment, the slaves are totally willing to accept the master as the NTP
>source (the master is at IP address 10.50.33.100). So there's no reason for
>the ntp client at the slaves to not believe the first reply they see from
Except that ntp does NOT believe the first reply, since it has no idea what
the network is doing.
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.
ntp has a very bad habit of throwing away 7/8 of the packets it receives.
This is to account for assymmetric network delays, but to me is like
amputating a leg because you might have athelete's foot. It does this even
if there is no evidence whatsoever that there are such assymetric delays,
and despite the fact that they now have the huff and puff filter to account
for assymetric delays.
>* Someone mentioned that they're seeing sync'up times of 11s with 'ntpd -q
>-g'. Well, congratulations - unfortunately I'm not. And even if I was, I'd
>even call that slow. Wasting 11s on time synchronization during bootup is
>still unacceptable - this translates into the equivalent amount of downtime
>for our clients. I'm using ntpd version 4.2.4p4 running on Gentoo Linux -
>seems like that's a pretty recent version.
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
>I can imagine a huge hue and cry if ntpdate is actually removed - given the
>current slowness of 'ntpd -q -g'. The maintainers are welcome to remove it -
>but given the current state, people will just dig up the old source, or hack
>up a new one and keep using that until ntpd itself provides equivalent
>support inside it.
More information about the questions