Re: [Ntp] Temperature Compensation for NTP?

Kurt Roeckx <kurt@roeckx.be> Tue, 08 December 2020 22:31 UTC

Return-Path: <kurt@roeckx.be>
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 3FAE33A1272 for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 14:31:32 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 G7SxMy9yHXwk for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 14:31:30 -0800 (PST)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 CFCF43A1289 for <ntp@ietf.org>; Tue, 8 Dec 2020 14:31:29 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 9B3E3A8A0117; Tue, 8 Dec 2020 22:31:27 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 30C001FE0DE5; Tue, 8 Dec 2020 23:31:27 +0100 (CET)
Date: Tue, 08 Dec 2020 23:31:26 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Harlan Stenn <stenn@nwtime.org>
Cc: ntp@ietf.org
Message-ID: <X8/+vnxPoYB+seTN@roeckx.be>
References: <20201208214421.CE92B40605C@ip-64-139-1-69.sjc.megapath.net> <d406413e-c539-cb74-daf4-5298a8a1db83@nwtime.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d406413e-c539-cb74-daf4-5298a8a1db83@nwtime.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ic8UEqNCADJniJ8Pmm6o-dm0S8E>
Subject: Re: [Ntp] Temperature Compensation for NTP?
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: Tue, 08 Dec 2020 22:31:32 -0000

On Tue, Dec 08, 2020 at 01:50:52PM -0800, Harlan Stenn wrote:
> On 12/8/2020 1:44 PM, Hal Murray wrote:
> > 
> > philipp@redfish-solutions.com said:
> >> Given we have better understanding now of the thermal stability of solid
> >> state (crystal) oscillators, why not include that into the algorithm if we’re
> >> going to flesh it out specifically? 
> > 
> > I think the algorithm(s) should be split out to a separate document, if any.
> 
> In which case somebody will only implement the protocol and do whatever
> they want with the algorithms, and clients will connect to this server
> and there will be a significant chance that because of the different
> algorithms, the behavior will be different and there will be train wrecks.

I think we should not say how it should be implemented, but explain what
is expected of what is put in all the fields. For instance, it
should explain how to calculate the errors, and what you
optionally do to minimize the errors.

> Different timing algorithms will cause much bigger problems.
> 
> NTP is all about a defined impulse response.

I think defining NTP as a impulse response is the wrong approach.
It's an implementation detail. If other systems use different
algorithms, it should only have an effect on the uncertainty. If
it causes big problems, it's an implementation problem.


Kurt