[LEAPSECS] Leap seconds have a larger context than POSIX

[Brooks Harris]

On 2020-02-06 5:22 AM, Tom Van Baak wrote:
>
> Hi Hal,
>
> It's 2020. How on earth can NTP still not implement UTC correctly, in 
> all cases? Or is it a fundamental NTP design flaw?
>
> The Z3801A issue doesn't sound like an NTP problem. This is a known 
> legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected 
> by one or even two GPS WNRO problems buy now?
>
If I understand this correctly Google Smear (and others, AWS, Bloomberg, 
etc) is a work-around to prevent possible system failure on 
leap-seconds. This is their primary concern, not leap-second accuracy. 
There are many potential ways a system or application might fail on 
leap-second depending on the implementations. At least one failure that 
was documented was what I'd call a 'stupid' bug where the code driving 
the output to the logging mechanism hung the kernel, setting off race 
conditions that took the whole data center down. It wasn't a bug in the 
handing of the leap-second itself but a bug in the reporting of the 
leap-second. Any given version of any OS might have some sort of bug in 
their leap-second handling or some related service.

Those data centers have millions of OS instances running on many 
different cpus (Intel, AMD, etc) on many different platforms (blades, 
etc), probably including various versions of Linux and Unix, Windows, 
Macintosh, and possibly main frame OSs. It is infeasible to upgrade all 
these at once only for leap-second or NTP updates because any OS version 
may have side effects that potentially upset the many critical 
applications running of each OS and it's subsystems. Potential side 
effects of the application behavior is a bigger risk than any 
leap-second behavior. The updates and upgrades must proceed very 
carefully in stages. Who knows how old some of these tiers might be. 
We've also heard complaints that many systems have not upgraded their 
NTP, with old systems still deployed. Its a very complex maintenance issue.

The potential practical problems related to leap-seconds implementation 
far outweigh the concern of accurate timekeeping. It will be many years 
before A) all OSs have identical and correct leap-second support 
(especially since the specs and common practices are vague and Windows 
is intentionally diverging from POSIX compliance), and B) the time-link 
systems, NTP, PTP, etc, also have identical behavior consistent with the 
OS's treatment.

It looks to me the smears will be with us for a very long time much to 
the frustration to those who wish computer timekeeping could be 
accurate. I don't see how consistency comes about without significant 
investment and this seems unlikely as the timing community debates the 
fate of the leap-second and no efforts are made to clarify the specs. 
The leap-second is evil but it looks like its with us for a very long 
time to come.

-Brooks

> /tvb
>
>
> On 2/6/2020 1:41 AM, Hal Murray wrote:
>> tvb said:
>>> There's no ambiguity. Those are just bugs. No software should depend on  more
>>> than 1 month notice of a leap second and no software should be  fooled if the
>>> notice is months or even years in advance.
>> There are plenty of quirks in ntp code along that line.  The APIs don't have
>> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
>> have most of the next day to turn it off.  The leap-pending on the wire is
>> leap-at-the-end-of-this-month.
>>
>> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
>> June or December.  It's a hack, but it gets the job done and the code wasn't
>> setup to ask it when the leap would happen.
>>
>>
>> tvb said:
>>> If you're writing a FAQ or best practices guide stay in touch. I have a
>>> semi-technical leap second report in the works. UTC is actually very  simple;
>>> but it's been complicated by untold levels of bad assumptions,  bad
>>> execution, and bad prose.
>> Are you going to say anything about POSIX?
>>
>>
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200206/718da89b/attachment-0001.html>