3 ms·
A long time ago I worked in a finance/trading environment and we had GPS clock receivers in our datacenters that synced from satellites. While they weren't that
by bogomipz 7y ago
A long time ago I worked in a finance/trading environment and we had GPS clock receivers in our datacenters that synced from satellites. While they weren't that expensive I would imagine at Google's scale they would might be. Is there a reason Google wouldn't have used this same technique if it achieves the same accuracy?
- scottlamb 7y agoiirc, one big reason is leap second handling. The closed-source GPS receivers' firmware tend to behave strangely around leap seconds, in a way that contradicts their documentation. And their behavior is untestable in advance: a global satellite network for time synchronization is the ultimate un-mockable time bomb input.
- bogomipz 7y agoThanks but isn't that a reason to forgo using GPS receivers? Google obviously decided to use them however.
- scottlamb 7y agoOh, sorry. I was distracted and misread your comment. I was trying to answer the question of "why an atomic clock rather than a GPS receiver" (and Google's "Armageddon masters" have their own atomic clocks), but I see now you were asking "why not use Cockroach's technique rather than any specialized hardware". I think one answer is in this blog post: > A simple statement of the contrast between Spanner and CockroachDB would be: Spanner always waits on writes for a short interval, whereas CockroachDB sometimes waits on reads for a longer interval. How long is that interval? Well it depends on how clocks on CockroachDB nodes are being synchronized. Using NTP, it’s likely to be up to 250ms. Not great, but the kind of transaction that would restart for the full interval would have to read constantly updated values across many nodes. In practice, these kinds of use cases exist but are the exception.
- bogomipz 7y agoThanks for the clarification, somehow I missed this tradeoff summary. Cheers.