Re: [Ntp] Consensus call: NTPv5 and leap second smearing

[Harlan Stenn <[e-mail]>]

On 7/10/2023 12:57 AM, Martin Burnicki wrote:
> Denis Reilly wrote:
>> Hello,
>>
>> Paul Gear wrote:
>>
>>> The reason smearing gets used under current NTP versions is because 
>>> the people using it have large-scale issues with timestamp-sensitive 
>>> software, and it's more efficient to implement the smearing on the  
>>> servers than on the clients, which can be orders of magnitude greater 
>> in terms of scale.  If we prevent this, we will only hinder the 
>> adoption of newer versions.
>>
>> I agree, but I think that hiding the smearing process in the timestamp 
>> is not optimal, because it prevents client interoperability between 
>> smearing and non-smearing servers. (We had to add a clause in the BCP 
>> about that.) I can see a use case where an organization that wants to 
>> implement server-side leap smearing in this fashion might still want 
>> to configure an independent non-smearing service somewhere in their 
>> hierarchy as a check on their timebase.
>>
>> Doug pointed out below that in the current draft the offset to UTC 
>> must be supplied when smeared time is distributed. If we have that, 
>> then what do we gain by sending the smeared time? I think we are 
>> better off sending UTC timestamps all the time, then using the 
>> smearing offset to modify the time as realized at the client. It would 
>> involve no additional config on the part of v5 clients, just some more 
>> math in the implementation. But it would enable this interoperability 
>> between smearing and non-smearing sources of time, because the UTC 
>> time from all servers is more easily accessible for comparisons.
>>
>> So I would support language that is a bit different than Paul's:
>>
>> - A server MUST send UTC timestamps.
> 
> Tell this also the NIST guys who operate servers that continuously send 
> UT1 instead of UTC. ;-)

Judah tells me that the NIST systems that offer UT1 time have a refid of 
NUT1, so there's no problem there.

H
--

> The intention is surely that all clients athat are configured to poll 
> these server have their system time run on UT1 rather than UTC.
> 
> We also have customers who expect that our LANTIME NTP servers send raw 
> GPS time instead of UTC because they have NTP clients that are expected 
> to have their system time be aligned to GPS time.
> 
>> - A server MUST provide indication (via an extension) of whether 
>> clients are meant to smear the leap second, and of the current 
>> UTC-to-smeared-time offset.
> 
> As said before, at least ntpd from ntp.org already provides an 
> indication that the "normal" timestamps contain smeared time, and can 
> use that (if required and desired) to compute UTC.
> 
> "Dumb" clients won't do that, and that's exactly the purpose of 
> server-side smearing.
> 
> It's similar to the IEEE (IRIG-like) time codes: the transmitted time 
> may be local time with an offset to UTC, but there's a data field 
> included that provides the current UTC/local time offset offset.
> 
> So dumb wall clocks that are not aware of the additional data field 
> simply display the transmitted local time, while more sophisticated time 
> code receivers can easily convert the transmitted time back to UTC, if 
> required.
> 
>> - A client that receives leap smearing information from a server and 
>> has no local leap smearing configuration MUST use the server’s 
>> configuration.
>>
>> - Clients MAY override the servers' leap smearing configuration with 
>> its own local configuration:
>>
>>    - to turn off leap smearing even if the server wants it to
>>
>>    - to apply its own leap smearing algorithm regardless of what the 
>> server is sending
>>
>> - Clients that are implementing leap smearing MUST NOT apply the leap 
>> second time jump, even if they are getting the LI bits from a 
>> non-smearing server.
>>
>> If we allow servers to send smeared timestamps in v5, as Paul 
>> proposes, then we will need to either codify all the current BCP 
>> restrictions prohibiting using smeared and non-smeared servers 
>> together (but only when sending smeared timestamps), or implementors 
>> need to take the time to specifically pull out the smeared offset 
>> before comparing these sources (but only when sending smeared 
>> timestamps). It seems simpler to me to just put all the timestamps in 
>> UTC, and the path forward then has a lot fewer conditionals.
> 
> There are simple NTP clients out there which just poll the time from a 
> server and set the local time. Do you really think such dumb clients 
> will implement anything of these proposals?
> 
>> There is an interesting side case: what happens if a client is 
>> listening to several smearing servers, each with a different 
>> algorithm? Maybe that’s purely academic if most people use the same 
>> algorithm. That seems difficult to resolve, but might be impossible if 
>> you are hiding the smearing adjustment in the timestamps, like we do 
>> now. (In fact, the current BCP says that if you are smearing, it's up 
>> to you to make sure all your servers are configured with the same 
>> algorithm, which we can surely improve upon in V5….)
> 
> That's a known problem, but I think the only way to keep this "clean" is 
> that an administrator carefully specifies the servers to be used.
> 
> Smearing is just a hack to avoid time steps at the client side, and I 
> bet that all the optional stuff mentioned above will even increase the 
> confusion about smearing instead of making things easier.
> 
> 
> Martin
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!