[Ntp] Antw: [EXT] Re: Timescales, leapseconds and smearing

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 09 December 2020 07:29 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727BC3A033F for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 23:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sBLIqJq0G_M9 for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 23:29:17 -0800 (PST)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94BC3A0332 for <ntp@ietf.org>; Tue, 8 Dec 2020 23:29:16 -0800 (PST)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A531E600004D for <ntp@ietf.org>; Wed, 9 Dec 2020 08:29:13 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id B201C600004A for <ntp@ietf.org>; Wed, 9 Dec 2020 08:29:11 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 09 Dec 2020 08:29:11 +0100
Message-Id: <5FD07CC6020000A10003D695@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.0
Date: Wed, 09 Dec 2020 08:29:10 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>, Steve Allen <sla@ucolick.org>
References: <X86sVykHUqlkXP96@roeckx.be> <20201208093104.GR2352378@localhost> <20201208164429.GA11385@ucolick.org>
In-Reply-To: <20201208164429.GA11385@ucolick.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part4D73CFD6.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/RKUTyJ3zOioNq1vxM-hKb1vMH5k>
Subject: [Ntp] Antw: [EXT] Re: Timescales, leapseconds and smearing
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 07:29:20 -0000

>>> Steve Allen <sla@ucolick.org> schrieb am 08.12.2020 um 17:44 in Nachricht
<20201208164429.GA11385@ucolick.org>:
> On Tue 2020‑12‑08T10:31:04+0100 Miroslav Lichvar hath writ:
>> On Mon, Dec 07, 2020 at 11:27:35PM +0100, Kurt Roeckx wrote:
>> > The proposed draft has support for the first 4, and offsets
>> > between some of them. Note that it calls the NTP timescale
>> > UTC, which it's not.
>>
>> How do you suggest it should be called?
> 
> More generally, I think that names of the time scales in the document
> all need an introductory explanation of what they mean.
> 
> Look at monthly issues of BIPM Circular T and it becomes evident that
> there is no "UTC" which is available in real time.  Sources of time
> which can be used by an NTP server there are only
> UTC(pick a laboratory)
> 
> Note in the issues of Circular T that the Bulgarian Institute of
> Metrology (BIM) has had UTC‑UTC(BIM) values around 12 microseconds
> during the entire year 2020.  Nevertheless, UTC(BIM) is the legal
> time in Bulgaria, and devices in Bulgaria might be constrained by
> regulations that require they use UTC(BIM) rather than another
> UTC which is in better agreement with the rest of the world.

This reminds me of "clock hopping" issues: I think with higher precision
"clients" the issue becomes more evident, and I'm not sure what the perfect
solution against the problem is. Maybe the specification should talk about
that, too.
I'm attaching an example that (I think) shows clock hopping (mostly between
two sources, using GPS and DCF-77, respectively).

> 
> The draft does not mention the source or authority for the values of
> UTC, UT1, TAI which are provided by NTP.  The draft almost certainly
> cannot specify particular sources of time values, and in the case of
> TAI there can be no source because TAI is not defined until next
> month when Circular T is published for this month.
> 
> The draft should include definitions for UTC, TAI, UT1 as used by NTP.
> At least for the case of TAI (but maybe for the other time scales
> also) the draft should include explicit text indicating that in the
> context of NTP those terms are used in a generic sense that does not
> specify how the values of time from NTP are related to the actual
> authoritative sources of those time scales.
> 
> ‑‑
> Steve Allen                    <sla@ucolick.org>              WGS‑84 (GPS)
> UCO/Lick Observatory‑‑ISB 260  Natural Sciences II, Room 165  Lat 
+36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng
‑122.06015
> Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp