IETF Logo Mail Archive

Re: [Ntp] Temperature Compensation for NTP?

Philip Prindeville <philipp@redfish-solutions.com> Tue, 08 December 2020 17:29 UTC

Return-Path: <philipp@redfish-solutions.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 B59063A10A2 for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 09:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 HqyMxheppAf5 for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 09:29:18 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (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 ADA7D3A1072 for <ntp@ietf.org>; Tue, 8 Dec 2020 09:29:18 -0800 (PST)
Received: from [192.168.3.4] ([192.168.3.4]) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 0B8HTEsT123841 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Dec 2020 10:29:14 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <X89r3DaFE9RSo5NX@roeckx.be>
Date: Tue, 08 Dec 2020 10:29:14 -0700
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0794DE6-78A1-4E64-841F-865B5354EA8C@redfish-solutions.com>
References: <5FCF48F1020000A10003D5E1@gwsmtp.uni-regensburg.de> <X89r3DaFE9RSo5NX@roeckx.be>
To: Kurt Roeckx <kurt@roeckx.be>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jufAck8XzeCkVZWaWtuPtjKy2d0>
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 17:29:27 -0000


> On Dec 8, 2020, at 5:04 AM, Kurt Roeckx <kurt@roeckx.be> wrote:
> 
> On Tue, Dec 08, 2020 at 10:35:45AM +0100, Ulrich Windl wrote:
>> Should NTPv5 have such a (similar) capability?
> 
> I'm not sure what you're asking. This just seems to be an
> implementation detail. You apply a correction, and as a result,
> hopefully, your maximum error should get smaller. I don't see
> how it's relevant for the protocol.
> 
> Should the RFC also cover which corrections you can all apply, and
> how that has an effect on the values you send to the client? There
> is at least a proposal where that would be outside the scope.
> 
> 
> Kurt


I think what Ulrich is pointing out is that the specification, rather than calling out specific requirements for the algorithm, actually specifies a/the algorithm, at least in v4.

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?

v2.23.0 | Report a Bug | By Email