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

On Wed, Dec 9, 2020, 11:56 PM Ulrich Windl <
Ulrich.Windl@rz.uni-regensburg.de> wrote:

> >>> Magnus Danielson <magnus@rubidium.se> schrieb am 09.12.2020 um 14:44
> in
> Nachricht <9ad5edd1-8794-6b55-ff9d-187fc77481a2@rubidium.se>:
> > 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...

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.

Warner

Regards,
> Ulrich
>
> >
> > Cheers,
> > Magnus
> >
> > _______________________________________________
> > ntp mailing list
> > ntp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ntp
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>