Re: [chrony-dev] chronyd not recovering after time stepped.

[Bryan Christianson <bryan@xxxxxxxxxxxxx>]

> On 27/08/2015, at 11:43 pm, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
> 
> On Thu, Aug 27, 2015 at 11:35:02PM +1200, Bryan Christianson wrote:
>>> On 27/08/2015, at 11:24 pm, Miroslav Lichvar <mlichvar@xxxxxxxxxx> 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 chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.