Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
gem@rellim.com said:
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.
Do you know of any ntp servers that have picked the wrong month?
gem@rellim.com said:
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:
I wasn't considering refclocks to be "core" in that context. Got a better
word?
Have you found any similar code that isn't in one of the refclocks?
gem@rellim.com said:
20 years? My house is 40 years old. In an IoT world people would like to
not throw away capital equipment every decade.
Your house gets a new roof occasionally. The IoT world hasn't figured out
how to handle firmware updates and/or people haven't adapted to throwing out
gear that looks OK physically but has bugs, especially if the bugs don't
break the main function of the device.
gem@rellim.com said:
gpsd filters out all but June and December. So sort of cleanly, but clearly
work needed. ...
The sort of "cleanly" I had in mind would be at the project management level.
Handwave. Each project should keep track of the assumptions in their code
that may not be correct many years in the future. That list should be
reviewed occasionally, say every year or few years.
It also has to be documented in a way that downstream users know what they
are getting involved with. This is a good example. Tom is arguing for
do-it-right according to the specs. I'm arguing for defensive programming
since we have already seen bugs in other gear. If you were packaging ntpd
into a box which would you want? Will your box last long enough to see a
leap second in Mar or Sep? Is your box going to connect to old/buggy gear?
Does your startup have enough funding to consider issues like this, or people
smart enough to understand the tangle?
--
These are my opinions. I hate spam.
Hal Murray wrote:
gem@rellim.com said:
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:
I wasn't considering refclocks to be "core" in that context. Got a better
word?
Have you found any similar code that isn't in one of the refclocks?
ntpd versions before 4.2.6 also had a plausibilty check, which even had
a bug when checking for end of June. See:
http://bugs.ntp.org/show_bug.cgi?id=525#c0
gem@rellim.com said:
20 years? My house is 40 years old. In an IoT world people would like to
not throw away capital equipment every decade.
Your house gets a new roof occasionally. The IoT world hasn't figured out
how to handle firmware updates and/or people haven't adapted to throwing out
gear that looks OK physically but has bugs, especially if the bugs don't
break the main function of the device.
Firmware updates? Why would anyone need this? ;-))
gem@rellim.com said:
gpsd filters out all but June and December. So sort of cleanly, but clearly
work needed. ...
The sort of "cleanly" I had in mind would be at the project management level.
Handwave. Each project should keep track of the assumptions in their code
that may not be correct many years in the future. That list should be
reviewed occasionally, say every year or few years.
Agreed.
It also has to be documented in a way that downstream users know what they
are getting involved with. This is a good example. Tom is arguing for
do-it-right according to the specs. I'm arguing for defensive programming
since we have already seen bugs in other gear.
I'd say the best solution would be a combination of both.
If you were packaging ntpd
into a box which would you want? Will your box last long enough to see a
leap second in Mar or Sep? Is your box going to connect to old/buggy gear?
Does your startup have enough funding to consider issues like this, or people
smart enough to understand the tangle?
+1
Martin
On Wed, Jul 20, 2016 at 01:05:59AM -0700, Hal Murray wrote:
gem@rellim.com said:
Yes, I know the problem being solved. Like today, the leap second being
broadcast sooner than ntpd expects, so it picks the wrong month.
Do you know of any ntp servers that have picked the wrong month?
When I was writing up my leap second measurements, I went looking
for reports of leap seconds in unusual months (i.e. not in
June/Decembet) and managed to find the following:
http://lists.ntp.org/pipermail/questions/2007-October/015655.html
http://lists.ntp.org/pipermail/questions/2012-August/033611.html
http://lists.ntp.org/pipermail/questions/2013-July/035664.html
For the first, I think Windows was involved? For the second, I'm
not sure how many people accidently leaped. For the last, there was
definitely one leap.
David.
Hi Hal,
I guess you know this but...
I wasn't considering refclocks to be "core" in that context. Got a better
word?
Have you found any similar code that isn't in one of the refclocks?
ntp_loopfilter.c used to have code that restricted the months for
leap seconds. The new core ntpd code doesn't do this check, though
if you have an up-to-date leapseconds file, it will veto bad
suggestions.
David.