On Tue, 27 Sep 2016 23:45:18 +0100, Stephen Colebourne wrote: > Leap second smearing is a way of taking UTC (with leap seconds) and > mapping it to a view of time that always has 86400 subdivisions per > day. > > Tony Finch summarized five known approaches, which are all linear: > > Amazon -12h +12h > Bloomberg -0 +2ks > Google -10h +10h > QTnet -"about 2 hours" +0 > UTC-SLS -1ks +0 > > The goal of this thread is to see if consensus could be found for one > approach of smearing. > > The decisions would appear to be: > > 1) Linear or Other? > All current known smears are linear. Google previously had a different > approach, but changed to linear. Are there any major arguments against > linear? It would seem to be easier to specify and code that way. > > 2) When to smear? > Some smear up to midnight, some smear after midnight, some smear both > sides. What are the arguments for/against each? > > 3) Speed of smearing? > The existing approaches have two broad groups - fast (under an hour - > Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with > QTnet an outlier towards the fast end. What are the arguments > for/against fast/slow? Would there be a case for two agreed standards, > one fast and one slow? > > 4) Anything else?
In my experience, large systems that really care to avoid leap-second disruptions lock NTP to GPS System Time (not UTC) from the GPS receiver, and handle the leap-second offset in application code at the human interfaces and computer interfaces to external systems that understand only UTC. What's coming, due to IEEE 1588 PTP is that GPS receivers now have the ability to publish TAI (over the screaming objections of BIPM) as well, so many newer systems will lock NTP to TAI. In both cases, there is usually a parallel all-hardware path that distributes nanosecond-accurate time from the GPS receiver to all time-critical hardware. There is also usually another parallel all-hardware path distributing microsecond-accurate time. This path was traditionally implemented using IRIG-B AM over coax, but now IEEE 1588 PTP is trying to take that niche over, but this will require increased maturity. Joe Gwinn _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
