Re: [Ntp] NTPv5 draft

[Warner Losh <[e-mail]>]

On Tue, Dec 8, 2020 at 4:43 PM Magnus Danielson <[e-mail]> wrote:

> Warner,
> On 2020-12-08 21:11, Warner Losh wrote:
>
> Magnus,
>
> On Tue, Dec 8, 2020 at 8:53 AM Magnus Danielson <[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.
>
I'd love that. Too few things care to get leap seconds right, leading to
the balkanization of efforts and generally a dog's breakfast of what works
and what doesn't. Bravo!

> 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.
>

Yea, you need both. It's thinking you can get by with only one if you can't
quickly lay hands on the other. It's the last bit I ran into trouble with,
even though the systems I worked on were redundant, sharing that
information in a pinch was a pain. Whose copy was right, what to do when
they disagreed etc got off into the weeds quickly...

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.
>
Yes. I've only ever seen it in an ancient product at Timing Solutions that
seemed to either be a one-off or a checklist item since it never seemed to
work and even if it did long term clients didn't get enough warning because
the lead time was < 1000 seconds...

 Warner