Harlan,
On Sun, 01 Mar 2015 20:35:20 +0000, Harlan Stenn wrote:
> Joseph Gwinn writes:
>> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
>>> Hi folks,
>>>
>>> I've been asked off list to make the slides of my presentation at
>>> FOSDEM 2015 in Brussels available and post the download link on this
>>> list.
>>>
>>> So here it is:
>>>
>>
<https://fosdem.org/2015/schedule/event/technical_aspects_of_leap_second_propagation_and_evaluation/>
>>>
>>> See the "Attachment" link.
>>
>> Very interesting; thanks for posting this.
>>
>> I have a few questions and comments:
>>
>> 1. Slide titled "Known Bugs (2)": Has support for negative leap
>> seconds been restored in NTP v4? It wasn't clear.
>
> Not yet. It's a tradeoff.
>
> We've never needed to delete a leapsecond and depending on who you ask
> it will probably never happen.
So long as UTC can do negative leaps, and the Earth is a wobbly clock,
the possibility is always with us.
> If we add the code to handle it, we increase complexity, potentially add
> in a (pretty small) abuse vector (a bad actor could find a way to tell
> your system to delete a second), and make some small demands on the test
> framework that we want to have.
The abuse vector argument is pretty weak -- the attacker could just as
well add a leap second. In both cases, one is off by a second. So, I
would submit that it's support for leap seconds that provides the
attack surface, and the area of that surface is not reduced by
elimination of negative leap seconds.
> If we don't have it and we end up needing it, that causes different
> problems.
>
> There is a parallel issue about folks who cannot or do not upgrade their
> software. Over 1100 issues were addressed between 4.2.6 and 4.2.8 and
> people still think 4.2.6 should be "good enough" for them.
Certainly in my world, changing software is a big deal, because one
needs to rerun all the regression tests. Changing NTP isn't as big a
deal as changing the OS or the C++ compiler and/or libraries, but still
people are wary.
> We've probably fixed about 3000 issues since 4.2.0 and people still run
> that.
>
> We don't have numbers for the number of bugs fixed between xntp3.5f,
> xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0.
>
> These older releases are still running out there, too.
And don't forget NTPv3 - bet lots of those still run.
Once people get a system to work, they don't tend to go fixing things
that ain't broke.
>> 2. Slide titled ""Possibilities for Future Improvements (2)": In the
>> wish list for a kernel call to ask if the kernel runs UTC or TAI, a
>> couple of issues come to mind. First, many systems set the GPS
>> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System
>> Time option may be needed. Second, we often have the GPS (or PTP 1588)
>> receiver to emit GPS System Time, but never share this with downstream
>> servers, who are configured for UTC (but strangely the leap seconds
>> never come). The difference between UTC and GPS System Time is handled
>> in applications code. The reason for this approach is so that the bulk
>> of the system is free from step discontinuities, and only the
>> interfaces need deal with UTC.
>
> This issue is also address by NTF's General Timestamp API, as
> "timescale" is one of the data elements of this timestamp. We have
> already done a proof-of-concept to get these timestamps used as the core
> part of the kernel timekeeping API. There is clearly more work to be
> done here. We know how to do this work, we just need technical and
> financial support to make it happen.
Great. Is this API a parallel to the named clock interface of POSIX,
where the OS kernel vendor can add named clocks that are not in the
POSIX standard - what is standardized is the mechanism for defining and
using special purpose clocks unknown to POSIX.
Joe Gwinn
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
