[LEAPSECS] Hetzner mail to customers: 1 megawatt more power due to leap second

[Warner Losh]

On Jul 5, 2012, at 11:57 AM, Michael Spacefalcon wrote:


> Warner Losh <imp at bsdimp.com> wrote:

> 

>> I think this was more of a comment about how fragile our modern

>> infrastructure is when confronted with a Leap Second.

> 

> Yes, I agree that the evidence points in the direction of your

> statement.  But we probably disagree on what the right solution is.

> Per my religion, Leap Seconds are in the right and that stupid modern

> infrastructure is in the wrong.  Therefore, instead of getting rid of

> the former, get rid of the latter.

> 

>> Bugs that existed in the system for years weren't fully deployed in time for

>> the leap second. The result was what was outlined in the story.  Bugs that

>> would have been trivial to identify had any testing actually been done, I

>> might add.  And not only one bug, but 6 different, or interrelated bugs to

>> boot.  People didn't take the leap second seriously, since it is only a

>> second after all, so many people did understand the problems well enough and

>> made the decision not to deploy.  Many others never heard of the problem

>> because it is just a leap second after all, so didn't get much attention....

> 

> I see the problem as having a different root cause.  Leap seconds are

> good for one and only one thing: radio broadcast time signals that

> transmit a pulse per SI second.  *NO* other system should ever be

> exposed to leap seconds directly, i.e., leap seconds should be

> rubberized before being presented to systems (such as real-number JD

> and MJD scientific time notations, or UNIX/POSIX time) that see time

> as a scalar rather than broken-down HH:MM:SS.

> 

> What NTP and POSIX-pandering versions of Unix/Linux do nowadays

> (stepping the time backward and repeating a second) *is* the root

> cause of all of the "leap second" problems: it is an assininely stupid

> and wrong solution, and no amount of bugfixing or testing will ever

> fix it, until the root cause is eliminated.


No, what ntp and posix try to do, but fail, is conform to the UTC standard, which says that the extra second exists and you have to cope with it.


> Contrast it with a sensible solution like Google's leap smear or the

> UTC-SLS proposal.  The inherent instability (unpredictable frequency

> variation) of a normal computer motherboard quartz crystal oscillator

> is far greater than the difference in rate between physics-time and

> Earth-rotation-time, hence if one were to use an NTP-like scheme to

> steer computer clocks to the latter instead of the former, they will

> never know the difference.  Unlike UTC, GMT (or any other longitude's

> Mean Solar Time for that matter) does not have leap seconds or any

> other stupid aberrations.  But GMT is not directly observable and is

> not available in real time for NTP-like steering, hence we need a

> synthetic timescale that is synthesized from broadcast atomic time,

> but behaves like GMT, i.e., is rubbery rather than leapy.  A

> standardized, widely recognized and adopted scheme for converting

> leap seconds to rubber seconds is what we need.


This is well and good for most systems.  Some, however, are required to track leap seconds for a variety of reasons (say if you are generating IRIG signals that need to know, or if you have to timestamp events without the rubberyness of the google or utc-sls issues).   Also, controlling skyward pointing things need to not be on a rubberized scale.

I'd say the root cause is even simpler.  People just don't take leap seconds seriously, so the engineering effort to get them right isn't put forth, so we wind up with different levels of FAIL at each leap second.  In some ways, the marketplace of ideas has spoke: we don't care about leap seconds, please don't inflict them on us.  The standards haven't caught up with the facts on the ground for the vast majority of deployed systems.

Warner