| Re: [chrony-dev] Let the kernel write the sys clock to RTC |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Fri, 14 May 2010, Håkan Johansson wrote:
Hi,
if I understand the discussion so far, there are two seemingly mutually
exclusive uses of the RTC:
a) Determining its actual rate, such that it can be used to set the system
time even after a long system shutdown. This requires (rather
accurate) knowledge of its drift.
b) Keeping it continously more-or-less up-to-date such that it can be used
to set the system time after a short system downtime. (11-minute mode)
Correction for drift is not needed here.
The reason b) conflicts with a) is due to the RTC only delivering time in
seconds, and therefore normal drifts, that are < 1 s / 11 min can not be
measured for a) due to the continuous spoiling by the updates of b).
NONONO. The rtc delivers time to the microsecond. It is just (like PPS from
gps) it only delivers it on the second. There is an interrupt which rtc
triggers when the internal rtc clock rolls over. That interrupt is very
accurate. Also setting the rtc is weird as the rtc hardware causes the first
interrupt after the time is set to occur excactly .5 sec after the time is
set. Thus you have to take that into account when you set the rtc (ie you set
it exactly .5 sec beforehand). But the rtc, except for its poor crystal (
higer than ideal drift rate) is very very accurate. (With the modern hpet
systems, and linux's handling of the rtc interrupt, this accuracy which is
still there, has been degraded.)
What if one can measure the RTC rate while using the 11-minute mode?
It is far far too short a timebase. And the kernel tends to set it a bit
randomly AFAIK-- ie it does not are if it is exactly every 11 min.
I presume that even if the RTC delivers only seconds when being read out, it
is delivering a correctly rounded time that is more accurate. So if one
after one 11-minute set of the RTC determines it's phase (i.e. accurately the
turn of a second), and does it again shortly before the next 11-minute set of
the RTC, then one could know the elapsed time of the RTC for a period of
about 10 minutes, with much better precision than 1 s.
The rtc beeps (triggers and interrupt) with very great accuracy ( much less
than a ms). It is just that it delivers that interrupt only once per second.
The idea would be to find the edges of the RTC by doing sort of binary-search
polling around it's edges, to find them.
Nope, it delivers and interrupt. NO need to search ( unless you are a linusx
kernel developer who throws away that interrupt)
E.g. begin by reading it every 0.1 s to get the edge location within 0.1 s.
Then, sleep (timeout) for .9 s, to be before the next edge, poll at 0.05 s to
find the edge. Then sleep another .95 s, and so on... One should timeout to
specific times and not really sleep for fixed amounts, to handle the cases
where one due to other system load misses the edges and need to back-up a
bit. Only samples which are sufficiently boxed in would be used.
Cheers,
Håkan (expecting to get shot down...)
--
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/