It's <i>really</i> hard to use these API's correctly.<p>Remember... your CPU can halt at any time for any number of milliseconds. That means simple things like:<p><pre><code> upperBound, lowerBound = readTime()
if (upperBound<deadline)
do_stuff(x, y, z)
</code></pre>
Are incorrect... There is no guarantee that the 'if' statement didn't take many milliseconds, and that the stuff didn't end up happening after the deadline.<p>It's also very easy to write code that works, but is theoretically wrong. You will leave a hidden bug that may only rear its head years down the line.
Two observations/questions, the first probably naive:<p>* It's not that hard to get your own "world class" time server, for under a thousand. A Rb standard slaved to a GPSDO is gonna be <i>so</i> accurate <i>and</i> stable, and use that to drive a SBC that supports IEEE1588, where you run your NTP and PTP server. Oh, but I guess that box, while inexpensive, isn't in Amazons DC, so doesn't help you.<p>* PTP's absence in the Amazon Time Sync Service article is quite conspicuous!
Using atomic clocks too, nice. From an older post:<p>> It uses a fleet of redundant satellite-connected and atomic clocks in each Region to deliver time derived from these highly accurate reference clocks.<p><a href="https://aws.amazon.com/blogs/mt/manage-amazon-ec2-instance-clock-accuracy-using-amazon-time-sync-service-and-amazon-cloudwatch-part-1/" rel="nofollow">https://aws.amazon.com/blogs/mt/manage-amazon-ec2-instance-c...</a>
They released it in 2017. [1]<p>Today they released a new OSS daemon and library for it.<p>[1] <a href="https://aws.amazon.com/about-aws/whats-new/2017/11/introducing-the-amazon-time-sync-service/" rel="nofollow">https://aws.amazon.com/about-aws/whats-new/2017/11/introduci...</a>
Back from my time at Amazon, one of my favourite technical videos on the internal educational/YouTube thing was from a service team explaining how hard accurate clock sync in distributed systems was. One of those problems
I’ve just taken for granted over the years. But just layers and layers of complexity where naive assumptions at any point get you the wrong result, but it’s not at all obvious you have the wrong result.<p>I really wish they made more of that stuff publicly available.
Google and GCP offer their own NTP endpoints. Does anyone know if GCP also exposes the TrueTime API to customers, or if it's only internal to Spanner?<p>I can't find any instance of the word "bound" in the GCP or Google NTP docs.<p>[1]: <a href="https://developers.google.com/time/guides#google_compute_engine" rel="nofollow">https://developers.google.com/time/guides#google_compute_eng...</a><p>[2]: <a href="https://cloud.google.com/compute/docs/instances/managing-instances#configure-ntp" rel="nofollow">https://cloud.google.com/compute/docs/instances/managing-ins...</a>
One of the key aspects of the TrueTime system is any device with serious clock error is simply murdered. It seems like offering that would significantly benefit users of this AWS API.
I'm curious about the title on this submission. I thought TrueTime had unusually strong guarantees about accuracy that don't seem to be called out in what I'm reading on the linked article.
Perhaps the biggest "fake-out" in 21st century computing: Google publicly released its MapReduce paper -- directing most of the rest of the industry toward loosely coupled, overly complex distributed data processing systems like Hadoop for the following decade -- but internally they just bought a bunch of atomic clocks and built a distributed RDBMS.<p>I know this is a somewhat simplified story, but it does make me chuckle.