Content-Length: 12399 | pFad | http://lwn.net/Articles/1002203/

Is one-way delay really half the round trip? [LWN.net]
|
|
Subscribe / Log in / New account

Is one-way delay really half the round trip?

Is one-way delay really half the round trip?

Posted Dec 15, 2024 8:09 UTC (Sun) by marcH (subscriber, #57642)
Parent article: Providing precise time over the network

Thanks for the great introduction!

> Both mechanisms take the same basic approach, however: they assume that the network delay between a device and the reference clock is symmetrical (which is usually a safe assumption for wired networks),

Veritasium has a nice video where they explain the universe could be asymmetrical and the speed of light faster one way than the other. No one believes that but... we can't prove it! It's a fun watch.

More realistically, it's not hard to imagine that a path through a switch could be not perfectly symmetrical, for instance because the "upstream" and downstream ports are not exactly the same or some other implementation detail.


to post comments

Is one-way delay really half the round trip?

Posted Dec 15, 2024 13:47 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

> More realistically, it's not hard to imagine that a path through a switch could be not perfectly symmetrical, for instance because the "upstream" and downstream ports are not exactly the same or some other implementation detail.

I've seen switches with prioritized ports (typically for the WAN gateway). The other tiers were "gaming" (presumably latency-tuned) and "everything else".

Is one-way delay really half the round trip?

Posted Dec 17, 2024 12:51 UTC (Tue) by wallnerw (subscriber, #131634) [Link]

It is actually quite common that the delay is asynchronous, e.g. PHYs (the chips directly connected to the physical medium) have often asymmetrical delays. The data sheet might state it will be 40-60ns in one direction and 80-120ns in the other direction.

As symmetrical delays are a basic assumption of measurements in PTP, such asymmetric paths cannot be synchronized, as the PTP participants don't "see" this asymmetry. A PTP device might report that it is synchronized with an offset of 0ns to the reference clock, but actually measuring the offset with an oscilloscope will show that it is off by half of that "invisible" path asymmetry.

Is one-way delay really half the round trip?

Posted Dec 18, 2024 14:55 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

More generally there is no technical reason forward and backward network routes should match except most network teams will see any form of asymmetry as extremely inconvenient to work with and will treat it as a design defect.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/1002203/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy