Splitting the Ping

Re:Splitting the Ping by statstutor on Monday March 01, 2021 @07:20PM (#26310362)

The article says "Now that we have a synced clock", but surely the clock synchronisation would also be unable to resolve any asymmetry in the ping and the synchronisation would inevitably be impacted by this. (Or, does NTP have a solution to this?)

[Edited to add: from https://en.wikipedia.org/wiki/Network_Time_Protocol: "Asymmetric routes... can cause errors of 100 ms or more."]

[ Parent | on HN ]

Re:Splitting the Ping by jtsiskin on Monday March 01, 2021 @09:23PM (#26311217)

Yes, NTP clock sync assumes symmetric delays, so you have the exact same problem.

However they use the closest NTP time server, so assuming the NTP server owners correctly are able to sync their own servers, the offset is probably close.

Unless the asymmetric delay is on the path which both the ping and the NTP synchronization take

[ Parent | on HN ]

Re:Splitting the Ping by toast0 on Monday March 01, 2021 @10:37PM (#26311642)

> Unless the asymmetric delay is on the path which both the ping and the NTP synchronization take

Assuming the NTP server is not on the LAN using a GPS (or other radio) reference, a large part of the asymmetry is on the poster's VDSL last mile hop. At least on my bonded VDSL2 line, it seems there's significant asymmetry; I found with regular ntpd I needed to delay incoming packets by around 18 ms to get a good match between a GPS receiver and network servers; my round trip time to the PPPoE concentrator is about 21 ms, and I was able to find a few NTP servers close enough that round trip to them was about 22 ms; not much room for additional asymmetry there.

[ Parent | on HN ]

Re:Splitting the Ping by benjojo12 on Monday March 01, 2021 @07:36PM (#26310472)

The point was to say, if you are in a DC environment and have ~1ms access to a Stratum 1 NTP server, then you can use that, if you are on DSL/DOCSIS etc, then it's likely required to use GNSS/PPS sources

[ Parent | on HN ]