Re: Predictable Internet Time

Stewart Bryant <stewart.bryant@gmail.com> Tue, 03 January 2017 18:25 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4D129A95 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 10:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqv_556o5hgw for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 10:25:19 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93154129A73 for <ietf@ietf.org>; Tue, 3 Jan 2017 10:25:18 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id a197so391171231wmd.0 for <ietf@ietf.org>; Tue, 03 Jan 2017 10:25:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=iwe7GKvJpPa1eFyiwszRH7rjUJaTleNsCKfTcVL75R4=; b=BMpL6pNV/0jxr36wrbEvUBoiS1aLKdOfdPA1GuT1dk7RPNkR3c41DaIHeC2Mpvk7qF HNG6v1eQGNmSmOsHZnLa7D54jIftg3UroQh/ZC/b1DMg66BiY4IwkcQs/EtAvJaIgG2C /30R6bz/50/z0F7j3E+jI4sJD16wAtL2Rdbpd89W/4jh0AAyusIn5BWoOZHcdgc0HZmK +dHBpvmL1QryyeAVF5r6k9AKK3MUhXp7KNVDaY+r7Dkrjz8V2XPgNcOoISWln+MoKmqf QZEtbqFfJQcyqY40rQVsqO2hkYCkM9DnLHc5Jxjpqk2BVv30Vpgwl0/13EW7Vo0LKmYO SGyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=iwe7GKvJpPa1eFyiwszRH7rjUJaTleNsCKfTcVL75R4=; b=bSTjkLe6zzTu04iAN6Fg2209ZZtLYEnxVdFipj/rdBRuSrUJUFI3/IEwk03OOIIZEJ WmEES4uNSfqxGjWVEU1EjZFDskzbu6KUAHdIaMURm4TJtCyxMsrO3Kk5bizrzJjBgFhE 2aWyhjS/vh/mkUlmIa7MiiIs/xB2zkzuao6rgw78NQ/qKxfnR5vsomxvMbvS+CbRSw+o G+HlxTdjauQ/QFVVv0otB7NEsPQJuUeY9zkZH6hh91P7c4qXkfrQVy26eq1n9c/m8C+9 qtUL1Nj1JQANVbKzVEo/bCorGaYAw6sFZnaQ58ZmBKkqVdaNi/NhSLVjiWd0thF/GgYT NnvA==
X-Gm-Message-State: AIkVDXK+SZsWhzr06qxTLDBVfjU9Dxv512hhBh5vAiaZYD220tndzmvuwDvf//Zh4ZZFQw==
X-Received: by 10.28.103.3 with SMTP id b3mr50101073wmc.24.1483467916846; Tue, 03 Jan 2017 10:25:16 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id bf2sm93835403wjc.48.2017.01.03.10.25.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 10:25:16 -0800 (PST)
Subject: Re: Predictable Internet Time
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com> <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu> <alpine.DEB.2.11.1701031348430.7102@grey.csi.cam.ac.uk> <0bbfcd7c-11a7-0e7f-56f7-eee959b7a947@gmail.com> <CAMm+Lwi0sQyRE_2dMCkwTk7xTiK2JbHhHSPYMkdG2FeBw_6CNA@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <2eddd920-4b22-c071-ae09-7963db47dcd7@gmail.com>
Date: Tue, 3 Jan 2017 18:25:13 +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: <CAMm+Lwi0sQyRE_2dMCkwTk7xTiK2JbHhHSPYMkdG2FeBw_6CNA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------442130DF20CC016AB8C6D9BA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EmXoEN07q-xEGNSdlY4vQXO9Ydw>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 18:25:22 -0000


On 03/01/2017 17:42, Phillip Hallam-Baker wrote:
> Agree 100%
>
> Hence my proposal for supporting multiple time scales for different 
> purposes:
>
>
> 1) TAI: Use this and only this for any and all purposes that involve 
> recording the time an event took place. Including forensic and 
> scientific purposes.
>
> 2) PIT: Use this for inter-machine communications. It may also be used 
> to present TAI in a human readable form because the mapping from TAI 
> to PIT is fixed.

It would, in my view, be better to use TAI for all inter-machine 
communications, and then allow applications that care, including 
non-scientific display of time to run the PIT algorithm locally.

There was a draft that I think Yaakov Stein and I wrote in the early 
days of TICTOC distinguishing transferred time from presentation time.

As far as I can see the only application that needs the PIT adapted 
version of time is an astronomers wall clock, after all most humans live 
with an error of an 0..2 hours between local astronomical time and the 
time-zone time, and most machines would be quite happy to live with what 
ever time they are using with no further leap seconds.

- Stewart

>
> 3) Local Time Zones: For human display purposes
>
>
> From the conversation it seems that the best definition for PIT would be
>
> PIT = TAI  + Smear ( Lag (UTC, 50 years ))
>
>
>
> On Tue, Jan 3, 2017 at 12:27 PM, Stewart Bryant 
> <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:
>
>
>     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 highly
>     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 second
>     offset. Provide the current leap second offset to the application
>     as a parameter
>     and let the application deal with it as it chooses.
>
>     - Stewart
>
>
>     On 03/01/2017 14:08, Tony Finch wrote:
>
>         Joe Touch <touch@isi.edu <mailto:touch@isi.edu>> 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.
>
>
>