Subject: Re: [Ntp] Smearing

From: Danny Mayer <[email-masked]>
Date: Tue, 19 Oct 2021 11:57:41 -0400

On 10/19/21 11:47 AM, Tony Finch wrote:
> Hal Murray <[email-masked]> wrote:
>> I think the protocol should use TAI and make available the leap info.
>>
>> That means an NTP client will need to know if it should smear.
>>
>> Plan A is to put that info in a flag in /etc/smear or such so that other
>> programs can also use it, perhaps to unsmear or perhaps just to print a
>> warning message when log files do/don't smear.
>>
>> Plan B would be to put that info into the kernel.  There are spare slots in
>> struct timex and struct ntptimeval.  Then a flag in ntp.conf could tell ntpd
>> to smear and it could pass that to the kernel.
> Both plans don't answer the question of how the client gets the correct
> configuration. Smearing is (typically) a feature of a data centre
> environment and each client implicitly gets a time that matches its
> neighbours by using the local NTP servers.
>
> When there's a mixture of NTP4 and NTP5 clients, how can you be sure that
> they get the same time? I think an NTP5 server should have some way to
> say, "if you were talking NTP4 to me I would give you a smeared time", so
> that an NTP5 client can match its neighbours.
>
>> --------
>>
>> The next leap info is big enough that I don't want it in the basic
>> packet format.
> It doesn't need to be more than 4 bytes.
>
> According to TF.460 (the definition of UTC) leap seconds can only happen
> at the end of a month, so the leap indicator only needs to count months.
>
> Leap seconds will no longer work when the earth is turning slowly enough
> that we need one at the end of every month; we expect that to happen
> before the year 4200, at which point DTAI will be about 4 hours.
>
> https://www.ucolick.org/~sla/leapsecs/dutc.html
>
> If you allow 15 bits for the count of months since 1972, that lasts until
> after the year 4700. 14 bits for DTAI is over 4.5 hours; it might be
> wise to add a sign bit in case things get really weird.
>
> That leaves 2 bits spare which is just enough for the leap direction.
> (Though it would be handy to have another bit to indicate smearing.)
>
> Tony.

I agree. My proposal includes a month count and a leapsecond count. A 
zero for both month count and leapsecond count indicates that the values 
are unknown. It also indicates if there is a leapsmear in progress, the 
type of smearing done (there are a number of different ones) by 
including a smearing ID. The client can then choose whether or not to 
follow that smearing type.

Danny