[ntp:questions] LOCL clock reachability not 377?

William Unruh unruh at invalid.ca
Thu Jul 31 17:03:37 UTC 2014


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. 

>
> Result: after the reboot, the system time was off by 270ms and the
> PPS was not trusted.  The time remained off by 270ms as indicated by
> a 270ms offset on PPS (marked with an x), and remained freerunning.

Yes, not entirely surprizing, especially considering the way ntp is
designed right now. This is a combination of bad ntpd design, and
restart when an external source is mandatory.


>
> Only after I managed to get a reachable external reference again, it
> stepped 270ms and then locked to the PPS again.

Not surprizing. A restart is NOT a situation under which I would expect
the local clock to keep resonable time, not least because when the
computer is off, it does not keep time at all. And the RTC is in general
a lousy source of time. 

>
> Of course this would not have happened when the system had remained
> running, as it normally would.  I rebooted it for major network reconfig
> and after that I was able to find NTP servers on another internet
> connection so it now has 3 external references again.
>
> 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. 

I never claimed that relying on the RTC was a good idea. I claim that
relying on the local system clock to keep time to within a second after
having been disciplined by ntpd and between ntpd PPS queries is a good
assumption. 



More information about the questions mailing list