Re: [Ntp] Frequency transfer in NTP

Miroslav Lichvar <mlichvar@redhat.com> Mon, 01 February 2021 11:39 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 DCF3E3A0DF9 for <ntp@ietfa.amsl.com>; Mon, 1 Feb 2021 03:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 WrT8MZbgNald for <ntp@ietfa.amsl.com>; Mon, 1 Feb 2021 03:39:05 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FE63A0D6F for <ntp@ietf.org>; Mon, 1 Feb 2021 03:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612179543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sR5N2+urm5k4IZbRcxBMrJqHQwV78rk3PgZghkrsdD8=; b=FmnFZQOBl5Ga9lBz31qkY1VRUeJTCke8EncATv0sQgJEacWkajm2Tlo20X878fd1XSDEYF 33rM6MLGMK1EdmZifbSLE4omCoHEi1OACpgV7xsiMxtzhXn+R14spwmivgSpsdeM0qltaA JZoNwdRHEqMoFYEEJi2qxYchQltU55Y=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-302-UGM71oOGNi6wYuDPYxyQeg-1; Mon, 01 Feb 2021 06:39:02 -0500
X-MC-Unique: UGM71oOGNi6wYuDPYxyQeg-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19CDE835DE5; Mon, 1 Feb 2021 11:39:01 +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 6E9AC5F7D8; Mon, 1 Feb 2021 11:38:59 +0000 (UTC)
Date: Mon, 01 Feb 2021 12:38:56 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Magnus Danielson <magnus@rubidium.se>
Cc: ntp@ietf.org
Message-ID: <20210201113856.GI1205378@localhost>
References: <20210128143137.GA1205378@localhost> <f60202de-d53f-4dea-6e2b-d59dbb0e1143@rubidium.se> <20210201093709.GF1205378@localhost> <a22737e3-05d0-e681-e32f-daada351e51c@rubidium.se>
MIME-Version: 1.0
In-Reply-To: <a22737e3-05d0-e681-e32f-daada351e51c@rubidium.se>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0Ru57hBUIc74iSC9Zxf0yL5rFEI>
Subject: Re: [Ntp] Frequency transfer in 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: Mon, 01 Feb 2021 11:39:07 -0000

On Mon, Feb 01, 2021 at 12:00:50PM +0100, Magnus Danielson wrote:
> On 2021-02-01 10:37, Miroslav Lichvar wrote:
> > On Sun, Jan 31, 2021 at 11:30:03PM +0100, Magnus Danielson wrote:
> > Yes, you can dampen the loops to avoid the overshoot, but that will
> > have a negative impact on the timekeeping performance. You can
> > minimize the phase error, or frequency error, but not both at the same
> > time.
> Turns out that as you measure the phase stability in MTIE and TDEV, as
> well as frequency stability in ADEV, you need to remove that overshot /
> resonance for best stability. This becomes especially true as you build
> a chain of them, as it will grow worse along the chain.

Right. You cannot minimize the phase error upper in the chain without
disturbing the clocks furher down in the chain. A sacrifice needs to
be made to keep the chain stable unless the frequency is transfered
separately. That's what I tried to explain in the post.

> While extremely simple, difficult to tune has not been my experience.
> Once one have done once gain scaling right, properly orthogonal setting
> of damping and frequency have been straight-forward. Getting optimum
> performance given a certain condition is as always a bit tricker, but
> not impossible.

The tricky part is making it adaptive. It's easy to tune a PI loop for
a well-characterised clock and network, but making it work well over a
wide range of conditions, as is common in NTP, is hard.

> > If you wanted to be constructive, it would be best if you showed us an
> > example of a loop that doesn't overshoot in the step response and
> > otherwise performs similarly to ntp or chrony.
> I could provide an example of scaling with poll-rate, sure. I just don't
> have the setup to do measurement of a chain, so that would take time and
> effort that I might not be able to pull together, but others may have that.

I'd like to see an example of a loop (it doesn't have to be PI) that
performs similarly or better than an implementation using the proposed
frequency transfer. I don't think that is possible. You say it is, so
an example would be a good way to show that.

Just post the code of the loop. In any language you like. I can
integrate it with NTP and compare it with the existing
implementations.

-- 
Miroslav Lichvar