[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Wed Jul 30 09:04:37 UTC 2014

William Unruh <unruh at invalid.ca> wrote:
> On 2014-07-30, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
>> On 2014-07-29 21:32, Paul wrote:
>>> On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis
>>> <Brian.Inglis at systematicsw.ab.ca> wrote:
>> These statuses show the same issue with local clock reach, implying if reach stays
>> at zero, sync will be lost and PPS become a falseticker without anything to number
>> seconds for too long.
> Once ntpd has started using the pps clock, there is no need for anything
> to number the seconds. The system itself does that perfectly fine. There
> is no way that the system is going jump a second, unless it is a very
> very badly broken system. Ie, one only needs something to number the
> seconds at the beginning when you start up PPS. Thereafter pps on its
> own is perfectly capable to maintaining the time. 

Yes, with the exception of those silly leap seconds, of course.

But they were implemented incorrectly.  When leapseconds went in the
timezone definitions and the NTP clock ticked in TAI, it would work.

However, when I lose my external NTP servers because again someone
is entering ACLs to fight some network storm, I prefer my clock to be
locked at least until the next leap second so I can find a workaround
for the problem.

What happened instead is that it started to drift shortly after.  I got
alerted by nagios when it was 10us off, which was within an hour or so.

That is why I added the LOCL clock and it solved that issue, but revealed
another one.

More information about the questions mailing list