[LEAPSECS] My FOSDEM slides
joegwinn at comcast.net
Wed Mar 4 08:54:00 EST 2015
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
>>> So here it is:
>>> 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
>> 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.
> 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
> 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!
> 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
More information about the LEAPSECS