4 ms·
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 synch
by statstutor 6y ago
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 https://en.wikipedia.org/wiki/Network_Time_Protocol: "Asymmetric routes... can cause errors of 100 ms or more."]
- benjojo12 6y agoThe 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
- jtsiskin 6y agoYes, 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
- toast0 6y ago> 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.