[ntp:questions] stepping and slewing

Serge Bets serge.bets at NOSPAM.laposte.invalid
Tue May 8 22:13:03 UTC 2007

Hello David,

 On Saturday, May 5, 2007 at 15:03:26 +0100, David Woolley wrote:

> Steve Kostecke <kostecke at ntp.isc.org> wrote:
>> 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).
> My impression is that -gq will be faster. ntpdate is certainly faster.

I agree, and experimented with a 30 ms offset. The box has the good
frequency both in kernel (ntptime -f) and in driftfile. The ntp.conf
declares one server with iburst, and the driftfile. Slewing 30 ms at
500 PPM should take exactly 60 seconds, right? I monitored with repeated
ntpdate -q until zero offset:

 - ntpdate took 60 seconds.

 - ntpd -gq took 67 seconds. I guess 7 seconds to determine the offset,
and 60 to slew it (execution time is 7 seconds).

 - ntpd -g took much much longer... It took 7 minutes to cross the zero
offset for the first time. But the frequency was then wildly off (about
12 PPM over normal). Offset overshoot by about 8 ms in one way then the
other. Finally offset and frequency both stabilized. After 4 hours.

4 hours to amortize a 30 ms offset at startup... that's a high cost for
stopping machines during the night.

> The 0.5ms/s slew rates are relative to the static error in the machine
> clock, so they can reduce to almost 0 in one direction and almost
> 1ms/s in the other, in a system with a clock at the margins of
> usability.

Are you sure? I have here a machine whose natural driftfile is -100 PPM.
It still seems to slew 500 PPM in both directions, not -400 +600.

Serge point Bets arobase laposte point net

More information about the questions mailing list