[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Thu Jul 31 16:33:05 UTC 2014


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.

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.

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

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.



More information about the questions mailing list