Re: [chrony-dev] automatic RTC trimming

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Feb 15, 2012 at 10:10:00AM -0800, Bill Unruh wrote:
> On Wed, 15 Feb 2012, Miroslav Lichvar wrote:
> >Decouple only their frequencies. Currently, when there is a change in
> >the system clock frequency, the RTC samples are slewed according to
> >that change. This makes sense if their sample spans are similar, but
> >probably not much if the RTC samples are much older. If the frequency
> >adjustments are ignored, I think we'll get an accurate long-term RTC
> >drift.
> 
> Hmm, have to think about this. If we assume at all times that the system clock
> is accurate, then you are right. you sould just measure the rtc against that
> accurate system clock and the rate difference from 1 will be the rate error in
> the rtc.

Perhaps even better it would be to adjust only samples which are not
older than the samples kept in the currently selected source's
sourcestats. This should work well in both extremes, 64*1024s span
with NTP or 4*4s span with an accurate refclock. 

> >There already is the rtconutc option for that. But to have the
> >automatic trimming option enabled by default in a distribution, it
> >would have to work in both UTC/local times automatically. I think the
> >approach used in the 11-minute kernel sync mode which makes no
> >assumption about timezone and corrects RTC only within +-15 minutes
> >might be useful here too.
> 
> That 11 min mode must know about local/utc, or it is going to always adjust
> the clock to utc. That is the only time it has.

Kernel doesn't really know at what timezone RTC runs or even what
userspace uses, so it assumes it's the closest half hour one, this
means the RTC can be off at most by 15 minutes to be corrected. Larger
errors has to be corrected by hwclock or similar. Unfortunately this
doesn't work when DST changes, the RTC will be kept at the 1 hour
offset and if hwclock is not called on shutdown, users are required to
have RTC on UTC...

Anyway, it seems the amount of work needed to get the rtc code to a
state where it all works safely and automatically is quite large, so
I'll probably postpone it and work on releasing 1.27 first.

The only other things I had planned was a new option to panic on a
very large offset (like ntpd does by default) or ignore the samples
and perhaps add a leap second parsing from system tzdata to handle the
upcoming leap second with refclocks which don't provide that
information (gpsd).

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