Re: [chrony-dev] chrony after start/wake up

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Nov 28, 2017 at 05:29:35PM +0700, Gerriet M. Denkmann wrote:
> I noticed that it takes chrony about 20 - 40 minutes after start/wake up to settle down to a plausible value for frequency.
> (The offsets are fine after about 10 minutes - and not too bad before this).
> 
> What about this ( n =  20 to 40 minutes ):
> 
> if  t = time since start/wake up < n and  /var/lib/chrony/drift exists then
> 	usedFrequency = [  (n-t) * frequency from  /var/lib/chrony/drift  +  t * computed frequency from insuffizient data ] / n
> else
> 	usedFrequency = computed frequency from no longer insuffizient data
> end if

That might work well in your case, but I'm not sure if it can be
applied generally. For instance, with a good reference clock or local
NTP server using hardware timestamping, the frequency can be accurate
to few tens of ppb in a couple seconds, even when completely ignoring
the value from the drift file.

Another case where you wouldn't want to stick to the drift value too
much is when the TSC clocksource in the Linux kernel is recalibrated
after reboot.

There is definitely a room for improvements in the code which updates
the frequency. A new parameter could control the weight of the new
frequency/skew estimate relatively to the old values. Setting it to a
small value would shift the trust to the local clock, so it would
only slowly accept a different estimate of the frequency. I've seen
some patches that do that, although it wasn't configurable.

-- 
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.