| Re: [chrony-dev] Question / Feature suggestion - trimrtc on start? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, 20 Jul 2011, Miroslav Lichvar wrote:
On Wed, Jul 20, 2011 at 05:24:35AM -0700, Bill Unruh wrote:
trimrtc is supposed to occur such that the algorithm to determine the rtc
drift rate compensates for the change in rtc caused by the trinrtc (all
entries in the prior rtc measurement table are shifted by the same amt that
the rtc is).
When the RTC is trimmed, the old samples are dropped and the
measurement starts from scratch. The reason behind this seems to be
that RTC can't be set very precisely (only to half a second?).
Hmm. You have looked more recently than I have, so you are probably right.
the rtc can be both set and read to much better than 1/2 sec, and chrony goes
to some effort to do so. In setting, the classic rtc had to be set exactly .5
sec before the time you are setting it to. But then its accuracy was I believe
usec accuracy. Reading was via the interrupt. Unfortunately, in recent ( 2.6)
kernels, the kernel people hafve totally screwed up the rtc timing. The
interrupt is remapped to the general system interrupt and can no longer be
used to exactly read the rtc, so reading is via polling (clearly less
accurate). The whole HPET emmulation of the rtc also plays a deliterious role.
So where once upon a time you could count on the rtc to actually be a very
accurate closk (a few PPM drift, and maybe 10s of usec read accuracy) it has
become a bit of a joke. This is another plank in the argument that the rtc
stuff in chrony has become somewhat outmoded. Its too bad.
I think the proposed option could behave similarly to running hwclock
--adjust on boot.
A related question is then - given I want chrony to learn a reasonable
estimate of RTC drift, plus I want to run trimrtc periodically, what is
a sensible frequency to set cron to call trimrtc? Hourly, daily,
weekly? What is the shortest sensible trim that will still lead to a
moderate estimate of RTC drift being learned?
The samples are collected in 15-480 second intervals and the maximum
number of samples is 64. I haven't done any experiments on how does
number of RTC samples affect the error in the drift estimate. I'd
probably go with the daily frequency.
The problem is that because of the thermal sensitivity of the rtc, it
fluctuates by many PPM over the course of a day (see the data on
www.theory.physics.ubc.ca/chrony/chrony.html where the rate of the rtc as
measured by chrony over the past 5 years or so can be found.)
I don't think there are many users of this feature. Generally, the -s
option (or hwclock --adjust) can't be used by default as there is no
guarantee that it's the only thing touching RTC. In my packages, I set
Well, the other thing is the hwclock call on shutdown which occurs in
certainly Mandriva, and probably redhat (since as I recall it was there
already when Mandrake branched off). I, as part of the installation routine
always remove those lines from /etc/init.d/halt (or wherever they move it )
the rtcsync option instead (the 11-minute kernel RTC synchronization).
That of course makes determining the drift rate of the rtc totally impossible,
and one just has to put up with the 80PPM drift rate that a typical rtc has.
(that is or order 10 sec/day).
If you always switch on shortly after you switch off, that is fine. If the
system is off for days at a time, it is not so good.
--
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.