Re: [Ntp] Leap smearing

[Magnus Danielson <[e-mail]>]

Doug,

On 2020-12-10 01:24, Doug Arnold wrote:
>
> For those organizations who want to leap smears, ntpv5 could support
> them with a leap smear extension that can be applied by clients. 
> Smeared time = UTC + leap smear offset.
>
>  
>
> After an added leap second the leap smear offset = -1, and gradually
> changes to 0 over the smear interval.  The leap smear function could
> be a cosine function, to match the frequency at the start and end of
> the leap smear interval.
>
>  
>
> Smear offset = -cosine(pi t/T) -0.5, where t time since leap second
> event, and T is the leap period.
>
That or a Gaussian shape transient, which will be a smooth fade-over as
integrated to the step function. Same philosophy.
>
>  
>
> Note it would always be possible to determine the unsmeared UTC if
> needed in this approach.
>
Yes, I think this should be done on the client side.

If you look at how SMPTE 2059-1 and 2059-2 work, the 2059-1 provides a
standard set of algorithms to provide all the classical timing
relationships. Some of these need specific parameters, and those is
distributed within the facility along with the time, as specified in the
2059-2. It covers a whole range of ugliness, some which makes
leap-second handling look like every-day evens. In fact, leap-second
handling is part of the set of things these have to handle.

The benefit is that you have a common core time distribution, and then
let the adaptation of that core time be done at the client side, as
needed by this or that application. Doing it like this, the core time
does not get hi-jacked by the needs of a particular application, at
least to a very little degree. Also, this approach is not even new, it's
already build and designed for by multiple vendors and deployment roll
out, so it's more about doing it adapted to the various needs that we see.

So, I agree very highly with that approach and was about to point out
that this is the way I see the future for NTP rather than having an ever
diversifying set of sources.

My preference would be to have core-time being TAI-based. Mandatory
TAI-UTC difference with relevant mechanisms. Then by providing
additional parameters can a diverse set of time-scales be mapped from
that, for instance UT1 can be produced by adding a source of UT1-UTC
differences and smooth that out, which is essentially how Judah Levine
created the NIST UT1 NTP server (he just stepped the predicted table
from the IERS).

The extra data-sources does not even have to be provided by the clock
source(s) selected. Being able to supply it that way will however be
useful. Being able to source them to clients and sources from other
sources will also be useful. As long as the core time provides the basic
support, the additional data can be more orthogonal in it's distribution.

Cheers,
Magnus