[ntp:questions] "ntpd -q" is slow compared to ntpdate
extproxy at gmail.com
Wed Oct 15 00:05:12 UTC 2008
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.
* 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
* 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.
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