Google public NTP servers to 'smear' leap seconds.
"For timekeeping purposes, December 31 will seem like any other day." https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-...
Thanks for the heads-up. It looks like this is the last time Google will use a 20-hour linear smear for a leap second; next time Google plans to use a 24-hour linear smear, as that is more popular elsewhere. They are proposing the latter as a standard practice everywhere. See: https://developers.google.com/time/smear
On 2016-12-01 14:10, Paul Eggert wrote:
Thanks for the heads-up. It looks like this is the last time Google will use a 20-hour linear smear for a leap second; next time Google plans to use a 24-hour linear smear, as that is more popular elsewhere. They are proposing the latter as a standard practice everywhere. See: https://developers.google.com/time/smear
Careful with systems that are subject to any audit, legal or regulatory requirements to discuss with auditors and lawyers; or any interfaces with those systems, especially external systems that may not be smearing. Your bids, nominations, offers, payments, settlements, trades, or other transactions may miss deadlines or schedules - businesses may lose deals and money, people jobs, and civil or criminal sanctions could apply. See http://xkcd.com/1499/ -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Brian Inglis wrote:
Careful with systems that are subject to any audit, legal or regulatory requirements
As I understand it Google wants to smear leap seconds the same way major cloud providers do, the idea being to come to a working consensus that could eventually become standard and legal. In a sense, this implements McCarthy and Klepczynski's proposal to do away with leap seconds -- a proposal that crashed and burned in the ITU -- in a different and arguably better way. I wonder who first proposed and implemented the 24-hour linear scheme that Google plans to switch to next time. It's not always that easy to change Google's collective mind. Was it someone at Akamai? Amazon? Microsoft? Come to think of it, we should document leap smearing. Proposed patch attached.
Paul Eggert <eggert@cs.ucla.edu> wrote:
I wonder who first proposed and implemented the 24-hour linear scheme that
Google plans to switch to next time. It's not always that easy to change Google's collective mind. Was it someone at Akamai? Amazon? Microsoft?
When I did a survey of leap smear schemes in September, only Amazon was doing -12 to +12 smear. Google originally did a sinusoidal smear, but I gather that interacted worse with ntpd and large polling intervals than piecewise linear. https://www.mail-archive.com/leapsecs@leapsecond.com/msg06152.html
Come to think of it, we should document leap smearing. Proposed patch attached.
It's probably worth noting that ntpd now has an open implementation of leap smear. Here's a link to the documentation in their Bitkeeper repo: http://bk1.ntp.org/ntp-stable/README.leapsmear Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn-- zr8h punycode
Tony Finch wrote:
When I did a survey of leap smear schemes in September, only Amazon was doing -12 to +12 smear.
Amazon has 10x the capacity of the next dozen cloud service competitors, according to Gartner. Microsoft (which Gartner says is #2) also uses a 24-hour smear, according to Google. So to some extent Google may be saying that it'll bow to the market leaders.
It's probably worth noting that ntpd now has an open implementation of leap smear.
Thanks, proposed patch attached. This also tones down the wording a bit, responding to John Hawkinson's comments (which I plan to reply to shortly).
As we have learned the hard way, words put into the tz distribution matter, and sometimes have profound effects (cf. questions about whether abbreviations used by the tz distribution propoaged elsewhere, or reflect common usage, etc., etc.). We should choose words with care, and be silent the rest of the time.
+# with it, use "posix_only" or "posix_right". POSIX time is often combined +# with leap smearing,
Leap smearing is still an experimental activity, and its consequences are not well-understood. I do not think we can fairly say "often" used, or "often" combined with POSIX time.
as this is more accurate than strict POSIX time
I don't see how the accuracy or precision improves with leap smearing. Some could say it degrades.
+# and it often works better than "right" time with applications that +# are not leap second aware.
Again, I don't think there is support for claims of "often."
+ tz-link.htm now covers leap smearing, which is popular in clouds.
I don't know that leap smearing is "popular." It is used by Amazon and Google for sure. I'm certainly not comfortable saying it is popular when we don't have to say anything. The biggest problem we have with leap smearing is that smeared time is not clearly traceable. If it were in its own zone and we could see Sat Dec 31 23:59:59.999 UTC 2016 versus Sat Dec 31 23:59:59.499 UTC-SMEARED24h 2016 then the world would be improved. I don't know that the tz package can usefully get us there. But if not, I think the less said in the tz distribution about leap smearing, the better. I am similarly uncomfortable with the text added to tz-link.htm, but if there isn't broad agreement that we should be a lot more careful in our language, it's not helpful to critique that. --jhawk@mit.edu John Hawkinson
John Hawkinson wrote:
I do not think we can fairly say "often" used, or "often" combined with POSIX time.
Although it's pretty common, we indeed don't have to say "often".
as this is more accurate than strict POSIX time
I don't see how the accuracy or precision
With leap smearing, the ideal clock is at most 0.5 s off UTC, as opposed to being at most 1.0 s off with strict POSIX time.
we don't have to say anything.
Given the popularity of leap smearing, and the fact that this Makefile section advises users whether to use "posix" or "right" time, the section should say something -- otherwise people are more likely to incorrectly choose "right" time on a system that uses leap smearing.
The biggest problem we have with leap smearing is that smeared time is not clearly traceable.
Yes, that would be a nice problem to fix somehow. Perhaps append "-A" to the time zone indication when the clock is using AWS-style leap smearing? And we could append "-P" for strict POSIX time (hmm, but that's the default, so perhaps not....). Just thinking out loud. Anyway, it's not a problem we can easily fix just by changing Makefile comments. Proposed Makefile patch attached.
Paul Eggert <eggert@cs.ucla.edu> wrote on Sun, 4 Dec 2016 at 23:33:05 -0800 in <5915ef83-dbde-9e26-814a-fe4bc7192d06@cs.ucla.edu>:
Although it's pretty common, we indeed don't have to say "often".
I'm not sure how we get to common. Even if we accept that the majority of cloud service providers now perform some sort of leap smearing (a point I doubt), that doesn't make it actually "common" in the Internet. What is the gain from our publishing seemingly authorative information from this experimental practice? Anyhow, your patch only changes the Makefile, not the tz-link.htm file, which is probably more important because HTML gets indexed and viewed more. Would you like me to take a stab at that?
as this is more accurate than strict POSIX time
I don't see how the accuracy or precision
With leap smearing, the ideal clock is at most 0.5 s off UTC, as opposed to being at most 1.0 s off with strict POSIX time.
Err...I think we would say that with a leap smearing, the clock is KNOWN to be inaccurate, by up to 0.5 seconds, and a POSIX UTC clock is exactly correct, except maybe during the one second of the positive leap. Therefore smearing is less accurate, not more accurate. I guess it might be more precise because POSIX's leap behavior might be deemed as inaccuracy, but I don't know. These words are not well suited to this (and therefore it's best not to use them).
Given the popularity of leap smearing, and the fact that this Makefile section advises users whether to use "posix" or "right" time, the section should say something -- otherwise people are more likely to incorrectly choose "right" time on a system that uses leap smearing.
If people are choosing "right" on the basis of what's in there, something is probably terribly wrong, and we make it too easy for them to foot themselves in the shoot.
The biggest problem we have with leap smearing is that smeared time is not clearly traceable.
Yes, that would be a nice problem to fix somehow. Perhaps append "-A" to the time zone indication when the clock is using AWS-style leap smearing? And we could append "-P" for strict POSIX time (hmm, but that's the default, so perhaps not....). Just thinking out loud.
Paul Goyette would, I believe, ask me to say something here that asks how the tz maintainers feel about making up abbreviations. I don't think there is much merit to a shorter more cryptic suffix versus a longer more verbose/explanatory one. Although the trick would be to only print this extra information when the smearing was in effect. Maybe that's too ambitious. By the way, I hesitate to mention this, but Martin Burnicki from Meinberg did a writeup comparing the effects of different smears on ntp that may be of interest: https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf (Discussion of this on the leapsecs list, rather than here, please.) Except I don't think we should really be influencing the smear experiment at all. Maybe I'm an outlier here. --jhawk
John Hawkinson wrote:
your patch only changes the Makefile, not the tz-link.htm file
I changed tz-link.htm in the previous email.
I think we would say that with a leap smearing, the clock is KNOWN to be inaccurate, by up to 0.5 seconds, and a POSIX UTC clock is exactly correct, except maybe during the one second of the positive leap.
There's no "maybe" about it. The POSIX clock stops cold during a leap second, and is therefore 1 s off just before the leap second finishes. I.e., the POSIX clock is also known to be inaccurate.
If people are choosing "right" on the basis of what's in there, something is probably terribly wrong
That part of the Makefile was not-so-subtly advocating "right" time. That advocacy made sense when "right" time was the only automatic way to deal with leap seconds. Nowadays other approaches are more popular in practice, so it makes sense to tone down the advocacy and to say how "posix" and "right" interoperate with these other approaches, which is what the recently-proposed changes are trying to do.
Paul Eggert <eggert@cs.ucla.edu> wrote:
That part of the Makefile was not-so-subtly advocating "right" time. That advocacy made sense when "right" time was the only automatic way to deal with leap seconds. Nowadays other approaches are more popular in practice, so it makes sense to tone down the advocacy and to say how "posix" and "right" interoperate with these other approaches, which is what the recently-proposed changes are trying to do.
I don't think `right` time interoperates with anything :-) It really ought to come with a huge warning banner telling anyone who chooses it that they will have a huge pile of 37s offset bugs. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Southeasterly 3 or 4, occasionally 5 at first in east. Slight or moderate. Mainly fair. Good, occasionally poor.
Paul Eggert <eggert@cs.ucla.edu> wrote:
With leap smearing, the ideal clock is at most 0.5 s off UTC, as opposed to being at most 1.0 s off with strict POSIX time.
It's a bit more complicated than that :-) There are a number of variations of leap smear. The ones that centre the smear interval on the leap second have an up-to-0.5s divergence from UTC. The ones that have the whole smear interval before (or after) the leap second have an up-to-1s divergence from UTC. If I understand the ntpd documentation, they have implemented a configurable smear interval that occurs before the leap second. If you have a traditional ntp setup without kernel leap second support, ntpd will react to a leap second by slewing the clock after it realises it is one second wrong, when it next polls its servers after the leap second. This is effectively a leap smear after the second, implemented as a side-effect of ntp's sync algorithms rather than being deliberately specified. Ops people have often configured ntpd to work this way rather than using kernel leap second support in order to avoid the clock appearing to go backwards, which frequently causes enormous consternation for sensitive software. Explicit leap smear is a more principled way to avoid this kind of upset, rather than old-ntp-style smear-as-a-side-effect. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5, veering southerly 5 or 6. Slight or moderate. Occasional drizzle later. Moderate or good, occasionally poor later.
On 2016-12-05 04:04, Tony Finch wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote:
With leap smearing, the ideal clock is at most 0.5 s off UTC, as opposed to being at most 1.0 s off with strict POSIX time.
It's a bit more complicated than that :-)
There are a number of variations of leap smear. The ones that centre the smear interval on the leap second have an up-to-0.5s divergence from UTC. The ones that have the whole smear interval before (or after) the leap second have an up-to-1s divergence from UTC.
If I understand the ntpd documentation, they have implemented a configurable smear interval that occurs before the leap second.
Note their provisos not to provide smear on public servers - to avoid legal issues; NTP must be rebuilt to support smear and be configured with a leap file and smear interval; server and peer times are still UTC, only client packets are fudged with the current offset, and they contain a refid address of 254. followed by 2 integer bits and 22 fractional bits of the signed (negative) offset from 0..-1s, calculated using the Google cosine formula. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
participants (5)
-
Brian Inglis -
J William Piggott -
John Hawkinson -
Paul Eggert -
Tony Finch