[LEAPSECS] A standard for leap second smearing

[Brooks Harris]

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" <scolebourne at joda.org>
> To: "Leap Second Discussion List" <leapsecs at 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 <dot at dotat.at> wrote:
>>> Steve Summit <scs+ls at 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 at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>