[ntp:questions] LOCL clock reachability not 377?

William Unruh unruh at invalid.ca
Thu Jul 31 20:09:57 UTC 2014


On 2014-07-31, Rob <nomail at example.com> wrote:
> William Unruh <unruh at invalid.ca> wrote:
>> On 2014-07-31, Rob <nomail at example.com> wrote:
>>> William Unruh <unruh at invalid.ca> wrote:
>>>> On 2014-07-31, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>>>>>
>>>>> Unlike otherwise stated in this thread I don't think it's a good idea to 
>>>>> leave the 1 PPS signal alone disciplining the time of the NTP server. 
>>>>> This can easily yield unforeseen problems, similarly as if you use an 
>>>>> IRIG time reference which only provides day-of-year and time-of-day, but 
>>>>> no year number. If you don't take care then such signal can be accepted 
>>>>> and provide a "valid" time which is off by an integral number of years.
>>>>
>>>> My point is that most of the internal clocks on computers are well able
>>>> to maintain the time to better than a second for a long time, even if
>>>> they were freewheeling, and if disciplined by a PPS, they are able to
>>>> maintain the time forever (well, until the next power failure anyway). 
>>>
>>> There are complications.
>>> While the clock would probably be capable of maintaining the time
>>> within a second, it cannot be set to a reasonable accuracy.
>>>
>>> On the system-under-test, i.e. with the locked PPS source, the LOCL
>>> clock, and the unreachable external references, I did a reboot.
>>
>> A reboot is a restart and on a restart you need an external source for
>> the seconds. 
>
> 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. 

>
>>> I think you should be prepared for an offset up to half a second when
>>> saving the time to the CMOS clock, rebooting, and reading it back.
>>> Not good.
>
>> The problem is usually drift. The drift in a cmos clock is of order of
>> 10s to hundreds of PPM. At 100PPM, the clock will be out by a second
>> after only 3 hrs. 
>
> 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.



More information about the questions mailing list