| Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
Yes, it is possible. Unfortunately the RTC was never designed to be a
particularly accurate clock. The OP now wants the RTC to get its time from the
system clock as well, which means that the RTC is no better than the system
clock, which are are then using to discipline the system clock. But for many
rtc you cannot set the RTC with any accuracy either (I recall that it has a .6
second offset on setting the clock, and can only set it to within a second).
As I mentioned far better is to use the thermal discipline in chrony to make
the system clock much better behaved and then use the system clock throughout
a few thousandth of a second accuracy, is millisecond accuracy. Network time
is good to a few microsecond. GPS discipline on chrony is good to a few
hundred nanoseconds. We have no idea what accuracdy he needs.
William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273
Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950
UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 _|_www.theory.physics.ubc.ca
I cannot reply to emails from outlook or hotmail or other microsoft domains.
On Mon, 31 Mar 2025, John Gilmore wrote:
[CAUTION: Non-UBC Email]
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.
--
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.