3 ms·
> I mean, even if you had a picosecond accurate clock available for use inside a server farm, you would still need a way to query it with a known (not necessari
by alexkus 14y ago
> I mean, even if you had a picosecond accurate clock available for use inside a server farm, you would still need a way to query it with a known (not necessarily zero; just known) latency to synchronize several machines. Servers are not known latency machines (unless specialized hardware is involved).
I think it's just a case of traditional NTP (which is itself based on atomic clocks and/or GPS) done over 'the Internet' is subject to too much latency that it becomes unreliable for their needs (e.g. Spanner).
By putting the equivalent of their own NTP master servers (based on GPS and atomic clocks) in each of their major data centres they solve that part of the problem. The possible LAN latency is much more controllable and reliable, to within tolerances that makes Spanner workable.
The clever bit isn't putting their own NTP master servers in each data centre, it's how Spanner works when using this info. The article puts far too much emphasis on the former whilst glossing over the latter.
- ghshephard 14y agoTheir alternative to NTP (and, it should be noted, NTP is never once mentioned in their paper), TrueTime API is actually pretty impressive. They are able to maintain <10ms latency 99.9% of the time across data centers all over the world. That's not something you can easily do with NTP over the internet. Placing Stratum-0 receivers (and, in fact, Stratum 0 devices) in their data centers isn't unheard of, but that alone won't get you the kind of global-temporal-synchronization that Google is able to achieve with TrueTime API. I'm looking very forward to the paper on that protocol/system which will hopefully be forthcoming - They tease it with this: "This section describes the TrueTime API and sketches its implementation. We leave most of the details for another paper: our goal is to demonstrate the power of having such an API."