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

Steve Kostecke kostecke at ntp.org
Thu Oct 16 20:49:10 UTC 2008


On 2008-10-15, Mohit Aron <extproxy at gmail.com> wrote:

> ATTRIBUTION MISSING said:
>
>> 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.
>
> Yes, I realize that. However, it does mean that the time will be
> synchronized after a long time - the machine needs to do lots of
> startup stuff when it starts and its essential that the time be
> approximately correct when this happens. For example, it needs to log
> messages about various things - the timestamps on these log messages
> cannot be out of whack. That's why its important to update the time
> quickly in a single shot, and then run something like 'ntpd -g' which
> can keep the time in sync in the background.

Here's a possible explanation for your report of 'ntpd -gq' taking 3
minutes to sync:

When older versions of ntpd start up the Undisciplined Local Clock
(LocalCLK) will not be accepted as a "time source" until 4 polls have
elapsed. The first poll occurs at start up and the subsequent polls
occur at 64 second intervals using the default settings. So, using the
dafults, the quickest that ntpd can "sync" to the LocalCLK is a bit
over 3 * 64 seconds (192 sceonds or 3.2 minutes). When ntpd is started
with '-gq' and only has the LocalCLK as a time source it _will_ block
for a bit over 3 minutes. This "sync" time may be reduced a bit (to
about 50 seconds) by setting minpoll for the LocalCLK to 4 (i.e. 'server
127.127.1.0 minpoll 4).

Along the same vein, if the server is using the Undisciplined Local
Clock (LocalCLK) as it's time source _none_ of the client systems will
be able to sync to it for _at_ _least_ 3 minutes after it boots.

So using sntp at client start up may not be the panacea it appears to
be.

Even though it appears that sntp, or ntpdate, are "done" because they
return almost immediately the initial clock setting may have silently
failed because ntpd on the server is not available (whether it is
because the server is down or the server's ntpd is not synced is not
important). The client systems may be "free wheeling" for some time
before their ntpds are are able to poll the server and step their
clocks or initate the first slew.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/




More information about the questions mailing list