[Ntp] Re: NTP speed of synchronization question

Miroslav Lichvar <mlichvar@redhat.com> Wed, 14 August 2024 08:42 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 AA502C151540 for <ntp@ietfa.amsl.com>; Wed, 14 Aug 2024 01:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T4ZVFDjmcEZ for <ntp@ietfa.amsl.com>; Wed, 14 Aug 2024 01:42:57 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CCDC151532 for <ntp@ietf.org>; Wed, 14 Aug 2024 01:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1723624970; 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=V4rqrh+4M5pa8e6fjwE+5sjri/l/r+Wp+zQdAywuPw8=; b=ZqaqTK56wcXruMnRRxZ6JwUbH5wKTvvVi1kc7Z4jmNrSvipI1hesoYESn/RhjQoqvkCSC2 Zp2p2FtlVz10Gonh242mLAtGOV+RG9gJHd9PAVaq4a+Z4EmSmhUSe4czVtsOUVjZBeJry6 kXmwTfP4Vqb8ZP4q0Y6BoLE3BmiKP6g=
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-163-S5I-XW6RPiuT3eIbG-A6iQ-1; Wed, 14 Aug 2024 04:42:46 -0400
X-MC-Unique: S5I-XW6RPiuT3eIbG-A6iQ-1
Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6D84B1944F02; Wed, 14 Aug 2024 08:42:45 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7C6E71955E8C; Wed, 14 Aug 2024 08:42:44 +0000 (UTC)
Date: Wed, 14 Aug 2024 10:42:41 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Toerless Eckert <tte@cs.fau.de>
Message-ID: <ZrxuAWeRok8VxwZf@localhost>
References: <ZrxmPeWAKqsIv86j@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
In-Reply-To: <ZrxmPeWAKqsIv86j@faui48e.informatik.uni-erlangen.de>
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Message-ID-Hash: 7KSFSBGJ3BIGUCJ6C6KGPUZUOM7ZHA77
X-Message-ID-Hash: 7KSFSBGJ3BIGUCJ6C6KGPUZUOM7ZHA77
X-MailFrom: mlichvar@redhat.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ntp@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Ntp] Re: NTP speed of synchronization question
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/r2sDP3DGniEbYXSgLAIQdCWCArw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Owner: <mailto:ntp-owner@ietf.org>
List-Post: <mailto:ntp@ietf.org>
List-Subscribe: <mailto:ntp-join@ietf.org>
List-Unsubscribe: <mailto:ntp-leave@ietf.org>

On Wed, Aug 14, 2024 at 10:09:33AM +0200, Toerless Eckert wrote:
> Assuming typical high-end routers and their implementation of NTP:
> 
> 1. Is there any reasonw why we should NOT be able to achieve synchronization of less than 5 msec ?

Not in a local wired network, but over internet routing asymmetries
can easily cause larger errors that 5 milliseconds. You would need to
limit the asymmetry.

> 2. Assuming synchronization only across some WAN connection, how long would it typically
>    take for a restarting router to synchronize against a peer to that level of accuracy or better ?

It depends on the NTP implementation and its configuration, most
importantly how frequently it is allowed to poll its server. It can
take a second or even less, or minutes, or hours.

> 3. Would synchronization to a local peer be faster ? If so, how fast could it be ?

It would be shorter by the round-trip time and the fewer number of
samples needed to get the required accuracy (less filtering need with
a smaller jitter).

> 
> 4. Am i correct to remember that the accuracy of synchronization should be accessible to
>    user of NTP (such as the aforementioned drafts mechanism) through some diagnostics interface ?
>    ( think to remmeber that to be the case from typical NTP implementation CLI).

The CLI tools should report the NTP root distance, or its two
parts called root delay and root dispersion. The distance estimates
the maximum error of the clock assuming the most extreme asymmetry in
the network delay.

-- 
Miroslav Lichvar