Harlan Stenn stenn at ntp.org
Sun Mar 1 15:35:20 EST 2015

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_prop
> agation_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.

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.

If we don't have it and we end up needing it, that causes different

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.

We've probably fixed about 3000 issues since 4.2.0 and people still run

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.

> 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.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!

More information about the LEAPSECS mailing list