From nobody Fri Oct 22 00:47:46 2021 Return-Path: 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 2B4273A0898 for ; Fri, 22 Oct 2021 00:47:44 -0700 (PDT) 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=unavailable 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 eK6WMkCw8l_h for ; Fri, 22 Oct 2021 00:47:39 -0700 (PDT) Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 569633A0874 for ; Fri, 22 Oct 2021 00:47:38 -0700 (PDT) Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9E9A4600004E for ; Fri, 22 Oct 2021 09:47:33 +0200 (CEST) Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 5C972600004D for ; Fri, 22 Oct 2021 09:47:31 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Fri, 22 Oct 2021 09:47:31 +0200 Message-Id: <61726C92020000A100044BD9@gwsmtp.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 18.3.1 Date: Fri, 22 Oct 2021 09:47:30 +0200 From: "Ulrich Windl" To: , , Cc: "ntp@ietf.org" References: <84735FB40200007C44DF974D@gwsmtp.uni-regensburg.de> <236983740200003E824A10E1@gwsmtp.uni-regensburg.de> <616E7B69020000A10004491E@gwsmtp.uni-regensburg.de> <616E933D020000A100044957@gwsmtp.uni-regensburg.de> <72083C72020000E06A6A8CFC@gwsmtp.uni-regensburg.de> <9E2EA18B020000B86A6A8CFC@gwsmtp.uni-regensburg.de> <6EFADD85020000BDFDA5B133@gwsmtp.uni-regensburg.de> <61714B21020000A100044B83@gwsmtp.uni-regensburg.de> <393ee78b-e2d6-e6bf-76a4-f5375724503f@meinberg.de> In-Reply-To: <393ee78b-e2d6-e6bf-76a4-f5375724503f@meinberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] =?utf-8?b?QW50dzogUmU6ICBBbnR3OiBSZTogQW50dzogW0VYVF0gUmU6?= =?utf-8?q?_New_Version_Notification_for_draft=E2=80=91gruessing=E2=80=91n?= =?utf-8?b?dHDigJFudHB2NeKAkXJlcXVpcmVtZW50c+KAkTAzLnR4dA==?= X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 07:47:45 -0000 >>> Martin Burnicki = schrieb am 21.10.2021 um 15:20 in Nachricht <393ee78b-e2d6-e6bf-76a4-f5375724503f@meinberg.de>: > Ulrich Windl wrote: >>>>> Hal Murray schrieb am 21.10.2021 um 11:20 = in >> Nachricht >> <20211021092000.13DDD28C157@107-137-68-211.lightspeed.sntcca.sbcglobal.n= et>: >>=20 >> ... >>> The root of the problem is smearing. The current implementation hides = it >>> from >>> the client software. >> ... >>=20 >> I wondered: Requiring that smearing servers lower (increase) their = startum=20 > by one or two? >> So when mixing sources, the non-smearing servers might win the = selection. >=20 > If I remember correctly, the stratum number plays not a big role in = the=20 > selection algorithm of ntpd. It's more important that different time=20 > sources agree on the "same" time. True. Maybe the "rest of the smear correction" (correction that still has = to be done) should be added to the dispersion instead. >=20 > So if there's a smearing server in a clique of non-smearing server, = the=20 > smearing server should be outvoted as falseticker. If the majority of=20 > non-smearing servers have the leap second warning bit set, the client=20 > should accept it and handle the leap second as usual. >=20 > On the other hand, if the majority of configured servers do the same=20 > smearing, the non-smearing server should be outvoted. And in addition,=20= > the the smearing servers (which are the majority) do *not* have the = leap=20 > second warning bit set, so the client should not accept the leap = second=20 > warning, but instead follow the smeared time that hides the leap second. >=20 > So the client may either smear its time, or step the time for the = leap=20 > second, depending ion the majority. >=20 >> An other question: Can a smearing server be confused when getting = smeared=20 > time from another smearing server? >> (something like: time is "t", but server smeared it to "t-0.5". The=20 > receiving server thinks it has to smear it to "t-0.5-1" eventually.) >=20 > If a secondary server gets smeared time from a primary server, it = just=20 > follows that time and doesn't even notice the leap second, just like = any=20 > other client. >=20 > So it doesn't add some other smearing offset, *except* if the = secondary=20 > has a leap second file that forces it to handle a leap second. So the assumption is that only stratum-1 servers do leap smearing and = higher strati even when seeing a leap announcement do "jump"? Or are they = expected to ignore the leap announcement? Or do the smearing servers keep = the leap announcement for themselves (not pass it on)? Thinking about it that would demand that a smearing server always = indicates "no leap" (LI=3D=3D00) to ist clients as it actualy converts the = leap event (taking one second) to a "smearing interval" (taking hours). Regards, Ulrich