[ntp:questions] stepping and slewing
serge.bets at NOSPAM.laposte.invalid
Tue May 8 22:13:03 UTC 2007
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
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