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

[[e-mail]]

I feel like we might have had this exact discussion before?

The issue is not about users or devices needing or not having access to TAI.

The issue is that the execution of leap seconds is a nightmare where digital equipment with wildly varying implementations (or, none) of that execution is concerned.

It would solve quite a few issues if neither NTP clients nor servers had to deal with that execution.

Kristof

P.S.: Also, the measurable benefit of leap seconds is that your timescale can agree with solar time of one random town in Britain to one second (plus/minus timezone stuff).

This is way past its usefulness now that satellite navigation has replaced solar navigation, and so is (IMO) us clinging to dealing with leap seconds on such a large scale.

-----"ntp" <[e-mail]> schrieb: -----

An: "Hal Murray" <[e-mail]>, "Miroslav Lichvar" <[e-mail]>
Von: "Danny Mayer"
Gesendet von: "ntp"
Datum: 21.10.2021 17:19
Kopie: "[e-mail]" <[e-mail]>
Betreff: Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

On 10/21/21 5:20 AM, Hal Murray wrote:
>
>> 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?

You need different server for that on a different port. It won't happen.
You may as well use roughtime in that case.


>
>> 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 only way this is going to work operationally is to use UTC. Sending
the TAI difference in the packet is sufficient if anyone actually needs TAI.
>
> ------
>
> 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.
Servers have a fixed IP address and don't use DHCP. Clients like your
laptop don't care about TAI, they only want UTC.
> How many other things could use tweaking?
>
How many other things would you have to change in order to make TAI the
default.

Danny

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp