Re: [Ntp] Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Martin Burnicki <martin.burnicki@meinberg.de> Thu, 21 October 2021 13:20 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 412773A166D for <ntp@ietfa.amsl.com>; Thu, 21 Oct 2021 06:20:22 -0700 (PDT)
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 a8xHu9uaGTtR for <ntp@ietfa.amsl.com>; Thu, 21 Oct 2021 06:20:16 -0700 (PDT)
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 7CD1F3A1665 for <ntp@ietf.org>; Thu, 21 Oct 2021 06:20:15 -0700 (PDT)
Received: from seppmail.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 AD04371C1416; Thu, 21 Oct 2021 15:20:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1634822413; 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: in-reply-to:in-reply-to:references:references; bh=Ti7yHchNOdq6OiVdxxaIDMOxEHBdpI+x96702oWnYYs=; b=aAx5BBh0jmlGTe9TIXCoolNaD0456jIDKx98DkJFWYj67Rr4opYAHME4wis45WsRmkhKXI EGsZ+/spaaR7A6nVAotz7kErhIO4fKgEVFfopUQj4Q9HQQ8Wu0fh+LNChJC/Y9UjX6lNke 1iODxgM+9eXCqMP5RSScDJW165Tp/BRfG89TDjlG9AtsdsGS0+29HaXpZP/N/XKEq9psBN 4PNC7oka6AF8Ls89kNhKvRUmUTOBAg5u9yIUbD1+YAWw9Jv6p9CAqrCupxeVwiqw0hV38L v0Jb5vklN2VkARVnKwedanTw4wG6m4CbwdWs42q4VRdFi4hUwRWOrAkzvoZxHg==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Thu, 21 Oct 2021 15:20:13 +0200 (CEST)
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, 21 Oct 2021 15:20:10 +0200
Message-ID: <393ee78b-e2d6-e6bf-76a4-f5375724503f@meinberg.de>
Date: Thu, 21 Oct 2021 15:20:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Content-Language: en-US
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, mlichvar@redhat.com, halmurray+ietf@sonic.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <D19C98F0020000AAAB822621@gwsmtp.uni-regensburg.de> <B6193D9D02000051AB59E961@gwsmtp.uni-regensburg.de> <84735FB40200007C44DF974D@gwsmtp.uni-regensburg.de> <236983740200003E824A10E1@gwsmtp.uni-regensburg.de> <CEFD0B92020000436A6A8CFC@gwsmtp.uni-regensburg.de> <616E7B69020000A10004491E@gwsmtp.uni-regensburg.de> <DB577C29020000EF6A6A8CFC@gwsmtp.uni-regensburg.de> <616E933D020000A100044957@gwsmtp.uni-regensburg.de> <72083C72020000E06A6A8CFC@gwsmtp.uni-regensburg.de> <D11527C602000032FDA5B133@gwsmtp.uni-regensburg.de> <9E2EA18B020000B86A6A8CFC@gwsmtp.uni-regensburg.de> <6EFADD85020000BDFDA5B133@gwsmtp.uni-regensburg.de> <61714B21020000A100044B83@gwsmtp.uni-regensburg.de>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Organization: Meinberg Funkuhren GmbH & Co. KG, Bad Pyrmont, Germany
In-Reply-To: <61714B21020000A100044B83@gwsmtp.uni-regensburg.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------BWAT3vq88ahJX3fcJZ0yAtVW"
X-SM-outgoing: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/hlGIs-NlFYg6LIK1MlZkAbQ4zN0>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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, 21 Oct 2021 13:20:23 -0000

Ulrich Windl wrote:
>>>> Hal Murray <halmurray+ietf@sonic.net> schrieb am 21.10.2021 um 11:20 in
> Nachricht
> <20211021092000.13DDD28C157@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:
> 
> ...
>> The root of the problem is smearing.  The current implementation hides it
>> from
>> the client software.
> ...
> 
> I wondered: Requiring that smearing servers lower (increase) their startum by one or two?
> So when mixing sources, the non-smearing servers might win the selection.

If I remember correctly, the stratum number plays not a big role in the 
selection algorithm of ntpd. It's more important that different time 
sources agree on the "same" time.

So if there's a smearing server in a clique of non-smearing server, the 
smearing server should be outvoted as falseticker. If the majority of 
non-smearing servers have the leap second warning bit set, the client 
should accept it and handle the leap second as usual.

On the other hand, if the majority of configured servers do the same 
smearing, the non-smearing server should be outvoted. And in addition, 
the the smearing servers (which are the majority) do *not* have the leap 
second warning bit set, so the client should not accept the leap second 
warning, but instead follow the smeared time that hides the leap second.

So the client may either smear its time, or step the time for the leap 
second, depending ion the majority.

> An other question: Can a smearing server be confused when getting smeared time from another smearing server?
> (something like: time is "t", but server smeared it to "t-0.5". The receiving server thinks it has to smear it to "t-0.5-1" eventually.)

If a secondary server gets smeared time from a primary server, it just 
follows that time and doesn't even notice the leap second, just like any 
other client.

So it doesn't add some other smearing offset, *except* if the secondary 
has a leap second file that forces it to handle a leap second.


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