i.e. A lot of distributed systems problems can be simplified if you can trust your clocks.
back
3 comments
Or guarantee that two separate coordinates on space-time can have identical values... which would mean breaking some laws of physics.
If the two clocks are stationary with respect to each other, that isn't a problem. Most of Google's servers are on the Earth's surface, so...
(Edit: Yes, different elevations cause a gravitational time dilation difference. For Earth's gravitational field and the elevation difference between different Google servers, I doubt it's an issue at the time resolution that Google needs to maintain.)
> If the two clocks are stationary with respect to each other, that isn't a problem. Most of Google's servers are on the Earth's surface, so...
...you can't generally guarantee that they are (even approximately) stationary with respect to each other, because points on the earth's surface (in general) are not stationary with respect to each other in an inertial frame of reference.
> you can't generally guarantee that they are (even approximately) stationary with respect to each other...
False.
> ... because points on the earth's surface (in general) are not stationary with respect to each other in an inertial frame of reference.
True. There is both the earth's rotation, and the relativistic difference due to differing elevations. But given earth's angular velocity and gravitational gradient, points on the surface are still approximately stationary with respect to each other, where "approximately" is defined by the amount of difference it will make compared to the time precision that Google cares about.
Even if the clocks are stationary with respect to each other (within some tolerance), it's impossible to guarantee completely synchronized clocks among the systems. This follows trivially from the impossibility of instantaneous communication due to the second postulate of special relativity.
If two clocks are stationary with respect to each other, then there is no ambiguity about where the midpoint between them is. Then you just do something like, when your clock hits noon, fire a projectile at a fixed speed toward the other clock. If the projectiles meet at the halfway point, then the clocks are synchronized.
And there is no relativistic funny business involved, because the clocks are stationary with respect to each other. There's no difference of viewpoint as to whether the projectiles met at the halfway point, or where the halfway point was, or even how far off from the halfway point they met (and therefore how far off the clocks are from each other).
This is the argument used in my relativity class to show that you can synchronize clocks that are stationary with respect to each other. (You have to be able to do that to construct an inertial frame of reference, that is, to be able to determine what time coordinate some event occurs at, no matter what spatial location it occurred at.)
"If the projectiles meet at the halfway point, then the clocks are synchronized."
And how would either end-point know this exactly?
That's the point of using physical projectiles, not light beams. You watch. That's how you know.
"Watch" may mean using something like a phased-array radar to measure it more precisely, if you wish...
If you move the clocks together physically, and synchronize them, this removes a large degree of the concern about instantaneous communication (this probably makes communication faster than your tolerances)
But you simply can't. Not even Spanner (Google's globally distributed db that's using that fancy GPS based clock) doesn't pretend that the clock's are actually synchronized.
what time is it anyway?