Subject: [Ntp] Leap smearing

From: Doug Arnold <[email-masked]>
Date: Thu, 10 Dec 2020 00:24:16 +0000

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.

Note it would always be possible to determine the unsmeared UTC if needed in this approach.

Doug

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 02:03:53 +0100

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

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 10 Dec 2020 15:32:55 +0100

> On 2020-12-10 01:24, Doug Arnold wrote:
[...]
> Yes, I think this should be done on the client side.

Again, IMO you have to distinguish.

If you have a "sophisticated" client for a specific application, you can
retrieve normal UTC from the server, with leap second warnings included,
and do the smearing locally at the client side.

As far as I know, some frameworks use UTC-SLS to do this, even if the
operating system time doesn't.

This should work fine for a specific application, but it would be
interesting to see what happens if programs that have been built with
UTC-SLS share timestamped data with programs that rely on the system
time provided by the native API calls of the operating system. ;-)

However, if you have "normal" clients and you just want to prevent your
applications from hickups when the system time is stepped back, it's
easier to let the server smear the time, because you only have to
configure this once, and all clients behave the same.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Hal Murray <[email-masked]>
Date: Thu, 10 Dec 2020 12:33:01 -0800

martin.burnicki=[email-masked] said:
> applications from hickups when the system time is stepped back, it's easier
> to let the server smear the time, because you only have to configure this
> once, and all clients behave the same. 

That seems appropriate when you have an existing installed base using an 
existing protocol.

But we are talking about a new protocol so there is no installed base.  It 
seems reasonable to me to move the smear decision to the client side.  But 
that forces the client to decide which means one more parameter for the admin 
to keep track of and possibly screw up.

If we decide to allow/encourage doing the smearing at the server, I think we 
should be sure to document that the reason is administrative convenience.  The 
client software should probably have a 3 way option: smeared, non-smeared, 
follow-servers.  The follow-servers option will have all the current problems 
if the selected servers don't agree.

-- 
These are my opinions.  I hate spam.

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 10 Dec 2020 13:21:22 -0800

Yo Hal!

On Thu, 10 Dec 2020 12:33:01 -0800
Hal Murray <[email-masked]> wrote:

> > However, if you have "normal" clients and you just want to prevent
> > your applications from hickups when the system time is stepped
> > back, it's easier to let the server smear the time, because you
> > only have to configure this once, and all clients behave the same.
> >  
> 
> That seems appropriate when you have an existing installed base using
> an existing protocol.
> 
> But we are talking about a new protocol so there is no installed
> base.  It seems reasonable to me to move the smear decision to the
> client side. 

+1

Removing it from the wire protocol make one less thing to get wrong on
the wire.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin