Re: [Ntp] Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

Martin Burnicki <martin.burnicki@meinberg.de> Fri, 08 January 2021 15:41 UTC

Return-Path: <martin.burnicki@meinberg.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 724873A1067 for <ntp@ietfa.amsl.com>; Fri, 8 Jan 2021 07:41:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level:
X-Spam-Status: No, score=-2.361 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, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
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 glZ09Z_EH0tU for <ntp@ietfa.amsl.com>; Fri, 8 Jan 2021 07:41:46 -0800 (PST)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D2B3A1065 for <ntp@ietf.org>; Fri, 8 Jan 2021 07:41:46 -0800 (PST)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 499E171C01AA; Fri, 8 Jan 2021 16:41:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1610120504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yMR9I6Ue+vYngTrkBmWeV7NFXLFNI0VCNiOyzbRegcg=; b=eg/QBqavGX5fx+gi1ff8stIV4kt5CGW5i+ZJ0tkbdHJLz2RFceKLI2/LxwCRibis72Yghk +yLxsWEGw4+7P5pAwUzQi3ZnhwI8TbO5FT8yjIGxkzek/wsZAAdA6E8w15OB8VDmfDtk68 8IASLdX7OPiZf0QIoD/YeULnnYmVxqx3lkt/VrgVsRy4WspxeqepMlRdOsR/A7g7RVkAbJ Gl8Zrp3NBeWft9qy+PYyt0V4g6+zmMaE6/v3cd6oYusA9mwfqHK+rL8jaq2XnLWBqDsog5 mEhHNU+qHRV3naIyhCz33EWkzJ9WcSSZrV4CX4+ellpr8LsdL8eg725+yNHL9A==
X-Footer: bWVpbmJlcmcuZGU=
Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)); Fri, 8 Jan 2021 16:41:42 +0100
To: Doug Arnold <doug.arnold@meinberg-usa.com>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "mlichvar@redhat.com" <mlichvar@redhat.com>, "emmanuel.fuste@thalesgroup.com" <emmanuel.fuste@thalesgroup.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>, "magnus@rubidium.se" <magnus@rubidium.se>
References: <20210102081603.1F63C40605C@ip-64-139-1-69.sjc.megapath.net> <cecaf661-92af-8b35-4c53-2f025c928144@rubidium.se> <20210104164449.GE2992437@localhost> <b1e61f7d-6cea-5e99-69f0-7eae815d9e19@rubidium.se> <20210105083328.GA3008666@localhost> <ba5d2cde-6b5e-d9b6-1877-c4060bf43e80@rubidium.se> <20210105144225.GH3008666@localhost> <35c4be55-b6af-82b5-aacd-d5a591383dec@rubidium.se> <20210105162901.GJ3008666@localhost> <c78ad54e-dd10-fc8e-fc88-cf65f9fb29a5@thalesgroup.com> <20210107115226.GB3415835@localhost> <a0e137c3-5e4a-2277-2e1d-2284b39de309@meinberg.de> <F5292A54020000F16A6A8CFC@gwsmtp.uni-regensburg.de> <31C5A262020000D985F26575@gwsmtp.uni-regensburg.de> <DD4618490200001F6A6A8CFC@gwsmtp.uni-regensburg.de> <56C209690200001686EDC2A6@gwsmtp.uni-regensburg.de> <5FF80A6B020000A10003E084@gwsmtp.uni-regensburg.de> <0D49017F-D7C4-49C5-936D-272B633D5575@meinberg-usa.com> <5c1e7eb9-b1a0-f7bf-c087-cc1fb32b5021@meinberg.de> <95CD4B48-4D9E-414C-B8E7-96AA3F5499CA@meinberg-usa.com>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Organization: Meinberg Funkuhren GmbH & Co. KG, Bad Pyrmont, Germany
Message-ID: <58137445-0b8a-e68b-21f5-5a11013657b7@meinberg.de>
Date: Fri, 08 Jan 2021 16:41:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <95CD4B48-4D9E-414C-B8E7-96AA3F5499CA@meinberg-usa.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/bRqSb0ozyP8WVKiX6jK1orHWAzE>
Subject: Re: [Ntp] Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)
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: Fri, 08 Jan 2021 15:41:48 -0000

Doug Arnold wrote:
> When I first heard of leap seconds I thought it was a terrible idea, a clumsy hack.  Since then I've come to understand that database and other application programmers are not timing people and often don't handle the possibility of leap seconds, or don't handle it correctly.  I believe that Google and other large data center companies have figured out that it causes less problems to mess up the time for a while than to have leap seconds.

With the systems (and specifically the *applications*) we have now, you
have 2 different choices when a leap second is inserted:

a) Let the kernel step the time back by 1 s, so applications may observe
duplicate time stamps. This can only be avoided if each application that
is possibly affected is aware of leap seconds, e.g. on Linux systems it
could periodically query the kernel if a leap second has been announced,
and then try to handle it properly.

The advantage of this approach is that the system time can be very
precise *except* during the leap second.


b) The system time can be smeared around a leap second, in which case an
application doesn't even notice there is a leap second, so there is no
problem with time steps back.

The disadvantage of this approach is that the system time is off by up
to 1 s if you smear the time completely before or after the leap second,
or up to +/- 0.5 s if you do symmetric smearing before and after the
leap second.


If you can accept such a time offset (which is huge, compared to the
normal millisecond offset) depends on the application.

In any case this is a dilemma that can't be fixed by simply using TAI
time stamps instead of UTC time stamps in a protocol.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki@meinberg.de
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