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

[Martin Burnicki <[e-mail]>]

FUSTE Emmanuel wrote:
> Le 06/01/2021 à 11:50, Martin Burnicki a écrit :
>> Philip Prindeville wrote:
>>>> On Jan 5, 2021, at 9:09 AM, Martin Burnicki<martin.burnicki=[e-mail]>  wrote:
>>>>
>>>> For NTP, things are different. There is a huge base of NTPv4
>>>> installations, and making NTPv5 basically compatible with v4 would IMO
>>>> strongly increase the acceptance of NTPv5.
> The "basically" mean nothing. Is is 100% compatible or not compatible. 

As I tried to explain in earlier messages, you can easily make it fully
compatible and support new features by extensions.

> It is NTPv4 or NTPv5.

In the first place it is NTP. If you think you need to completely
redesign it, just give it a different name.

> The "not so different" between v3 and v4 was much 
> a source of problems than an adoption catalyst.

I'm working with NTP for a very long time now, and I don't remember any
problem when moving from v3 to v4. Exactly the opposite was true: there
were no problems because the protocol was compatible to a very high
degree, so it was no problem to have a mixed v3/v4 environment an slowly
changeover to v4. And according to my job I've seen *many* different use
cases, both for the client and for the server side.

So which problems exactly do you mean?

> I even view it in the opposite for a psychological/marketing acceptance 
> point of view: being  v4 compatible is so restrictive for v5 that people 
> would prefer to stick to v4 as v5 would give nothing more than v4 
> (unless being an expert to understand the difference/gain).
> Do we want to do a NTPv4 revision or NTPv5 ?

IMO the protocol should evolve from v4 to v5 in a compatible way.

As I already mentioned before, I've seen real incompatibility problems
when PTPv2 was introduced because even the base packet was incompatible
with v1. Luckily this wasn't a too big problem because PTPv1 wasn't
widespread when v2 was introduced.

>>> The logical corollary to this argument is that because there ARE a lot of servers, it’s not unreasonable to think that there will be a lot of both NTPv4 and NTPv5 servers co-existing in the future, and the user is free to peer with either.
>> So you think it's not necessary to upgrade v4 nodes to v5, as it has
>> been done from v3 to v4? Simply systems should stick with v4 and only
>> enhanced system should start using v5?
>>
>> In this case, wouldn't it be better to start defining a completely new
>> protocol and e.g. call it "Extended Time Protocol", which can be chosen
>> instead of NTP? This would be similar to PTP, which you can use instead
>> of NTP. ;-)
>>
>>> Which eliminates the need for NTPv5 servers to also speak NTPv4.
>> If you have a large network with different types of client you will need
>> to provide NTPv4 and "ETP" (AKA NTPv5) if NTPv5 has requirements that
>> are not needed and can't be supported by some clients.
> But the "can't" is wrong as long as the offset is always transmitted and 
> for the "need" argument, the same clients would have stick to 
> time/daytime service if it is a real one.

Sorry, but you are competing apples to peaches. Do you really suggest
that NTPv4 clients fall back to time/daytime (which, by the way, are
also different protocols than NTP) ?

> A v5 server could still provide v4 frame and for v4 clients if needed 
> but without hw times-stamping support which it would reserve for v5 
> clients if it has some actives. But it is implementation and policy details.

I think whether hardware timestamping is supported or not isn't related
to the packet format. Even NTPv4 can use timestamping in the kernel
driver, if the OS supports it.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy