| Re: [chrony-dev] automatic RTC trimming |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, 15 Feb 2012, Miroslav Lichvar wrote:
On Tue, Feb 14, 2012 at 09:37:35AM -0800, Bill Unruh wrote:
On Mon, 13 Feb 2012, Miroslav Lichvar wrote:
- track long-term drift: always keep a maximum number of samples
(disable the runs test), increase the maximum measurement interval
or do RTC sampling only on reference updates (NTP polling), decouple
RTC and system clock drifts (don't slew RTC samples on changes in
system clock frequency)
I do not know how you can decouple the rtc and system drifts since the only
time which the rtc can be compared with is the system time. If you change the
notion of what the system time is, you also have to change the notion of what
the rtc time is.
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.
- add an option to periodically trim RTC
Seems reasonable. Of course this means that one has to import into chrony, the
notion as to whether the rtc is on UTC of local time. As it is , the rtc can
be off by 8 hours, say (here in BC) and chrony will not object. But if chrony
trims the rtc, it has to know what to trim it to. Sys time ( meaning use of
UTC), local time, of some other time the user might want his rtc to run at.
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.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
--
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.