Re: [chrony-dev] Bug -- interaction between ntpdate and chronyd at bootup -- will never sync up

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Feb 21, 2013 at 11:40:47AM -0800, Bill Unruh wrote:
> On Thu, 21 Feb 2013, Miroslav Lichvar wrote:
> >I think the fix is to discard the old data when the frequency
> >estimate reaches a specified limit, similarly to the case when a
> >backward jump is detected.
> 
> Or when the skew gets too large. Clearly if the remote clock's frequency is so
> badly off and fluctuating ( or rather in this case the local clock's frequency is so badly off
> because chrony did not realise that the local clock had been reset) then it is
> time to start again.

Skew can get too large easily with short polling interval (iburst) and
there was a similar bug with stucked chronyd which was fixed by
clamping the skew.

In this case with large jumps forward the skew is very small. See the
data coming to the regress function:

0 -1.250000e+09 -1.720173e-01
1 -1.250000e+09 -3.137940e-01
2 0.000000e+00 1.250000e+09
slope: 1.000000e+00 skew: 1.676772e-06 offset 1.407935e+00:

I think the delta calculation could be changed to use interval * (1.0
+ freq_lo) instead of interval / (1.0 - freq_lo), that would avoid the
problem with slope getting close to 1.0.

> I would hesitate to just use the frequency since one of the advantages of
> chrony over ntpd is that it will compensate for frequencies offsets far above the
> 500PPM that ntpd allows.  Ie, it will compesate for bad but stably bad clocks
> (eg clocks which the OS has initialised badly on bootup.)

I was thinking about a much larger limit than the 10% which can the
Linux kernel slew.

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