[ntp:questions] LOCL clock reachability not 377?
unruh at invalid.ca
Thu Jul 31 22:17:28 UTC 2014
On 2014-07-31, Rob <nomail at example.com> wrote:
> William Unruh <unruh at invalid.ca> wrote:
>>> Why? The time is copied to the CMOS clock regularly, and one could
>>> expect that during the short reboot the CMOS would not drift away so
>>> much that the time could not be synced to the PPS unambiguously.
>> Sure it could. And how does the system know what a "short reboot" is.
>> ntpd can hardly be expected to root throught the filesysytem trying to
>> figure out how long it has been since last boot, or how far off the rtc
>> is. ntpd distrusts the rtc at the best of times.
> Well, ntpd reads the stored estimated frequency error from disk too.
> The fact that it does all that is within its capacity to destroy this
> value does not matter.
>>> No, the problem is that the CMOS can only be set to an accuracy of one
>> Well, actually no. It can be set to an accuracy of about 1usec. And read
>> to that accuracy. It only reports the time the second it is true. But It
>> emits an interrupt on the turnover of the second. Of course for some
>> Linux kernels, the handling of that interrupt is seriously broken, but
>> even then it can be read by polling to a few usec.
>> Setting is a rococo procedure. You have to write to the rtc something
>> like .5 sec before you want that second to fall. But that can set it to
>> usec accuracy.
> You are mistaken. The running clock in Linux can be set and read that
> accurately, but not the CMOS clock.
I think you need to read up on the cmos clock. As I said, it reports
only the seconds, but is settable and "readable" to microseconds.
The seconds rollover is exactly on the second so polling could do it,
but it also issues and interrupt. And it is also settable to the order
Look at the code in hwclock as an example. Or the code in chrony.
More information about the questions