Hi Tom,
Seems to me this conversation is drifting back and forth between objectives.
It started out to explore if a common method of smear could be found for
purposes as Google, AWS, and Bloomberg are using it. As I understand it,
the whole point there is to "hide" the Leap Second from the very many
consumers because its infeasible to anticipate the Leap Second behavior
of every device. Some of those may be ancient. It's used as a practical
matter for keeping the systems stable and the timestamps as accurate as
possible under the circumstances where the consumers cannot be ungraded
en mass. The point is exactly to fake out the consumers so they don't
choke. I think its a very good idea that systems do it the same way.
The conversation then moved to exploring once again some more ideal
method of handling Leap Seconds by somehow smearing within the consumer.
That might be OK for some purposes, but many applications just can't
accept or tolerate any frequency shifts in the timebase. That's why GPS
and PTP ignore date accuracy for machine and process control. They have
to because there's no reliable way to account for date and time with
Leap Seconds. In the video broadcast industry a frequency shift like a
smear would be catastrophic and a technique like that just can't be
considered. Frequency stability is fundamental.
There are fundamental irreconcilable conflicts between some ideal Leap
Second compensated timescale, even if we could agree on what that might
be, and the traditional 86400 second day based timescales. Even if a
good set of well defined and deterministic specifications for handling
Leap Seconds emerged it will be necessary to continue to support the
existing vast infrastructure of 86400-day devices.
Smear has become part of that infastructure, and refining it seems like
a very good idea to me. Its encouraging that representatives of Google
have joined the conversation. It seems like this thread should stay on
that topic and explore what Google has learned about the practical
application of smear in their environments, what their challenges and
objectives are and more detail on how they've handled them so far.
-Brooks
On 2016-09-28 11:31 AM, Tom Van Baak wrote:
NTP is designed to disseminate the SI second and a UTC timestamp. If you want a
completely different timescale (e.g., UT1, or some smeared variant of UTC) it seems like
this could be part of NTP, not some opaque hack below or above NTP so as to "fake
out" ancient or hardcoded assumptions of NTP.
Is it really easier and wiser to propose a universal layer of kernel
timekeeping hacks than to change how NTP works or how NTP is configured or how
UTC is defined?
/tvb
----- Original Message -----
From: "Stephen Colebourne" <scolebou...@joda.org>
To: "Leap Second Discussion List" <leapsecs@leapsecond.com>
Sent: Wednesday, September 28, 2016 7:40 AM
Subject: Re: [LEAPSECS] A standard for leap second smearing
On 28 September 2016 at 14:39, Tony Finch <d...@dotat.at> wrote:
Steve Summit <scs...@eskimo.com> wrote:
Me, I'd very much rather *not* add this sort of thing to (say)
NTP, because NTP doesn't have a problem with leap seconds.
This does seem true - hacking ntp feels like the wrong solution.
Except that every leap second is screwed up by a large proportion of NTP
servers...
True. But there are far fewer ntp servers than installations of an OS
kernel. So, it should be a more tractable problem to fix.
Stephen
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
