[LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

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