Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC

[John Gilmore <gnu@xxxxxxxx>]

Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
> Not at all clear why you want to go via the rtc since it can only
> be queried to the nearest second anyway.

It's really simple to get an RTC timestamp that is accurate to much
more than 1 second.  You don't even need to use an RTC interrupt.
Software can come to the rescue of dimly built hardware.

Basically, your sofware loops as tightly as possible, reading the RTC,
and notice when it increments.  It will take you a maximum of 1 second
of tight polling to do that.  Then you have captured the tick as
accurately as the frequency with which you can query the RTC (many
thousands of times per second).

(There are complications if running multi-threaded when your polling
loop might be interrupted by other tasks, which you must take care
to account for the possibility of.)

If you don't want to dedicate a core or a bus to a continuous 1-second
loop, and you already have a higher-resolution timer in the system (as
in a modern PC Linux system), you can do this just as well over a few
seconds, with much lower (largely invisible) overhead.

Poll the RTC once, delay your polling process by a tenth of a second (as
measured by your higher resolution timer -- letting other tasks run
during that time), then poll it again.  Loop on that.  When you see it
has incremented, then you know (within your process scheduling latency +
1/10th second) the phase of when it ticked.  Now schedule a delay until
a tenth of a second before you think it will next tick.  After the
delay, do the high-speed loop reading the RTC and waiting for it to
tick; that should only take you 1/10th of a second of dedicating
polling.  You can insert a middle phase in which you do e.g. .01 second
delays in order to creep up on when you believe it will tick.  What you
want is to have your tight loop start running JUST BEFORE you think the
RTC will tick, so it will read the old value, then only spin perhaps a
few dozen or few hundred times, before it sees an accurately caught tick.

Then NTP can condition your high resolution (but volatile and drifty)
clock based on the recent tick.  You're done.  You can do this at
whatever frequency you like to measure the drift between the HR time
and the RTC.

	John Gilmore
	

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