Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

[Miroslav Lichvar <[e-mail]>]

On Tue, Jan 05, 2021 at 04:51:13PM +0100, Magnus Danielson wrote:
> Actually, here lies a problem. There seems to be fairly wide agreement
> that we want the core time-stamping to use a TAI-like form of time. This
> means, it keeps ticking, behaves like a well-functioned linear ramp.
> That makes any processing of it easy and so does all encoding.

Yeah, I don't agree with this idea. It will create more problems than
solve. I'd like NTP to be versatile and support multiple timescales,
as PTP does for instance.

> So, when forces say they really, really want to get rid of these
> encoding issues in the core transport of time-stamps, it's a real thing.
> It will be completely incompatible with UTC transport without means to
> handle things.

You cannot get rid of these issues until operating systems fully
support a non-leaping timescale and the TAI-UTC offset is always
known. I don't expect that happen anytime soon. You can specify a
nice protocol that supports only a non-leaping representation of time,
but it will just make implementations more complicated and less
reliable on those systems if the protocol actually gets implemented.

> Now, if the source side is unable to derive the TAI-UTC difference from
> it's timing source (say a simple GPS-receiver), when to resolve this,
> some other means of resolvement needs to be done at the server. You
> could use a leap-second.list file. You could use DNS based methods. You
> could listen to other trusted NTP servers only to attain the TAI-UTC
> difference and then re-distribute that. Regardless of which, when
> achieved you can provide the full service for all clients.

That's not always practical. If you start to rely on humans doing
something once every few years, you can be sure it will be broken. We
have few CDMA-based NTP servers in our network. They need to be
manually programmed for each leap second. You can guess how many times
I have seen that done correctly. Not once. It's fixed only when people
notice their clocks are off by one second. Before another leap second
occurs, it's all forgotten.

> If we say that we indeed can have different time-scales, then each user
> then needs to be able to handle the situation of conflicting time-scales
> from different servers, either separate or at the same time. I end
> thinking madness lies within.

I don't expect it to be a problem, at least not a bigger problem than
trying to convert everything to a common timescale. In the case when
the server cannot provide the service in the requested timescale and
the client cannot convert the timestamps locally, how could it
work if the protocol allowed only one timescale?

> I lean towards pushing the conversion requirement onto the NTP source
> nodes just to achieve the intended cleanness of the rest of the
> infrastructure.

It makes sense to require servers to convert the timestamps if they
have the offset, but for some hardware implementations (one-step
clocks) that might not be possible.

-- 
Miroslav Lichvar