Serge, Many, many times have I hollered that the ntpdate program is evil. That's why ntpd -gq was provisioned in the first place. The behaviou you report is bogus and completely broken. It does no good whatsoever to overshoot. To do that and then return to "normal" requires more than one call to adjtime().
Be carefully advised that some kernels attempt to speed up the slew using an exponental average where the time constant depends on the offset. This introduces an additiona pole in the impulse response and can well explain the overshoot, even if adjtime() is called only once. If that is the case, the only way to behave properly is to remove this "feature" from the kernel. Dave Serge Bets wrote: > On Wednesday, May 9, 2007 at 0:13:03 +0200, Serge Bets wrote: > > >>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. > > > Correction: ntpdate took 60 seconds to cross the zero offset. But it > continued slewing for 30 more seconds, ending at a -15 ms offset. > Looking at the source, this overshoot is a feature. > > > Serge. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
