Doesn’t this system make the assumption that the latency between the server and the client is symmetric? What happens if the packet takes 100ms to go but 50ms to return?
If Alice pings Bob first, and then sends the total round-trip time to Bob along with the timestamp, then can't Bob easily discover the asymmetry as a constant offset compared to the adjusted clock?
Say Bob assumes the round-trip is symmetrical and adjusts his local time to the time Alice sends minus half the round-trip time, then any asymmetry should be visible as a consistent offset between the local time and the time from Alice no?
This of course assumes the latency and local clocks are relatively stable over the measurement period.
No, that doesn't work. See https://cs.stackexchange.com/q/602/86141 for an explanation of why it's impossible. If you tried your method with concrete numbers, you'd see that it would always say the delay is perfectly symmetric, even when it actually isn't.
If all you have is Alice and Bob, there's no way to determine the time from Alice to Bob, or from Bob to Alice, you can only determine the sum of the two. This is because Alice and Bob have different local time scales.
To put it another way, you can't distinguish being in sync and Bob -> Alice taking 4 ms, and Alice -> Bob taking 6 ms, from being out of sync by 1 ms, and both directions taking 5 ms.
If you've got an external reference, such as GPS or an adjusted for time in transit radio clock, you can figure this out. If you've got a asymmetric first hop, but afterwards a mostly symmetric path (common for residential customers connecting to commercially hosted ntp servers) and a set of servers that are different round trips away, you can get an estimate. But if all the servers are the same/similar round trips, you likely won't have enough information.
The reference implementation does make that assumption. OpenBSD's ntp does too. phk, author of ntimed had written some blog posts exploring asymmetric paths, so I think ntimed doesn't assume symmetry, but assigns it higher probability. I don't remember what chrony does.
The thing is, it's rather difficult to determine the individual components of the path latency without an out of band reference clock. Especially if all of your network clocks are about the same round trip away.
NTP is designed to deal with unreliable networks, from wikipedia:
"It uses the intersection algorithm, a modified version of Marzullo's algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency."[0][1]
So if one server is asymmetric one way (the uplink is slow) and another server is asymmetric another way (the downlink is slow), you can use that to narrow down the possibility space and get an answer that's more accurate than just talking to one server or the other?
It works as long as all your uplinks aren't too slow or too fast...
Variable network latency is different than static assymetry.
Variable latency means sometimes there's extra delay, and is solved by throwing away measurements that are outside the norm. Assymetry in delay is not handled by the reference implementation, which assumes equal delay to and from each server.
