Re: [Ntp] NTPv5 draft

[Magnus Danielson <[e-mail]>]

Warner,

On 2020-12-08 21:11, Warner Losh wrote:
> Magnus,
>
> On Tue, Dec 8, 2020 at 8:53 AM Magnus Danielson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Agree fully. You bring up a point which I think not all is
>     appreciating.
>     While we may develop protocols for the Internet, does not mean
>     that they
>     actually have access to the network, or that such access is open
>     in any
>     normal sense. For such air-gaped networks update cycles can also
>     be long
>     enough that for instance leap-second file cannot be sent along each
>     upgrade to ensure correct leap-second list that way.
>
>
> When I implemented the LORAN-C timing system refresh at Timing
> Solutions, this issue was the biggest issue we had. We could get leap
> seconds from the GPS, and had to resort to a number of ad-hoc methods
> to distribute from there. Especially since we needed to cope with the
> scenario where a computer fails and is replaced by a spare that had
> been on the shelf for 5 years, but still had the requirement it
> couldn't get setting the UTC time of the atomic clock wrong (since
> LORAN TOC was timed vs UTC time scale, so a wrong time meant wrong
> timing signals to the LORAN transmitter), nor wait for a full GPS
> almanac to download.... We used a number of ad-hoc methods to do this
> since there was nothing standard and in practice they proved to be
> less robust than one would have liked. These machines were networked,
> but on a private network that existed at each LORAN station only with
> only minimal connectivity to the outside world (if any).
>
> Leap seconds sound easy and simple, but the logistical issues
> surrounding them are legend, especially when one must engineer for
> discontinuous use cases.
>
> Leap seconds are trivial if you have perfect knowledge. Sadly, history
> has shown that this knowledge to be somewhat less than perfect...

It's not only that, but also depends on over what system they are
conveyed over. Some work better than others. Some show for sure that
they where not designed with leap-second handling up-front, and the
patch work create various pains. As we look forward for NTP for
instance, we should make sure that the leap-second difference and
related mechanisms goes in with it up front.

As I've done work recently in a related effort, I've found that while
operating system may have needed capabilities, knowledge of what comes
in the box as well as configure it up properly to build a capable system
remains the challenge. What we can learn is to make sure that we remove
as much as possible of detailed configurations to make it work properly,
but make it the default behavior needing minimal configuration that
works. As you step the major version, you are allowed to break some old
behaviors in order to establish new default behavior.

Once TAI, UTC, GPS, PTP or NTP time is known alongside the leap-second
info, producing the other time-scales is fairly simple and
straight-forward, including leap-second steps. What keeps confusing
people is that UNIX and Linux time-scales jump differently.

The only IRIG-B version I've seen that do leap-second handling fairly
well is that of the IEEE C37.118.1 variant. Several of the IRIG variants
is not even close to do leap-second handling very well. The power-grid
folks is very aware of it and testing has been done to improve the
situation. That remains the key point, sufficient support and testing.

Cheers,
Magnus