[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Thu Jul 31 20:37:00 UTC 2014


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



More information about the questions mailing list