Re: [chrony-dev] makestep command sometimes makes chrony stop reading its sources

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Jan 20, 2010 at 10:50:39AM +0100, Hattink, Tjalling (FINT) wrote:
> So far the results are very good under normal conditions. When a
> properly synchronised SHM and PPS clock is provided and the rtc clock
> was already somewhat in sync the system converges in minutes after a
> cold boot! Also temperature changes are corrected a lot faster by Chrony
> than normally done by ntpd. Sometimes ntpd was off for milliseconds for
> hours when the temperature increased with 5 degrees, but Chrony was only
> drifting 300 nSec for half an hour.

Just curious, what vendor/model is the GPS card and what std dev
is reported in sourcestats in normal conditions?

Please note that currently chrony can't slew below microseconds, so
even when the reported std dev is very low, the real offset can't be
better than 0.25 us on average. (the remaining offset is reported in
the tracking output).

> What I'm testing is how chrony recovers when the RTC is way off during
> boot. In the bios I adjust the RTC clock with one year. Because Chrony
> is only slewing the clock it would take ages to recover from this
> situation, so I made a script that checks if the offset is too large
> (more than 30 seconds), and if so, issue a "makestep" command through
> chronyc to chronyd. This command immediately causes the system clock to
> be in sync with the GPS clock. Chrony keeps working fine when I adjust
> the RTC clock back one year in the past in the BIOS, but when I advance
> the RTC clock by one year Chrony stops reading its sources after the
> makestep command. It does not recover anymore. I had this running for 15
> hours and the sources command told me the LastRx was 15h for all
> sources. This problem is reproducable.
>  
> I think there are some absolute timestamps used in chrony that are not
> updated when makestep is issued.

Correct, the timestamps used in scheduler aren't updated when makestep
is performed. The problem is that scheduler needs to use raw time
(unlike pretty much everything else in chronyd) and adjusting only raw
time isn't reported by the ParameterChange system.

Probably the easiest fix is to move the makestep code from system
drivers where it goes unnoticed to local module and do two
adjustments, one to cancel the remaining slew and second to do the
actual step. This also makes the makestep command available on all
systems.

Please try the attached patch.

Thanks,

-- 
Miroslav Lichvar