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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
