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: [email protected] > 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 > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
