[Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Thu, 12 September 2019 10:16 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9898812010E for <ntp@ietfa.amsl.com>; Thu, 12 Sep 2019 03:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AqKgqnrupbrI for <ntp@ietfa.amsl.com>; Thu, 12 Sep 2019 03:15:58 -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 AEE25120077 for <ntp@ietf.org>; Thu, 12 Sep 2019 03:15:58 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id CE978600005A for <ntp@ietf.org>; Thu, 12 Sep 2019 12:15:55 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx1.uni-regensburg.de (Postfix) with ESMTP id BDB996000050 for <ntp@ietf.org>; Thu, 12 Sep 2019 12:15:54 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 12 Sep 2019 12:15:54 +0200
Message-Id: <5D7A1AD9020000A100033ABD@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Thu, 12 Sep 2019 12:15:53 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <stenn@nwtime.org>,<mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <252618a3-d2fb-d5b1-baa4-72b16ef0f845@nwtime.org> <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se> <20190902124303.GF15024@localhost> <24c6b80b-2bbb-e555-9eaf-34f964947d6e@nwtime.org> <20190912094603.GN21704@localhost> <D92F920B020000B67ED719BE@gwsmtp.uni-regensburg.de> <5FEC8C46020000E66A6A8CFC@gwsmtp.uni-regensburg.de> <0FA08C67020000EC822C0D04@gwsmtp.uni-regensburg.de> <85F2C64C020000776A6A8CFC@gwsmtp.uni-regensburg.de>
In-Reply-To: <85F2C64C020000776A6A8CFC@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Wyo0DSIDUuztn3VyPulGG1vgepU>
Subject: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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, 12 Sep 2019 10:16:02 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 12.09.2019 um 11:46 in
Nachricht <20190912094603.GN21704@localhost>:
> On Mon, Sep 02, 2019 at 05:52:33AM ‑0700, Harlan Stenn wrote:
>> The thing is that NTP is a complete specification with a goal of time
>> synchronization that includes *known behavior in the face of impulse
>> response*.
>> If one uses different algorithms with different impulse response
>> behaviors, this can trigger oscillations and even unstable tracking (the
>> wheels fly off the bus).
> This was discussed a bit on the last meeting.
> Does anyone have an example of a PLL that is unstable when cascaded
> with a different loop? If something works well enough to be stable

I think it was the old Dave Mills consensus like: "It's only NTP if it
provides the same output for the same input". So if you think of some
improvements, they still would not be allowed (I had some discussions while
implementing PPS in the Linux kernel)

> when synchronizing a clock of an NTP client to a stable reference
> clock in different network conditions, how could it cause its own
> clients to become unstable?
> ‑‑ 
> Miroslav Lichvar
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp