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

[Magnus Danielson <[e-mail]>]

Miroslav,

On 2021-01-05 17:29, Miroslav Lichvar wrote:
> 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.

I'm not at all convinced. PTP has little, at least as I can see in
IEEE1588-2008, that really supports the UTC with time-stamps. I should
check IEEE1588-2019 for more details, but you will have to explain very
clearly how that support comes about in PTP, because as I see it, if you
run UTC only it's hand-wavey at best. If you can show clearly how PTP
handles UTC and especially as a leap-second occur without hickup.

>
>> 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.
Well, I think it can be done.
>
>> 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.

Yeah, so I did suggest several ways to remedy that.

As a secondary note, do take a look at the expected lifetime of the CDMA
service, as that may be phased out as 5G roll-outs starts to come
closer. A lot of them have already closed.

>
>> 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 never said it could not be done, I said it would be complex and
troublesome. Avoiding comlexity seems to be one of the driving forces
behind NTPv5. If so, one will have to choose what things remains and
what one trade out. I am very sure that people is not fully coherent on
that and what it endtails, therefore one needs to ask the hard questions
so people learn what challenges lies ahead. If we are not agreeing on
basic properties, the discussions further down the line will not be very
fruitful.
>
>> 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.
>
What one-step clocks would that be? Surely, I expect none of the
existing NTP clocks to automatically support NTPv5, almost regardless
which shape it will take.

Cheers,
Magnus