[ntp:questions] LOCL clock reachability not 377?

William Unruh unruh at invalid.ca
Wed Jul 30 16:52:01 UTC 2014


On 2014-07-30, Rob <nomail at example.com> wrote:
> 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.

I do not believe this was ever the case as the default. 
I agree that one needs an external source, or a leapseconds file to tell
ntpd when to impliment leapseconds.

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

I regard that as a bug. Whether the ntp developers do is another
question.



More information about the questions mailing list