Gary E. Miller wrote: > Yo [email protected]! > > On Tue, 19 Jul 2016 23:18:18 -0700 > Hal Murray <[email protected]>, [email protected] wrote: > >> [email protected] said: >>>> In general there's a common belief that a leap second can only >>>> occur at the end of June or December. This is false. Don't ever >>>> hardcode this assumption. >> >>> NTP Classic thinks otherwise: >>> http://bugs.ntp.org/show_bug.cgi?id=3D1090 >> >> If you read the fine print in that bug, you will see that it's a work >> around for a bug in the HP firmware that is the core of this >> discussion.
If it's known that certain devices out there have a certain bug then it's fine IMO to try to fix this in the device-specific part of the code, i.e. in ntpd's particular refclock driver. As Hal has already mentioned, I wouldn't consider the refclock driver as belonging to the core functionality, just because it is part of the code tree. > Yes, I know the problem being solved. Like today, the leap second being > broadcast sooner than ntpd expects, so it picks the wrong month. If the NTP specs say a leap second pending flag must not be set earlier than month or 1 day before the leap second occurs then the upstream software should account for this, regardless whether it's an upstream NTP server, or a refclock driver. >From ntpd's point of view: - If it receives a leap second announcement, in which case should the announcement be accepted; in which cases (buggy upstream sources) rejected? - When should ntpd start to pass a leap second pending flag on to its clients? - When should ntpd start to pass a leap second pending flag down to the OS kernel, so that the kernel can handle the leap second? If the leap second warning is passed too early then there's a good chance for confusion. If ntpd already has a current leap second file then it already knows about the upcoming leap second now, but it still doesn't pass a leap second pending flag to its clients, or to the OS kernel. Beside this there's still another point: - What should ntpd do if there are different upstream sources which disagree about an upcoming leap second? In current ntpd versions: - A leap second file has precedence unless it is outdated. - If no valid leap second file is available then a leap second warning from a refclock is accepted. - If no valid leap second file is available then a leap second warning from upstream NTP server is only accepted if a majority of servers provide it. >> I don't think there is anything in the core of ntpd that restricts >> leap seconds to Jun/Dec. If there was, it would have filtered out >> the above problem. There has been such a check before ntpd 4.2.6, but the code has been removed in current versions. > How about this: > > ntpd/refclock_hpgps.c, line 544: > > /* See http://bugs.ntp.org/1090 > * Ignore leap announcements unless June or December. > * Better would be to use :GPSTime? to find the month, > * but that seems too likely to introduce other bugs. > */ > case '+': > if ((month==6) || (month==12)) > > >> Things get interesting if you are shipping code today that will last >> for 10 or 20 years. My HP Z3801A has software dates from 1995 so 20 >> years isn't unreasonable. Of course, they were retired from >> commercial use a long time ago, so maybe it's OK if the firmware has >> bugs. > > 20 years? My house is 40 years old. In an IoT world people would like > to not throw away capital equipment every decade. > > But i'm prolly spitting into the wind... > >> I don't know any software projects that handle this sort of thing >> cleanly. (My exposure is limited.) > > gpsd filters out all but June and December. So sort of cleanly, but > clearly work needed. I notice ntpd also filters out leap warnings for > the first short bit of the month. That might be worth doing too. On systems which support this (Linux, *BSD, etc.) ntpd just passes a leap second pending flag to the kernel, and the kernel handles the leap second. However, ntpd has to keep track of its internal leap second flag which it sends out to the clients. So only if it polls the kernel status *after* the leap second has occurred and sees that the kernel's leap second flag has been cleared, ntpd can clear its internal leap second flag which it sends to the clients. So there's a chance that ntpd sends a leap second flag to client during a short interval after the leap second until it has polled the kernel status again and found that the leap second has passed by. So if clients accept a leap second flag in advance then it's important that there's some interval at the beginning of a month where they don't. > If a giant asteroid hits earth, and we need a negative leap second in > March, there will be a lot of urgent patching to do. Yes. Specifically, the German long wave transmitter doesn't have the possibility to announce a *negative* leap second. Martin _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
