Re: Predictable Internet Time

Stewart Bryant <> Tue, 03 January 2017 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7FD1129A5B for <>; Tue, 3 Jan 2017 09:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 EExSb0HpP4gT for <>; Tue, 3 Jan 2017 09:27:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54FE7129A4B for <>; Tue, 3 Jan 2017 09:27:26 -0800 (PST)
Received: by with SMTP id k184so239803477wme.1 for <>; Tue, 03 Jan 2017 09:27:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ajzJ7z8c8Tizb5Gdq6sDSlHNvWeNEd6EXYpuyZul46U=; b=YuGsClVvZVptfnWwMD6Uxg5TO8sxLPKjaK7NgPHGyr0DPayQZUiiQQwFn4N8EV5FQs JsYL1DjzsOOQSk85d3ngog0SYV/YfiaqzeJKFCQm2+1eFpAyfLSxWTweJm4dR4BE16ws Pp4BwyN1lNGSi3J9QyFJUMn5NRs+OAT3VhdD7H+qH6kGtY2T5K0OLEGuoCVmo6CYGhrU rePT42mFrcM/YtYm2VypAlnJs/APpndI7YSfUUnjiCJ3MP/D4VStmuNi1t/R0WVg66RL r2ilOA1JUcvyIhOg2csRsssE05NLYMiPpXdLU/WS9D9i8eiJtJzFMoDz6ww30Sq7tWKK NTWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ajzJ7z8c8Tizb5Gdq6sDSlHNvWeNEd6EXYpuyZul46U=; b=XDNrrfaXe+dZLuBC/mQnyMaDI5Wn1aowv+1N/J1C2n74gf+F3g9i7oTzwswyRkZxwq 6VIrZBbL26Audb+e4m3sPGsxa7UmSVwkHh43lJMbDDTp/ZpflGode2MQBNaB92p1znO1 anqCXze29r/RgL+eb7ZQlmyhlKFD2UsLyoE1tfNH0DSfBzB/5rYC91PmWnPnDVFAjdN/ 5vyTKmXX7gKzorhj7MKhvKjW4ZyKDfwJLThkDUSlT/57ZLE8sHqXHmuW3QITgT3A3k7t U3KwA344TfYWmp84nSdjnYrhf+L65wxVFjxOHljXGseiRtEdtRtDu3zGyWvMK3qC7es3 5jJA==
X-Gm-Message-State: AIkVDXJQgTFXyi+PVfL9TPHUMNpANOjETL7JRr/ZGc5zuKG+djJ9Z3bLV69AuqLw5HPiZg==
X-Received: by with SMTP id i82mr52947589wmh.6.1483464444560; Tue, 03 Jan 2017 09:27:24 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id cj1sm23315228wjd.46.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 09:27:23 -0800 (PST)
Subject: Re: Predictable Internet Time
References: <> <> <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Tue, 03 Jan 2017 17:27:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 17:27:28 -0000

Smearing worries me.

If you have an application where tiny fractions of a second make no 
difference, then
a slow smear is a good approximation to no leap second.

However, there are some highly accurate implementations of NTP, and some 
sensitive applications that use it, and having a long term interval 
error, which is what
happens during a smear, is harmful to those applications.

It seems to me that it might be better to freeze NTP on the current leap 
offset. Provide the current leap second offset to the application as a 
and let the application deal with it as it chooses.

- Stewart

On 03/01/2017 14:08, Tony Finch wrote:
> Joe Touch <> wrote:
>> Smearing leads to differing interpretations of elapsed time for two reasons:
>> 1) smearing isn't unambiguously specified
>> 2) smearing doesn't match the clock standards set by the ITU (who
>> defines UTC)
> Since leap smear is becoming more popular, it would be sensible to try to
> get a consensus on the best way to do it if you do it. Clearly
> organizations that do leap smear think (2) leap seconds are too much
> trouble so it's better to diverge from official time in a controlled
> manner.
> To clear up (1) there are a few technical choices on which people seem to
> be working towards some kind of agreement...
> * If you centre the smear period over the leap second, your maximum error
>    from UTC is 0.5s, which seems to be preferable to starting or ending the
>    smear period on the leap second
> * Linear smear works better than sigmoid smear, since it minimizes the
>    rate divergence for a given smear period, and NTP's algorithms react
>    better
> * Longer smear periods are better, because they give NTP more time to
>    react to the rate change, and they minimize the rate difference
> It looks to me like a 24h leap smear from 12:00 UTC before the leap to
> 12:00 UTC after the leap has a good chance of becoming more popular than
> other leap smear models.
> Tony.