4 ms·
iirc, 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
by scottlamb 7y ago
iirc, 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.