Hello David, On Saturday, May 5, 2007 at 15:03:26 +0100, David Woolley wrote:
> Steve Kostecke <[EMAIL PROTECTED]> 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. -- Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
