[Ntp] Re: NTP speed of synchronization question

Watson Ladd <watsonbladd@gmail.com> Wed, 14 August 2024 08:34 UTC

Return-Path: <watsonbladd@gmail.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 4E8A4C14F610 for <ntp@ietfa.amsl.com>; Wed, 14 Aug 2024 01:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ax1nMRBU5fye for <ntp@ietfa.amsl.com>; Wed, 14 Aug 2024 01:34:12 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E493FC14F5F9 for <ntp@ietf.org>; Wed, 14 Aug 2024 01:34:12 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3684eb5be64so3514822f8f.3 for <ntp@ietf.org>; Wed, 14 Aug 2024 01:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723624451; x=1724229251; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nOVcQ54QaBU7/5QxsMXAF3LLIs7qnBrg8cZmuVt2o1E=; b=TVG6wAHmi0x63bxTsv+ieSsNqGpx6xihwNHbjBhy7Uph+AeMLB6o/yBW9MuVoIucvO MxmpfyBLqmTuBKdzHOeQ9GvSlMwkivcPEa4pwfkpEGAVMc6/b5Ef/YsxN73jYBwZ1idU I9zeZzeOa51bjhmDUAwiObT2VfYYBeFv54s8Qcthrr3DxHZaY/axv71dexFsfuK1cpTI B331tUlr9vVvnLRUX6adv4YLBkVBPGx3DiB/SyZaaAGMYjd4SbAEMVUcuE/f5R03siVc k9PePaXQpedqBLYsdCr4YGhkHkN+CNNzrCwI/nZJDJKvsKhwVJ977mrUKx9L9qBghdCe U1GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723624451; x=1724229251; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nOVcQ54QaBU7/5QxsMXAF3LLIs7qnBrg8cZmuVt2o1E=; b=gzbweH6+mIQutsfie6nxlwK7Ip486zRnaWsPRpICcsq63gXXV6Wge8PDv3prVtszVO toAlVctGl1PGcMwLljxSaz9ffhcUe9ShxN4bgDfNYGrosWGFFHRH0AK4zbEJvnvRoLkg ni/jwhFhw3DpCiDDm21dJeXMxjQbEu5Lq+aKK+jjYOlduOa0SJpqf6GF+RVFObGW0CnT lBQ9cUqXveYAQ8E0Vxt6AFV6u2AWaHUcGtw0KAJYvbpMqnZ/p4eiMiH/k1Ht7Pf09sgw jUFPT7jhW3omUanHpsSr5rur3Gl7Fg4uPWlvd74PP9cUSluK+wAhBYv+sdeAyCJ2bL8+ fuwg==
X-Gm-Message-State: AOJu0Yyx2W52EugR55G18AO7niR8XUxvNN2q4wJ8D1GqjId1xMhLewkX GHggZA4bh+DxqSrb0yENPrHkNh4uZBJgSJ2CLX1S7cZOEJ0dTXDdQuz8Q00fasHl6ZzyMTAdCnu RB4THy8X14aaJIsDfuc0/qjIMQAaR7Yb9
X-Google-Smtp-Source: AGHT+IEjQRf160WIdgvrPMq8hhXnMykCpDu8tmQKnf4s031XbeQSsGJVOBUauTLdJ80LMxA+95c6mvNi3LkMNQ/cltg=
X-Received: by 2002:adf:fe8b:0:b0:368:5a32:f5bc with SMTP id ffacd0b85a97d-371777f5a88mr1433756f8f.38.1723624450437; Wed, 14 Aug 2024 01:34:10 -0700 (PDT)
MIME-Version: 1.0
References: <ZrxmPeWAKqsIv86j@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZrxmPeWAKqsIv86j@faui48e.informatik.uni-erlangen.de>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 14 Aug 2024 09:33:58 +0100
Message-ID: <CACsn0cnmcsKZieBXNYtA_ivfY6i66urKVxBuq2Rv62AxcYHp3g@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: F7QSIHJWLHRFE5SSLZ2W4WDATFCMNG2O
X-Message-ID-Hash: F7QSIHJWLHRFE5SSLZ2W4WDATFCMNG2O
X-MailFrom: watsonbladd@gmail.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/D5_DYDIbQhB2CUU9lbYq2DVDbvQ>
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 9:09 AM Toerless Eckert <tte@cs.fau.de> wrote:
>
> Dear NTP WG
>
> I have a few quick ops question against NTP which would take me a lot longer to investigate
> on actual devices. This is for reviewing draft-ietf-bess-evpn-fast-df-recovery which wants
> to utilize clock synchronization between routers.
>
> 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

What's the performance characteristic you want, and how much do you
want to do to get to it? You can get to single digit milliseconds with
right design, and start pushing beyond that with PTP easily. Some
exotic designs go down to nanoseconds, but it's not that exotic, just
a matter of making the pieces go together. How bad can it get when
people screw up? Pretty bad.

>
> 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 ?
>
> 3. Would synchronization to a local peer be faster ? If so, how fast could it be ?

The synchronization speed is entirely dependent on the PLL
characteristics. Implementations and hardware vary in how good they
are at this.

If the router comes up with no idea of the current time, and limits on
the maximum frequency shift, it could take a while to stabilize,
especially if steps aren't allowed. If the clock can be stepped to the
right time, it would be a lot faster. If the RTC is good, again a lot
faster. Putting a clock on each physical hop and arranging the
inheritance accordingly can do good things or bad things depending on
network conditions and the implementation.

>
> 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).

It is in most implementations but they vary in how they do that.

>
> Thanks so much!
>     Toerless
>
> _______________________________________________
> ntp mailing list -- ntp@ietf.org
> To unsubscribe send an email to ntp-leave@ietf.org



-- 
Astra mortemque praestare gradatim