[ntp:questions] stepping and slewing

David L. Mills mills at udel.edu
Fri May 11 02:18:33 UTC 2007


Serge,

The NTP clock discipline doesn;t work like that. The ntpdate and 
imitator compute an offset correction, hand off the adjtime() and go 
home. The NTP clock discipine algorithm incorporates a feedback loop 
which includes a proportional control with time constant of several 
teens of minutes. See the arthictecture briefing at the NTP project page.

Dave

Serge Bets wrote:

> 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.




More information about the questions mailing list