IETF Logo Mail Archive

Re: [Ntp] Leap smearing

Martin Burnicki <martin.burnicki@meinberg.de> Thu, 10 December 2020 14:33 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 C72083A0F0A for <ntp@ietfa.amsl.com>; Thu, 10 Dec 2020 06:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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.001, 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 Di9kVRQDccOP for <ntp@ietfa.amsl.com>; Thu, 10 Dec 2020 06:33:00 -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 668C13A0F01 for <ntp@ietf.org>; Thu, 10 Dec 2020 06:33:00 -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 DE29571C18D5; Thu, 10 Dec 2020 15:32:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1607610776; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3cbCf77xQhM/1Zptj+/7ULm/hx2CRjWTnc59YeSI4I8=; b=Vu1enP34zzQLQyqEGDZpJmHDYB8uf0OCygvdXg98S5Qd8QIX69QmJ+Xwp2ffybr+rTEDGI 5fxYwNKdUVvarWG02HrU0Qu6lHsVLnevQL0FVvu+4PHiDHkoG8ubhPJ5bdo8C+wUVhwkbx e0TZp0Zq6MrIwh1eyVaU1JqlKQpudQfPQuCZlyd7adTSwOjNkifa1+ZBdJpw6JKOxHLky2 xm23/ZmzccVFdeEDIW3ayRaK/lqGfpvBeXA7RWRnp0hdY6DO1LGmsAwpumNyajApI/FVFD 2bbCOyFxQpwFyNn+p1e3i4klK5EvIDb5pEky1BMijupRaqGwWEM8a8MkkjHvdA==
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)); Thu, 10 Dec 2020 15:32:56 +0100
To: Magnus Danielson <magnus@rubidium.se>, ntp@ietf.org
References: <5E7696D6-0986-4A0C-8FF7-2CEBD01CE717@meinberg-usa.com> <eedff236-f8c2-a6d5-10d2-0136904fc390@rubidium.se>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Organization: Meinberg Funkuhren GmbH & Co. KG, Bad Pyrmont, Germany
Message-ID: <540f9f25-5c7a-b6ac-9fcf-6eeb3162dcac@meinberg.de>
Date: Thu, 10 Dec 2020 15:32:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <eedff236-f8c2-a6d5-10d2-0136904fc390@rubidium.se>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/F2E0dJewVKvC2pb2PQrE7NLLCg0>
Subject: Re: [Ntp] Leap 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: Thu, 10 Dec 2020 14:33:03 -0000

Magnus Danielson wrote:
> On 2020-12-10 01:24, Doug Arnold wrote:
[...]
>> 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.

Again, IMO you have to distinguish.

If you have a "sophisticated" client for a specific application, you can
retrieve normal UTC from the server, with leap second warnings included,
and do the smearing locally at the client side.

As far as I know, some frameworks use UTC-SLS to do this, even if the
operating system time doesn't.

This should work fine for a specific application, but it would be
interesting to see what happens if programs that have been built with
UTC-SLS share timestamped data with programs that rely on the system
time provided by the native API calls of the operating system. ;-)

However, if you have "normal" clients and you just want to prevent your
applications from hickups when the system time is stepped back, it's
easier to let the server smear the time, because you only have to
configure this once, and all clients behave the same.


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

v2.23.0 | Report a Bug | By Email