[ntp:questions] ntpd -gq VS ntpdate -B

Steve Kostecke kostecke at ntp.isc.org
Mon Apr 30 03:14:06 UTC 2007


On 2007-04-12, RICCARDO <castellani.riccardo at tiscali.it> wrote:

> Thanks for your exhaustive explanation but I have also one doubt:

You're making this issue quite a bit more difficult than it needs to be.

As I, and others, have stated in this thread, the best way to keep your
clock synchronized on an ongoing basis is to just run ntpd (as the
daemon it is intended to be).

> If for example I used in cron "ntpdate -c server1 server2"

'-c' is not a valid ntpdate option according to the distribution
documentation at http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html

> (without taking accuracy but only convergence time) and local clock
> was different from NTP server time for 60 seconds, ntpdate will step
> time taking several hours !

If the clock offset is greater than 0.5 seconds (as in the ntpdate
manual which _you_ quoted below) the clock will be stepped unless you
use '-B' to force a slew. Steps are virtually instantaneous.

> How can it destructive ? Time will not adjust in few seconds but in
> several hours, I think.

Unless you deliberately change the default behavior of ntpd (or ntpdate)
an offset of more than 128ms (or 0.128 sec) will be stepped.

> Ntpd -qg with this time difference has the same behavior. Do you agree
> with me ?

ntpd -gq will step the clock if the offset is greater than 128ms (or
0.128 sec).

> See following reference of ntpdate manual:
>
> If  ntpdate determines  the  clock  is in error more than 0.5 second
> it will simply step the time by calling the system settimeofday()
> routine.  If the error is less than 0.5 seconds, it will slew the time
> by calling the system adjtime()  routine

This refutes some of your statements above.

Why don't you just run ntpd as a daemon and be done with this?

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




More information about the questions mailing list