On Wed, Dec 11, 2019 at 03:57:50PM +0700, Gerriet M. Denkmann wrote:
> chronyd does a good job of keeping the time in sync without big changes in
> the drift (freuquency).
>
> But there are a few situations, where an “aggressive mode” (i.e. drastically
> increasing the frequency) would be more appropriate:
>
> (1) at start
> (2) when there is a big time-error (ntp-time - cpu-time) (e.g. > 2 sec)
> (3) (at least on macOS) when the computer wakes up from sleep.
The speed of the correction is controlled by the "corrtimeratio"
directive. The default is quite aggressive. I suspect you may be
limited by the maximum slew rate. If you see a "system time"
offset value in the tracking report smaller than one second and
decreasing by about 500 microseconds per second, chronyd is at the
limit. The only way to correct the clock faster would be a step
(makestep directive).
> (3) On macOS there is usually a time-error of -1 … +2 seconds upon wake up.
> (rarely more than 2 sec) (this is only true with rtcsync working).
> The problem here: when chronyd thinks that all is stable, the next check with
> ntp might by delayed by up to 17 min (sometime up to 53 min).
> And for usual errors < 2 sec, case (2) does not apply. This results in almost
> an hour (depending of course on the wake-up error) until the time is correct
> again.
> Here I would like to see an “aggressive mode” until the time-error is down to
> a few msec.
So, here agressive means a shorter polling interval, so the correction
will start sooner? chronyd doesn't know when the system is
suspended/resumed, but there should be a system-specific way to run
"chronyc burst 4/4" when that happens.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
