[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
- [Ntp] Re: NTP speed of synchronization question Watson Ladd
- [Ntp] Re: NTP speed of synchronization question Miroslav Lichvar
- [Ntp] Re: NTP speed of synchronization question Martin Burnicki
- [Ntp] Re: NTP speed of synchronization question Hal Murray
- [Ntp] NTP speed of synchronization question Toerless Eckert
- [Ntp] Re: NTP speed of synchronization question Toerless Eckert
- [Ntp] Re: NTP speed of synchronization question Dave Hart
- [Ntp] Re: NTP speed of synchronization question Tony Li
- [Ntp] Re: NTP speed of synchronization question Hal Murray