Ken Hornstein wrote:
Hmm...maybe I don't understand your problem, but I thought that was how ntpd worked. When the clock isn't right, ntpd needs to both step the clock and possibly change the clock frequency. When the clock frequency isn't quite right, then stepping the clock will work for a while, but it will still drift off. So, ntpd will repeatedly readjust the clock and clock frequency until it doesn't drift much. I believe that ntpd has an algorithm to slowly adjust the clock frequency to minimize effects of intermittent bad data points.This has been bugging me for a while now, and I thought I'd finally say something about it. On my TS-7200, ntpd has some issues synchronizing the clock. Specifically, when ntpd starts up, it finds the time servers normally and does the initial time step to get the clock close enough. But after that time step occurs, the clock is off by a variable amount; sometimes it's close to a second, but a lot of the time it's around a quarter of a second. E.g: Dec 7 20:28:57 modred ntpd[302]: frequency initialized 0.000 PPM from /var/db/ntp.drift Dec 7 20:30:30 modred ntpd[302]: time reset -2.381602 s Dec 7 20:30:30 modred ntpd[302]: kernel time sync status change 0001 Dec 7 20:46:32 modred ntpd[302]: time reset +0.906469 s Dec 7 21:02:04 modred ntpd[302]: time reset +0.573713 s Dec 7 21:18:06 modred ntpd[302]: time reset +0.201409 s Dec 7 21:33:12 modred ntpd[302]: time reset +0.198393 s Eventually what will happen is that ntpd will get "lucky" and get the time within the 128 ms slew threshold, and then ntpd will function normally. I've been trying to figure out what's going on here, but I've had little luck. Does anyone have any ideas? Or even an idea of where to start? --Ken
From: http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm <http://www.eecis.udel.edu/%7Entp/ntpfaq/NTP-a-faq.htm>, Section 5.
Instead, *ntpd*'s reaction will depend on the offset between the local clock and the reference time. For a tiny offset *ntpd* will adjust the local clock as usual; for small and larger offsets, *ntpd* will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and *ntpd* will terminate itself, believing something very strange must have happened. ...For a general discussion see Section 3 <http://www.eecis.udel.edu/%7Entp/ntpfaq/NTP-s-sw-clocks.htm>. Also keep in mind that corrections are applied gradually, so it may take up to three hours until the frequency error is compensated...
From the ntpd man page:-x, --slew Slew up to 600 seconds. Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete. This option can be used with the -g and -q options. See the tinker configuration file direc- tive for other options. Note: The kernel time discipline is disabled with this option.
Hope this is what you were asking. Regards, Don