[LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> 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.
> 
> I have to admit that I wrote this before 4.2.8 had been released. 
> Support for negative leap second has been in older NTP versions, but 
> had been removed in 4.2.6.
> 
> Now in 4.2.8 the leap second code has been reworked and cleaned up, 
> and a very quick look at the source code seems to indicate that this 
> might work again. At least there's code which passes the announcement 
> flag to the kernel, if kernel support is enabled.
> 
> I think I'll give it a try soon. I'd expect that a negative leap 
> second might work if an appropriate announcement is received from a 
> refclock or upstream NTP server, but it will be interesting to find 
> out if this works with a NIST-style leap second file where the TAI 
> offset decreases at a given date.

Hell - lots of code can't handle a positive leap second, so what hope 
is there?

 
>> 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.
> 
> Yes.
> 
> Though I would prefer using TAI instead of raw GPS time if a linear 
> time scale is required. What if you use a different GNSS receiver, 
> e.g. for Galileo, or the Chinese Beidou?
> 
> GPS time (or whatever) is fine in closed projects/environments, but 
> IMO a UTC and TAI are the "global" time scales, while GPS is specific 
> to the U.S.

While TAI would be ideal for the reasons given, the problem is that TAI 
is not yet widely supported enough.  


>> 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.
> 
> I agree, but as I've tried to point out above I think a better 
> project design would have been to use TAI instead of GPS time. PTP 
> works natively with TAI, and you can easily convert between he two 
> scales.
> 
> Of course it's easy to convert GPS to TAI, and vice versa, but you 
> have to take care that more types of conversions are required and 
> implemented correctly.

Right now, GPS System Time is the best solution.  In ten years, I bet 
the answer will be TAI.

 
> Thanks for your feedback!

Quite welcome.

Joe Gwinn


> Martin
> -- 
> Martin Burnicki
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burnicki at meinberg.de
> Phone: +49 (0)5281 9309-14
> Fax: +49 (0)5281 9309-30
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
> Andre Hartmann, Heiko Gerstung
> Web: http://www.meinberg.de
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs