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

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Thu, 21 Feb 2013, Miroslav Lichvar wrote:

> On Thu, Feb 21, 2013 at 10:17:39AM -0600, ray vantassle wrote:
> > > Can you please post your config and if possible also the tracking,
> > > measurement and statistics logs (configured by the log and logdir
> > > directives in chrony.conf) when that happens?
> >
> > Here is another run.  This time, it never synced up.  In fact, it
> > seems to have stopped making queries altogether, because the next
> > morning the REACH fields were all 0.
>
> Thanks for the data.
>
> It seems the problem is that chronyd can't recover because all
> incoming NTP packets are ignored due to failed test4. It tests if
> the absolute value of peer delay is shorter than 16 seconds.
>
> The peer delay is calculated like this:
> delta = local_interval - remote_interval / (1.0 - source_freq_lo);
>
> The source_freq_lo value is from the already collected samples and it
> seems to be very close to 1.0, which amplifies the remote_interval to
> thousands of seconds.
>
> 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. Perhaps a counter as well, because if this happens too
often something is seriously wrong somewhere (eg something is messing up the
local clock) and chrony should just give up. But like the -g to ntpd, fixing
something like this once on startup should be allowed, either in general, or
it a flag is set in configuration saying this should be allowed once, or twice
or whatever.

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


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