Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 31 August 2022 11:58 UTC

Return-Path: <heiko.gerstung@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 F3E39C14CE25 for <ntp@ietfa.amsl.com>; Wed, 31 Aug 2022 04:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3CEe2xNrgKC for <ntp@ietfa.amsl.com>; Wed, 31 Aug 2022 04:58:31 -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 2CA8CC14CF0A for <ntp@ietf.org>; Wed, 31 Aug 2022 04:58:30 -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 EA02371C026B; Wed, 31 Aug 2022 13:58:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1661947107; 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=l9bpUaqRjM9d/pp78zZAb27rIo2WUZ4AjCf6+9iE6+4=; b=kK3SuYp1fMODcWbKwu4/a/IUjPgV7kM49wqSezJEIDOLSKzEBjE7Q4q9AgfmNOpZjXZxPI iw15HcwkYP4m/h+jLgN9UYavlfqgLwzlKju9v2pqkMbHdLgG47IIq8X+eFO1lLRAjgrNAC UuvhvtLqYBR3Ot+fEAL+kv0s+LlAX0g0WJDOkW1v/r23sZ79h1IZEzYvimkdiUle/Mk2Yn eDGajXGSEUFZaG9++/UhZYabzC9SdueSUp6fx0MS8fG+iFI4+y2PBgH8mLPTgqEykKiys1 lERgWGB3c0HQIshowIs8d8bAY/OgDSQX0dIpVujo2THtUhxBV7mymbBUEA4ZGg==
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; Wed, 31 Aug 2022 13:58:26 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.63.22070801
Date: Wed, 31 Aug 2022 13:58:22 +0200
Message-ID: <B68AD5B2-F927-466D-9DC1-9D642D6FA2E0@meinberg.de>
Thread-Topic: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
References: <david@venhoek.nl> <CAPz_-SVPE-Fd1vFWnbu+GAPc=y2bkJMW4pyu98bBwDfcm+R2rg@mail.gmail.com> <20220830205143.DFDC328C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <Yw8NBX6ATjRr0/A4@localhost> <C492F298020000C2AB59E961@gwsmtp.uni-regensburg.de> <F347640002000095FDA5B133@gwsmtp.uni-regensburg.de> <8F7E1DA8020000866A6A8CFC@gwsmtp.uni-regensburg.de> <630F1321020000A10004D377@gwsmtp.uni-regensburg.de> <Yw8eVn34M+Ip6ey6@localhost>
In-Reply-To: <Yw8eVn34M+Ip6ey6@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NGEwY2I0NzMxNjI1OWRiMQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: "halmurray@sonic.net" <halmurray@sonic.net>, "ntp@ietf.org" <ntp@ietf.org>, "mayer@pdmconsulting.net" <mayer@pdmconsulting.net>, "david@venhoek.nl" <david@venhoek.nl>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----46E21AA526E403CC6AC67B324A0ED873"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/zp6bJLMwLEovQH2U3Ygxc2Zs3vQ>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 31 Aug 2022 11:58:37 -0000

Am 31.08.22, 10:41 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com>:

>  On Wed, Aug 31, 2022 at 09:52:01AM +0200, Ulrich Windl wrote:
> > I think that is not sufficient: It would be a loop if the server's clock
> > (actually the error estimate) gets worse again, and then the process continues
> > (clock is getting more inaccurate over time). However it it's "smoothed out"
> > it's not a loop IMHO.

> The impact of the loop depends on how much weight the source has,
> polling intervals, number of servers in the loop, and other things.
> Even if the clocks can stay close to the true time, there is still a
> negative impact on stability.

I agree. A timing loop is by (my) definition a situation where a clock servo uses a reference which directly or indirectly is using the output of said clock servo. Even if the input source is only one of multiple sources and even if - in a weighted scenario - it is providing a small contribution. I agree with the statement that, no matter how small the contribution is, it is going to have a negative impact. 

> When the conditions are right, the loop can amplify oscillations. In
> this example (which I have shown before) there are 4 ntpd servers
> using the same source and also synchronizing in a A->B->C->D->A loop.

> https://fedorapeople.org/~mlichvar/ntpresponse/sync-loop.png

> Do you blame the user for misconfiguration? Or would you prefer if the
> protocol enabled the servers to detect the loop?

Yes, it can happen that something changes upstream which is not under the control of the server admin for "A", maybe the admin for "C" decided to switch sources and use "D" now. You can blame both for not talking to each other, but I still see value in helping users to avoid this scenario in an automatic, self-healing way. 


Heiko

> > > In the graph theory, it's a loop in a directed graph.
> > 
> > The problem is the "line" (correpsonding to time): In NTP it's a combination
> > of several sources (lines).

> Which means the loops can be ignored?


>  -- 
> Miroslav Lichvar

--
Heiko Gerstung | Managing Director
T: +49 (0)5281 9309-404 | LinkedIn Profile <https://www.linkedin.com/in/heikogerstung/> | Twitter <https://twitter.com/hgerstung>
heiko.gerstung@meinberg.de

MEINBERG® The Synchronization Experts
 
Meinberg Funkuhren GmbH & Co. KG
Lange Wand 9 | 31812 Bad Pyrmont | Germany
Web: http://www.meinberg.de | http://www.meinbergglobal.com | LinkedIn  <https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Do not miss our Time Synchronization Blog:
http://blog.meinbergglobal.com