Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

[Martin Burnicki <[e-mail]>]

Hal Murray wrote:
> [e-mail] said:
>>> The time used in time-transfer should be TAI to keep things clean.
>>> No leap. No smear.
> 
>> I'm sure that would look great on paper, but how exactly do you implement it?
>> You cannot convert POSIX time_t to TAI just from the timestamp alone. When
>> you receive a timestamp from the kernel (e.g. in the SO_TIMESTAMP control
>> message), you don't know if it was captured before or after the leap.

Exactly.


> Good point.  What does the current code do?
> 
> I don't have a simple/clean answer.
> 
> A short term hack would be to drop all packets where a time stamp is ambigious.

How do you find out which timestamp is ambiguous, and which is not?

I think that if you want SO_TIMESTAMPING to return a TAI timestamp you 
have to introduce another mode which requests that.

> A long term solution would be for the kernel to keep time in TAI and the
> library to translate all the old APIs to UTC.
> 
> A medium term fix for SO_TIMESTAMP and friends would add the TAI-UTC offset to
> the time stamp or a leap-in-progress flag.  That's a few lines of code in the
> kernel.

This would mean that  each time a packet is timestamped, the 
timestamping code would have to grab the timestamp and check and collect 
the status in an atomic way.

I bet this is too expensive, with regard to the execution time.

The same problem has been discussed before about letting user space 
programs retrieve the current time plus status from the kernel, which 
would fix lots of leap second problems.

>> The other important issue is that the TAI-UTC offset is not always known.
> 
> Yes.  I think requiring the client to know the TAI offset is reasonable.  They
> can get it from a leap-seconds type file or from a simple UDP exchange.  It's
> the same as knowing about the next leap second.
> 
> We could put it in every packet, but that seems ugly to me.  It makes things
> slightly simpler for the simple/dumb client (1 packet vs 2) at the cost of
> complicating the packet on the wire.
> 
> Maybe we should have a separate packet format for simple clients.  How dumb
> are current dumb clients?  Would they be happy with only a single time stamp
> from the server?  Do they even care about fractions of a second?
> 
> 
>> NTP is a simple protocol for exchanging timestamps. It shouldn't enforce what
>> kind of timestamps are exchanged.
> 
> We either have to pick one and hence enforce that, or put the type of
> timestamp in the packet.  I think it's cleaner to have only one on the wire.
> 
> ------
> 
> The root of the problem is smearing.  The current implementation hides it from
> the client software.

This was exactly the intention when smearing was introduced. Hiding leap 
seconds from clients so that they all have the same time but don't even 
notice there's a leap second.

We've had customers that had to stick with certain, certified software 
versions on the client systems. They weren't even allowed to update the 
kernel which had a known leap second bug, and they wouldn't be able to 
install a cool new NTP client which can do the smearing locally.

Instead, letting the server provide smeared time fixed the problem.


Clients that can do the smearing themselves don't necessarily need 
smearing info from a server.

In fact this has already been done, e.g. following the Markus Kuhn's 
UTC-SLS proposal from 2005:
https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/

If I remember correctly this is at least supported in Pearl.

Similarly, you could let the kernel smear the time if it has received a 
leap second warning.


> Unless we change that, we have to continue with 2 NTP worlds: one set of
> servers that returns smeared time and another set that returns non-smeared
> time.

Yes. In any case you have to take care about the configuration:

If you have smearing servers, you have to configure clients so that they 
either use only servers that smear in the same way, or only servers that 
don't smear.

If you have smearing clients and non-smearing servers, you have to take 
care to configure each client whether and how it shall smear the time 
when a leap second is approaching.

> My suggestion of TAI only on the wire requires that the client implementation
> know about smearing.  The we-want-smearing information moves from hidden in
> the list of servers to an explicit flag in a config file (or whatever).

My preferred solution (in general) would still be to use UTC for the 
timestamps in the packets, and also provide a UTC/TAI offset so that 
systems that only need UTC can use that, and systems that need/want TAI 
can apply the offset to get TAI.


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