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

[Martin Burnicki <[e-mail]>]

Hal Murray wrote:
> 
> [e-mail] said:
>> NTP is used for synchronization of various clocks. Most of them are based on
>> UTC. NTPv5 cannot support only TAI. 

I fully and strongly agree with Miroslav.

NTP isn't only used on Linux, which supports TAI time, and FreeBSD,
which doesn't support TAI right now but can easily be extended to
support it in the near future (if I have understood some earlier
messages correctly).

Instead, there are more operating systems like other Unix-like systems,
Windows, VxWorks, QNX, and last but not least embedded systems and IoT
devices which are not even mentioned here. In many cases at least the
latter won't even run a full-featured NTP daemon but some simple NTP
client software just to keep their system time basically synchronized so
that their logs etc. are based on a fairly accurate time, which is
UTC/POSIX or a local time derived from that.

In the past, moving from NTPv3 to NTPv4 was easy and could be done
seamlessly due to the (IMO very good) evolution of the protocol, e.g.
that the format of the base packet was unchanged and new features were
implemented using extension fields.

When the NTP daemon (at least the original implementation from ntp.org)
received a request from a v3 client, it just had to change the set the
version field in the response packet to v3 instead of v4 to keep v3
clients happy.

>From the point of view as a manufacturer of time server appliances this
is much easier to maintain than the mess we had with PTP, where v2
packets had a totally different layout than the original v1 packets. The
only thing that limited the impact of that change was that PTPv2
appeared soon after v1, and v1 wasn't much widespread at that time.

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.

Yes, I know that it *may be* possible to design the protocol new, from
scratch, without any compatibility with v4, but IMO this would just
keeping lots of folks from using it for a long time, so the question is
if this was really a better approach than taking care of compatibility.

> This is a tangled area.
> 
> I think that a TAI only NTPv5 protocol would be much cleaner and easier to 
> document.  Yes, I agree that we need a story for UTC, but the answer doesn't 
> have to clutter up an RFC for NTPv5.

Yes, of course. If you only care how easy it is to document it, you
could simply say that NTP provides TAI time stamps, and that's it. This
would leave all the problems of the details how to convert that to UTC
and/or local time to the implementers of the system timekeeping.

In my opinion it would make much more sense to keep the NTP base packet
compatible with v4 and maybe make some extension fields mandatory for
v5, for example some correction information that let the client derive
TAI from the timestamps, if required or supported.

IMO this would strongly increase the acceptance of a v5 protocol because
existing clients still can use the same server as new, full-featured v5
clients, which can derive TAI if they want or need it.

> All the kernel and/or libc need to convert TAI to/from UTC is the TAI-UTC 
> offset (a small integer) and the date of the next leap second, a flag for 
> insert/delete/none, and the valid-until date of the info.

And there needs to be an API call that returns the current TAI or
UTC/POSIX) time *plus* the associated UTC offset atomically, with an
execution time as short as possible.

If you have to call several API functions after each other, you know in
worst case the kernel could just step the time between the 2 calls, so
the result ing timestamp/offset pair would be inconsistent.

I know there is already the ntp_gettime() call available on some
systems, but if you have a huge number of clients, the execution time of
that function significantly reduces the performance of the NTP server.

> We could provide that data in an extension.  The same extension would allow a 
> NTPv4 server to provide clients with enough info to let current UTC based 
> kernels provide TAI and/or leap when appropriate.

Why not do it the other way round, and provide the time scale that is
required by default by the clients, and provide a way to derive TAI for
those who really need it?

Yo still have to keep in mind that if you use TAI, you need a reliable
source not only for leap second announcements but also for the current
TAI offset. The latter is not provided by all reference time sources,
e.g. DCF77 doesn't have it.

> We could provide code that lets systems process leap-seconds.list
> ntpd already does.

Yes, but "someone" has to provide the file, at some point.

> A copy of the leap seconds file is included by the Time Zone project and 
> distributed by IANA.  Most distros are already setup to keep the time zone 
> info up to date.  It should be simple for the leap file to go along for the 
> ride.  Debian already does it.

Except the versions that aren't updated anymore, or embedded of IoT
devices. This has been discussed many times before.

IMO it's a step back to force using TAI just because it can easier be
described because it just shifts the existing limitations to a different
location in the time synchronization chain.


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