Re: [Ntp] Antw: Re: Antw: [EXT] Re: Timescales

[Magnus Danielson <[e-mail]>]

Warner,

On 2020-12-10 08:27, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020, 11:56 PM Ulrich Windl
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     >>> Magnus Danielson <[e-mail]
>     <mailto:[e-mail]>> schrieb am 09.12.2020 um 14:44 in
>     Nachricht <[e-mail]
>     <mailto:[e-mail]>>:
>     > Ulrich,
>     >
>     > On 2020-12-09 14:29, Ulrich Windl wrote:
>     >>
>     >>> Relying on a separate source like the leap‑seconds file is not
>     always
>     >>> possible. The device may not have an up‑to‑date OS, or
>     actually have
>     >>> any writable memory to store that information.
>     >>>
>     >>> There is definitely not a plenty of warning. Some reference clocks
>     >>> give the leap announcement only an hour before it happens (e.g.
>     >>> DCF77). Even delaying setting of the kernel leap status to the
>     clock
>     >>> update can be a problem if you are polling at 1024 seconds and
>     have
>     >>> more than two measurements dropped in a row in the clock filter.
>     >> However you could see the leap indication flag also as "leap
>     confirmation"
>     >> flag (actually there will be a leap event). With only DCF-77
>     clocks this
>     > could
>     >> be a problem. As said earlier, it would be best if NTP could
>     reliably
>     > transfer
>     >> the leapsecond table, or at least the relevant part of it to
>     make clients
>     > know
>     >> in advance that and when a leap event is scheduled.
>     >
>     > A mechanism that works well conveys the current value, when an
>     upcoming
>     > event is occurring and which direction it will be. That solves
>     most of
>     > the practical problems. For back-dating purposes, which is more
>     of an
>     > obscure corner-case, being able to also provide older parts of the
>     > leap-second history is nice, but rarely very useful.
>     >
>     > A less useful but still helpful mechanism is when there is a
>     pre-warning
>     > mechanism of upcoming event and indication when the event
>     occurs. For
>     > this to fully function the current value needs to be supplied
>     from the
>     > side, but from then the updates can be done correct if the node is
>     > operational during the pre-warning interval. The strength in
>     providing
>     > the current value directly is that you instantly can be "on the
>     right
>     > page, eh second" and the strength of the pre-warning system is
>     that you
>     > in advance can know of the leap second. In GPS for instance, you
>     have in
>     > practice over 5 months of pre-warning, and you get an indication
>     of when
>     > the event will occur so you can even be non-operational during
>     the event
>     > and as you wake up instantly provide the correct value even if the
>     > current value update can be slugish (12.5 min cycle for
>     transmission).
>     >
>     > So, a good and simple mechanism is to give the current TAI-UTC
>     offset,
>     > then have a flag indicating up-coming leap-second event, give the
>     > system-timestamp for when this event occurs and the TAI-UTC
>     offset as
>     > result of that leap-second insertion.
>     >
>     > Piggybacking a historic leapsecond file transfer will always be
>     a nice
>     > feature, but not strictly required if this is in place.
>
>     Hi!
>
>     That's why I wrote "or at least the relevant part of it", meaning
>     whether
>     there will be a leap event withing the next six months or not.
>     That's deinitely
>     not a lot of data. The only reason to send the full table would be
>     having to
>     avoid parsing the table before sending.
>
>
> Technically, a leap second can happen at the end of any month. It
> would be foolish to bake the 6 month thing in. Even so, the entire
> leap second table can be encoded in less than 100 bits today. Less if
> you get a bit clever with compression.
>
> I do agree that you can compress the relevant bit to 1 in the steady
> state once you know. But for discontinuous operation you need more to
> fully implement UTC, including correct reckoning of elapsed time
> between two events. Declaring these sorts of problems as outside the
> scope is why I make comments like bastard step child. Or put another
> way: if they were properly implemented, we'd have no need for smearing...
>
To extend your discussion with an example when it fails:

In the HP Z3801A GPSDO clock, the Motorola GPS OEM module flips a flag
to indicate that there is an upcoming leap-second. You can read out of
the OEM module when the leap-second occurs. However, the firmware choose
to interpret this to be in the last month of the UTC quarter, which is
secondary choice position in the ITU-R specification of time
transmissions. Now, as IERS chooses to only use the primary choice
position, that is end of june and end of december, and IERS publish
their decision just a few days after half-year, and the fact that the US
Air Force operation of the GPS constellation chooses to insert the
upcoming leap second typically within a few weeks of the IERS
annuncement, this means that the indication flag for leap second occurs
in two quarters, so the Z3801A will insert it in the wrong quarter. This
despite the availability of the correct time-stamp, which is a pure
software bug.

This is a great example how you should not interpret the flag value to
have implied time-meaning. You have two sets of specification, two
controlling organizations, two different vendors of equipment integrated
together. There is good chance things gets done the wrong way.

> Exchanging the metadata about UTC (or whatever timescale) is needed to
> completely implement it. Time exchange needs to be thought of as more
> than just a phase delta measurement.

Agreed. We learned this from bitter experience. We have seen severe
problems and we had to completely decommission equipment from operations
because of it.

Just do a very strict and clear design. It still cost a few bits, but it
ends up producing more transparent and robust mechanisms, that can be
adapted to the changing situation.

Cheers,
Magnus