Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
On Tue, 19 Jul 2016 23:18:18 -0700
Hal Murray hmurray@megapathdsl.net, time-nuts@febo.com wrote:
gem@rellim.com 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.
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.
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.
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. I'm
sure something else will crop up before 2017.
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.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Gary E. Miller wrote:
On Tue, 19 Jul 2016 23:18:18 -0700
Hal Murray hmurray@megapathdsl.net, time-nuts@febo.com wrote:
gem@rellim.com 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