That forms a basis for the difficulty. But then there's additional layers of difficulty in real networks where the path between nodes is often asymmetric, and you may also observe that elapsed time (A -> B -> A) is sometimes greater than elapsed time (A -> C -> B -> C -> A) or (A -> C -> B -> A) or (A -> B -> C -> A)
Doesn't each node just need to know its exact path (or latency of same) to the time source each is synchronizing from? The path from node to node doesn't matter because we're ordering log entries from the timestamp of the receiving node.
Imagine you take three atomic clocks, synchronize them, and move each within exactly 1 meter of one of those nodes, directly connected in an identical manner. Relativistic effects are constant. If there are elevation differences, you factor it once and done. The problem with this setup is not relativity. It is quantum uncertainty (and various interference sources, thermal radiation, etc).
How do you know the latency of the path if you haven't synchronized the clocks...
You might be able to control the latency on a LAN, but once you have servers in different locations, good luck. (GPS helps a lot, of course...)
There is this command called 'ping' that tells you that. But in my example, I included the network topology as a known, static factor.
> There is this command called 'ping' that tells you that.
Ping tells you the round trip latency. As I mentioned, asymmetric routing is common and very difficult to measure.
> But in my example, I included the network topology as a known, static factor.
Ok, so spherical cows.