[ntp:questions] stepping and slewing

Steve Kostecke kostecke at ntp.isc.org
Thu May 3 18:23:51 UTC 2007


On 2007-05-03, castellani.riccardo at tiscali.it wrote:

> I'm going to use ntpd -qg to synchronize my Linux DB "clients"
> because I think today machine clocks are enough accurate

They're not. That's why you need to use ntpd as it is intended to be
used: as a daemon.

> and I don't await significant offsets (between real time and local
> time) from first synchronization,

If your clock is less than 128ms off ntpd slews it. The slew will take
the same amount of time regardless of how ntpd is running (e.g. as a
daemon or via a cron-job w/ -gq).

The quickest way to set your clock is to use '-g' on the ntpd command
line and iburst on the ntp.conf server lines. This allows ntpd to
initially set the clock regardless of how far off it is _and_ the
initial sync to your time server(s) will occur in (probably) less than
15 seconds. Just keep in mind that ntpd needs to be allowed to run for
20 minutes, or so, the first time it is started as a daemon.

Once ntpd has run long enough to determine the correct PLL frequency,
and write it to the drift file, ntpd restarts are very quick.

If you want to make sure that the clock is set before the database is
started you have a couple of options:

1. Run 'ntpd -gq' and allow it to block the boot process while the time
is set and then start ntpd (as a daemon).

2. Start ntpd (w/ -g and iburst) and make the boot process wait until
ntpd reaches state 4. There is an ntp-wait (?) script in the
distribution that can be used to make the boot process wait for ntpd.

> my opinion is to not use service but a program which starts at
> specific intervals.

The problem with this approach is that the clocks will drift during
those intervals. If you wait too long between cron-jobs you may end up
stepping the clock backwards at some point.

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




More information about the questions mailing list