> On 27/08/2015, at 11:43 pm, Miroslav Lichvar <[email protected]> wrote: > > On Thu, Aug 27, 2015 at 11:35:02PM +1200, Bryan Christianson wrote: >>> On 27/08/2015, at 11:24 pm, Miroslav Lichvar <[email protected]> wrote: >>> That is odd. How long is the polling interval? It shouldn't take more >>> than 6-10 new measurements after the step for the frequency to get close >>> again to the right value and correct any remaining offset. >> >> The polling interval is 8 seconds. And indeed, when I restart chronyd it >> only takes a few cycles to correct the offset. >> I'm not seeing any significant change in frequency, maybe 1ppm (from 17.5 >> ppm) for just a few samples after the step and then back to 17.5. > > Ok, that probably means it's something in the driver or the kernel. > It might help us to see what values at what time is adjtime() getting > and what it returns.
I think I figured it out. When the time is stepped there is a big spike in offset_sd. This causes the drift removal interval to be increased to a very large value (aprox 2 hours in the trace I just looked at) and then applied when the current drift cycle completes. So for the next 2 hours, clock adjustments in start_adjust() are having a predicted offset of 30 ms or so. When the very long drift removal interval expires, then things go back to normal - offset_sd is now small and the system rapidly recovers. I think the drift removal cycle should be restarted if the newly calculated interval is significantly different from the value of current_drift_removal_interval -- Bryan Christianson -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
