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

[Hal Murray <[e-mail]>]

[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.

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.

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.


> 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.

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.

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).

The NTP stuff for DHCP could get extended to include the smear flag.

How many other things could use tweaking?



-- 
These are my opinions.  I hate spam.