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

[Gerard Ashton]

Michael Spacefalcon gave an overview of how a high precision system (which
he incorrectly supposed I possessed or ran) could interface to a low
precision system. But if a rubber time scale ever became law, high precision
systems might have to interface with each other indirectly through the
rubber time scale because of legal requirements. This would cause the
interface systems to operate a little differently near leap seconds than
they usually do, so there would be a potential for flaws to crop up. History
suggests these interfaces will not be tested frequently enough.

Also note that this time it is medium-precision systems that failed; the
coarse systems like Windows desktop systems that invoke their NTP client
once a week did fine, and did fine when interfacing with medium-precision
systems if the medium-precision systems were operating at all.

Gerard Ashton

-----Original Message-----
From: leapsecs-bounces at leapsecond.com
[mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Michael Spacefalcon
Sent: Thursday, July 05, 2012 5:28 PM
To: leapsecs at leapsecond.com
Subject: Re: [LEAPSECS] Hetzner mail to customers: 1 megawatt more power due
to leap second

Gerard Ashton <ashtongj at comcast.net> wrote:


> Michael Spacefalcon wrote " a standardized, widely recognized and 

> adopted scheme for converting leap seconds to rubber seconds is what we

need"

> but also mentioned "a normal computer motherboard quartz crystal 

> oscillator". But of course there are systems that are far more 

> accurate than a normal computer motherboard by necessity, and those 

> systems will not be able to use rubber seconds.


Ahh, there is a critical misconception: while it is true that systems
needing high-precision timing can't be reasonably asked to deal with rubber
seconds as long as every Alice and every Bob does his/her own ad hoc
rubberization (like Google said they did), I argue that rubber seconds will
become perfectly OK even for precision-timing systems if the rubberization
scheme were standardized.

Consider this example: suppose I were to create my own micronation, call it
the Principality of Falconia, and declared UTC-SLS to be Falconia's official
legal time.  Suppose you are an operator of a high-precision timing system,
but some legal/social/cultural requirement compels you to display Falconian
legal time in the user interface, which has the rubber seconds of UTC-SLS.
Yet you want the displayed time to be precise to the nanoseconds or even
finer.  Can it be done?  I say yes, because simple algorithmic
rubberizations like UTC-SLS (or my own UTR proposal, which is essentially
the same thing, but politically independent of UTC) derive their "rubber
time" by an *exact algorithmic formula* from atomic time.

So you could build your fancy high-precision timekeeping systems using
cesium fountains or whatever, using a TAI-style timescale as a low-level
internal implementation detail, but export a timescale like UTC-SLS to the
"civil/social time" layer, the software layer that handles all human-visible
times.  It would still be a high-precision timing system, i.e., the rubber
second times displayed by Alice's system can still be made to agree with
Bob's system down to nanoseconds or whatever finer time precision you fancy.


> But at some point there will be an interface between the rubber second 

> systems and the precise systems.


We already have this interface issue in the present world during "normal",
non-leap-second times.  I am using a system whose timekeeping requirements
are extremely coarse by the standards of this list (being within a few
seconds of GMT is all I need), and given such low level of requirements,
I've chosen an implementation that is accordingly crude: each of my VAXen
currently polls an ntpd-enabled Linux box once an hour or so, asking for the
time, then does a single
adjtime(2) call.  You, on the other hand, probably run a much more
precisely-timed system.  Yet we are able to exchange these emails without
any apparent problems.  That's an example of a low-precision- timing system
interfacing to a high-precision-timing system, isn't it?

It would be no different in a world standardized on UTR or UTC-SLS.
Each system would choose a high-precision implementation or a low- precision
one according to its needs, and the interoperability issues would be no
different from those that already exist currently during normal,
non-leap-second times.

Suppose that a rubberization scheme were officially defined as something
like this: "At such and such precise time, the length of the civil second
changes from exactly one SI second to exactly 1.001 SI seconds. At such and
such precise subsequent time, it changes back to exactly one SI second."  A
high-precision timing system could easily implement these rules exactly,
such that any two such systems anywhere in the world would exactly agree on
the rubberized civil time.  Yet a low-precision timing system like a bedroom
wall clock could be built much simpler: not bother with the exact
rubberization rules and simply reset the clock to something "approximately
right" at some hour of the night like the current cheap RC clocks do.

The different choices made by low-precision systems differing from the
high-precision ones can't be construed as a new interface problem: it is no
different from the present situation in the absence of leap seconds, where a
low-precision system is expected almost by definition to have an
unpredictable time delta from the official precise time, usually on the
order of a few seconds, sometimes a minute or two.

SF
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs