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

[Warner Losh <[e-mail]>]

On Wed, Dec 9, 2020 at 8:11 AM Magnus Danielson <[e-mail]> wrote:

> Miroslav,
>
> On 2020-12-09 15:22, Miroslav Lichvar wrote:
> > On Wed, Dec 09, 2020 at 02:07:28PM +0000, FUSTE Emmanuel wrote:
> >> Le 09/12/2020 à 14:46, Miroslav Lichvar a écrit :
> >>> NTP could distribute a leap-second table (it already did it with
> >>> Autokey, right?), but isn't NTP about distributing current time,
> >>> rather than reconstructing time in the past or future?
> >>>
> >> "Current" is a referential problem. As soon as you distribute/tackle
> >> different time scale which one is "current" ?
> >> You will more or less  inevitably start to need to reconstruct time in
> >> the past or future.
> > In all timescales there should be a value corresponding to current
> > time. It may be ambiguous.
> >
> > For the purposes of clock synchronization I think the client just
> > needs to know the current time and whether there will be a leap second
> > in the next slot if the timescale jumps on the leap second. If NTP
> > should also allow the client to know current time in another
> > timescale, it also needs to know the current offset (e.g. relative to
> > the receive timestamp) between those two timescales. The NTPv5 draft
> > does that.
> >
> > Most computers work primarily in UTC. The leap second tables are not
> > universally available. NTP needs to keep the UTC support and work even
> > when the TAI-UTC offset is unknown.
> >
> While I in general agree with you, a few words.
>
> First of all, we never get the "real" UTC, but only a local replica
> attempting to follow and respect some other time-scale, may it be UTC or
> TAI or whatever. Depending on how well we do the job in the chain from
> the source to the client, this replica may be more or less well aligned
> to the time-scale it attempts to replicate.
>
> It turns out that we have an increasing need to create TAI or PTP local
> replicas in addition to UTC replicas, and yes this is implied even with
> NTP as timing protocol. In the media industry we move all of our
> processing over to that, while we do more and more on "normal" clients.
> In fact, many other processing things occurs on essentially Linux
> platform for a whole range of processing needs. So, the need to know the
> TAI-UTC leap-second offset in addition to current time is needed.
>
> In my mind, the train to discuss the need for leap-second information
> has already gone. Too many applications start to need it for them to
> function well, and if NTPv5 is not able to deliver that, then it should
> either be redesigned to just dropped as an effort and focus on a
> revision of NTP that does support it, because what is needed is a
> solution that supports this. In the meanwhile, PTP has the needed
> support and we could just drop NTP and go all PTP then. Personally I
> think there is great value in NTP for many applications, if only it can
> handle this properly along getting secure with NTS.
>

One of the biggest issues I had with getting leap seconds to work right is
distribution. NTP v4 punting leapseconds to some crazy autokey ghetto
didn't help. Leap seconds are always some bastard stepchild in the timing
community. Yet they are also critical for UTC to be implemented correctly.
You can't purport to be a UTC time scale w/o distributing at least some
portion of the leap second table. If NTP can't make leap seconds first
class citizens that are mandatory for all implementations to  implement,
then they will continue to be bastard step children.

Most reference clocks will provide this information at stratum 1. Some will
not and we should shift the burden of those clocks to require
administrative support. They are rare and the main protocol shouldn't be
designed to cater to recovery of phase and frequency without meaningful
recovery of the meta-data that UTC needs to be implemented correctly...

Warner