Re: [chrony-dev] Let the kernel write the sys clock to RTC

[Håkan Johansson <f96hajo@xxxxxxxxxxx>]

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

What if one can measure the RTC rate while using the 11-minute mode?

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 idea would be to find the edges of the RTC by doing sort of 
binary-search polling around it's edges, to find them.

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