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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 12 September 2019 11:17 UTC

Return-Path: <mlichvar@redhat.com>
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 5921712083F for <ntp@ietfa.amsl.com>; Thu, 12 Sep 2019 04:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 AIekToI8V4Zn for <ntp@ietfa.amsl.com>; Thu, 12 Sep 2019 04:17:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895C3120833 for <ntp@ietf.org>; Thu, 12 Sep 2019 04:17:00 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DEE6307D976 for <ntp@ietf.org>; Thu, 12 Sep 2019 11:17:00 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 97BBE5C25B for <ntp@ietf.org>; Thu, 12 Sep 2019 11:16:59 +0000 (UTC)
Date: Thu, 12 Sep 2019 13:16:53 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190912111653.GP21704@localhost>
References: <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> <5D7A1AD9020000A100033ABD@gwsmtp.uni-regensburg.de> <edb8aa94-a667-a68a-b7e1-f18495c81aab@nwtime.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <edb8aa94-a667-a68a-b7e1-f18495c81aab@nwtime.org>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 12 Sep 2019 11:17:00 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/kuU72HcLJbVGv7-4kpsn-TGDyUc>
Subject: Re: [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 11:17:03 -0000

On Thu, Sep 12, 2019 at 04:03:19AM -0700, Harlan Stenn wrote:
> On 9/12/2019 3:15 AM, Ulrich Windl wrote:
> > 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)
> 
> It's not only about instability.

Well, do you have any examples of instability between different
algorithms?

> It's about known and agreed-upon impulse behavior.

That doesn't seem so useful to me that it should discourage people
from implementing more advanced algorithms.

FWIW, in PTP there is no specification of how the clock should be
controlled. There is a problem with poor performance in long chains of
boundary clocks (one of the reasons why transparent clocks were
invented), but as I understand it, that is not specific to an
implementation or protocol.

-- 
Miroslav Lichvar