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

[Magnus Danielson <[e-mail]>]

Warner,

On 2020-12-09 20:49, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020 at 8:11 AM Magnus Danielson <[e-mail]
> <mailto:[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.
Agree. We implemented (really used enabled it's use) autokey only to get
the leapsecond difference.
> Leap seconds are always some bastard stepchild in the timing community.

Disagree. There is several designs that handles it really well, that
have taken it really serious and you just said their work was bad, as
they are too in the timing community. It wasn't bad work, it was wrong
identification of the 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.

Please note that the leap second file is a NTP centric term, defined to
meet NTP specific needs as NTP was designed before. We may need to
unlearn that when we speak about time in general. The list of historic
IERS leap-second decisions is distinct from the leap second file.

What is true is that we need to know the current TAI-UTC difference, and
when a decision for an upcoming change comes, we also needs to
distribute this knowledge in advance to the event occurring, and then
when that is going to occur and the new TAI-UTC difference from that point.

If we can provide a historic list, that's fine. I prefer to identify TAI
time (directly or indirectly as suitable) at which a leap-second occurs
and the new TAI-UTC time at that point. Turns out to make interpretation
cleaner, much cleaner. This works well in GPS for instance, and even GPS
added it as an after-thought to the original signal structure.

> 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.
Yes, and it will make NTP harder and harder to use for many applications.
>
> 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...

Agree.

We can actually allow for a more flexible view, but tolerating the range
will become somewhat of a challenge.

We can have:

0) Djungle-clock, frequency, phase, time and full TAI-UTC difference
unknown/uninitiated.

1) Proper SI-second frequency, but phase, time and full TAI-UTC
difference unknown/uninitiated.

2) Proper SI-second frequency and phase (with some bound of phase
errors, which may be unknown but reasonably stable), but time and full
TAI-UTC difference unknown/uninitiated.

3) Proper SI-second frequency, phase and time-scale time, but unknown
TAI-UTC difference.

4) Proper SI-second frequency, phase, time-scale time and TAI-UTC
difference.

For each step, we gain additional knowledge and corrections. Notice that
I have avoided telling exactly which time-scale is being used, as that
ends up being less relevant for the overall scenario, while the
technical details of course matters grately, but you end up loosing
track of the bigger picture.

Notice that none of these provide any real accuracy and uncertainties in
the actual product, any form of meterology traceability aspects can not
be assumed by this, as I intentionally left out all those calibration
and traceability issues, they come as a separate discussion.

As you "fall back" one step, some specific thing drops out. However,
even stage 1 can be useful as it will provide the right frequency for
hold-over even if phase, time and TAI-UTC offset can not be updated.
Allowing for a source to step among these and do the best with the
situation will for sure provide the best approach for robustness. We
could even make independent decisions about our trust level for each of
the information given.

So, what we for the moment haggle about is really if we can assume NTP
to be a stage 3 or stage 4 type of service as default. I am advocating
that we shall make sure that the default behavior of future NTP devices
aim to achieve stage 4 level with minimum of configuration for
intermediary and client nodes. We end up needing that TAI and UTC sense
for so much these days. I also think it should not be too hard to design
things to achieve that, and there is plenty of good examples to
illustrate that, so lets learn from that and incorporate as we go forward.

Historically there have been gazillions of small little reasons making
the road unnecessarily rocky, and many of these technical reasons really
come from not having the ambition to make the design should achieve
stage 4. Rather than dwelling too much in the history, we should focus
on what we want to achieve in the future, and see what needs we see in
diverse set of applications. Just from my day-job I can tell you that I
seeing more and more need for stage 4 level of support and I feel sad
that trying to do it with NTPv4 make so many cuts and bruces. For other
mechanisms that is much less so an issue and I've designed my own system
for our products and not found it too hard to do proper in those
designs, if you only choose to have the mindset, which is maybe we this
ends up being the problem.

Cheers,
Magnus