Re: [Ntp] Leap smearing

Magnus Danielson <> Thu, 10 December 2020 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88B863A09E0 for <>; Wed, 9 Dec 2020 17:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TW45QloTtC6n for <>; Wed, 9 Dec 2020 17:04:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACF8C3A07EA for <>; Wed, 9 Dec 2020 17:04:01 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 192193F741 for <>; Thu, 10 Dec 2020 02:03:35 +0100 (CET)
Authentication-Results:; dkim=pass (2048-bit key; unprotected) header.b=k6HcF3l4; dkim-atps=neutral
X-Virus-Scanned: Debian amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CcVh-JSZ2jne for <>; Thu, 10 Dec 2020 02:03:29 +0100 (CET)
Received: by (Postfix) with ESMTPA id 969893F6AC for <>; Thu, 10 Dec 2020 02:03:29 +0100 (CET)
Received: from machine.local (unknown []) by magda-gw (Postfix) with ESMTPSA id AEFA19A0520; Thu, 10 Dec 2020 02:03:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=rubidium; t=1607562233; bh=hwUKVfcDKoeJDSbTERifjkarURlvexy6u6OCs1rqIfw=; h=Cc:Subject:To:References:From:Date:In-Reply-To:From; b=k6HcF3l4Gk/sfSyw9VmOlZwPUxiOpuvGjEBRdH+WAdVV7i+HoksVZ3KCrpcS7/2NH O8tS5ap5o0cBNWkF4j8bLyrE5BtCmzjMr4P8m8vEV0IQQpMEM+8KEtj99Owu4ILQpL jMdczHwChb1Dyk3qTWvZtk9qbxNNcH2sTYz3rfPhZqhWuyAwbR6IiP06K2enQFzPvW FJIIkBX8yfq+eqNPT5EKCE8tOstUFLX2CrZEVC58SyGK7+pyDcM3yVJ25eeFSqrGVT b9ciqj7oZYe5fnNCmVABWad3A4aeuxpT/oq31T8vpGEAbC91Z58QdPr7BR5qBd6rD3 RhBdGHeEQCxLQ==
References: <>
From: Magnus Danielson <>
Message-ID: <>
Date: Thu, 10 Dec 2020 02:03:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------44E057BB498C955EE2F29BA8"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] Leap smearing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2020 01:04:13 -0000


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.