On 2014-07-30, Rob <nom...@example.com> wrote: > William Unruh <un...@invalid.ca> wrote: >> On 2014-07-30, Brian Inglis <brian.ing...@systematicsw.ab.ca> wrote: >>> On 2014-07-29 21:32, Paul wrote: >>>> On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis >>>> <brian.ing...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
