[Ntp] Re: NTP speed of synchronization question

[Toerless Eckert <[e-mail]>]

Thanks folks

I am trying to figure out what a good set of operational considerations are that the draft
in question migt benefit from. Or rather implementers/operators of the draft.

So, how about the following text:

---

For the mechanism to provide the desired benefit, synchronization of a few millisecond (5)
or less is required. This should in general not be a problem to achieve with minimal NTPv4
installations that are aware of common pittfalls:

When a router restarts, initial synchronization to other NTP server(s) is sped up if the
router has a local clock from which to derive a starting time and if the clock can be stepped
to quickly synchronize to the othrer NTP server(s). If either is not possible, synchronization
may take more than a few seconds and it may be desirable to delay the bringing up this
documents services up to a point when the necessary level of synchronization is achieved.
Optionally, it may be prudent to provide a configurable maximum-synchronization-wait timer
to allow initiating the services without clock synchronization used.

Synchronization across WAN links can be subject to asymmetric latency, which can be as
high as some msec. clock synchronization protocols can not automatically figure out such
asymmetric latencies. If deployments with such asymmetric latencies is required, the clock
synchronization protocol needs to have options to learn about such asymmetries, such as through
configuration.

---
correct/good/suggestions ?

I am aware of PTP implementations to have configu options for asymmetry. I don't remember that
i have seen this in NTP implementations. Is anyone aware of config options for NTP, i'd
be curious to learn about them.

Cheers
    Toerless

On Wed, Aug 14, 2024 at 11:05:01AM +0200, Martin Burnicki wrote:
> Toerless Eckert 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:
> 
> All of the answers to the questions below depend completely on the NTP
> implementation running on the *client*.
> 
> > 1. Is there any reasonw why we should NOT be able to achieve synchronization of less than 5 msec ?
> 
> Assuming that the time provided the NTP server(s) is sufficiently accurate
> and precise, this should not be a problem if the client runs a good NTP
> implementation. It's the client who has to evaluate the time stamps involved
> in the packet exchange, calculate time offset vs. packet delay, identify and
> discard outliers, etc. See also:
> https://kb.meinbergglobal.com/kb/time_sync/time_synchronization_accuracy_with_ntp
> 
> A systematic residual time offset may affect the final accuracy if there is
> some asymmetric delay on the network path between the client and the
> server(s), maybe due to different upload and download speeds. See:
> https://kb.meinbergglobal.com/kb/time_sync/time_synchronization_errors_caused_by_network_asymmetries
> 
> > 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 initial range of the time offset on the client, and the
> way the client compensates the time offset: The time on the client can be
> stepped to the time received from the server(s), or it can be slewed fast or
> slow.
> 
> > 3. Would synchronization to a local peer be faster ? If so, how fast could it be ?
> 
> Basically, I don't think so, provided that the server responds in time and
> the network connection is stable enough.
> 
> The first KB article I mentioned shows that even on a WAN connection with a
> huge network delay the resulting accuracy achieved with ntpd can be in the
> range of 1 ms.
> 
> > 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 depends on whether the NTP program actually supports this. Again, if
> there is a systematic residual time offset, the client can't report it. If
> the client could determine the offset, it could also compensate it. So to
> detect such systematic offset, you need another reference time that is
> suitable for time comparisons.
> 
> Martin
> -- 
> Martin Burnicki
> 
> Senior Software Engineer
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: [e-mail]
> Phone: [phone]
> Linkedin: https://www.linkedin.com/in/martinburnicki/
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre
> Hartmann, Heiko Gerstung
> Websites: https://www.meinberg.de  https://www.meinbergglobal.com






-- 
---
[e-mail]