On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris <[email protected]> wrote:
> On 2020-02-06 9:08 AM, Warner Losh wrote: > > > > On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak <[email protected]> wrote: > >> Hi Hal, >> >> It's 2020. How on earth can NTP still not implement UTC correctly, in all >> cases? Or is it a fundamental NTP design flaw? >> > > Design flaw. NTP time stamps can't encode a leap second. It can therefore > never really work in all cases. We are left with what hack do you want to > do today. > > You can't fit 86401 pegs in 86400 holes. Something's got to go. No > agreement on what goes. > Exactly. We have a number of different hacks that we use to keep the problems under control, to discard potentially bad data, to filter bad data that we can't discard, etc. It's a series of hacks that usually work well. Not because it's well specified, but because different implementations have programmed defensively to ensure that the current spec + unwritten policy rules + some known past bugs are filtered so ntpd doesn't react when it's likely a bad time. This will fail, of course, if we ever have a leap second in March or September. It's working for the conditions we have today, which is great, but it's not robust or resilient. > The Z3801A issue doesn't sound like an NTP problem. This is a known legacy >> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or >> even two GPS WNRO problems buy now? >> > Known past issues are likely future problems. 40 years in software has > taught me that we do not always learn and apply the lessons of the past. > Every 5-10 years we swap out the coders that learned them for newer, > cheaper labor. Or there are new players in a niche that have more hubris > than tribal knowledge. This guarantees bugs will repeat. > > Especially in the absence of clear specifications. > Yes. That's exactly what I meant by tribal knowledge. We could all tell long stories about how we learned all the details because of that absence... Warner > Warner > > > /tvb >> >> On 2/6/2020 1:41 AM, Hal Murray wrote: >> >> tvb said: >> >> There's no ambiguity. Those are just bugs. No software should depend on more >> than 1 month notice of a leap second and no software should be fooled if the >> notice is months or even years in advance. >> >> There are plenty of quirks in ntp code along that line. The APIs don't have >> an explicit when. The NTP-Kernal API for leap-pending is leap-tonight. You >> have most of the next day to turn it off. The leap-pending on the wire is >> leap-at-the-end-of-this-month. >> >> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was >> June or December. It's a hack, but it gets the job done and the code wasn't >> setup to ask it when the leap would happen. >> >> >> tvb said: >> >> If you're writing a FAQ or best practices guide stay in touch. I have a >> semi-technical leap second report in the works. UTC is actually very simple; >> but it's been complicated by untold levels of bad assumptions, bad >> execution, and bad prose. >> >> Are you going to say anything about POSIX? >> >> >> >> >> _______________________________________________ >> LEAPSECS mailing list >> [email protected] >> https://pairlist6.pair.net/mailman/listinfo/leapsecs >> > > > _______________________________________________ > LEAPSECS mailing > [email protected]https://pairlist6.pair.net/mailman/listinfo/leapsecs > > > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs >
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
