| Re: [chrony-dev] chronyd not recovering after time stepped. |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Fri, Aug 28, 2015 at 04:49:07PM +1200, Bryan Christianson wrote:
> > 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.
Ok. That explains it.
> > 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
> >
>
> Alternatively, and much simpler, we set an upper bound on drift_removal_interval of say 200sec
I like the former better. Would it make sense to always restart the
timer in set_sync_status() instead of waiting for the currently
running one to expire? I guess it would simplify the code a bit, but
there would be an extra adjtime() restart on every clock update. I'm
not sure if it's worth it.
--
Miroslav Lichvar
--
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.