Hafele and Keating Experiment: "During October, 1971, four cesium atomic beam clocks were flown on regularly scheduled commercial jet flights around the world twice, once eastward and once westward, to test Einstein's theory of relativity with macroscopic clocks. From the actual flight paths of each trip, the theory predicted that the flying clocks, compared with reference clocks at the U.S. Naval Observatory, should have lost 40+/-23 nanoseconds during the eastward trip and should have gained 275+/-21 nanoseconds during the westward trip ... Relative to the atomic time scale of the U.S. Naval Observatory, the flying clocks lost 59+/-10 nanoseconds during the eastward trip and gained 273+/-7 nanosecond during the westward trip, where the errors are the corresponding standard deviations. These results provide an unambiguous empirical resolution of the famous clock "paradox" with macroscopic clocks."
So if we are loosing nano seconds per day, couldn't we fly clocks around the datacenters and resync every month. 7ms seems beatable and not a terrible operational overhead for a fast globally consistent database.
I also think satellite clocks have to take time relativity it into account (both due to distance from earth's gravity and their speed).
Randall Munroe has a pretty entertaining write up that does a decent job giving a high level overview in pretty easy to understand terms: http://www.newyorker.com/tech/elements/the-space-doctors-big...
However, someone moving on the satellite would see the clock on the satellite move normally, and us on earth moving in slow motion, because they are on the same frame of reference of the satellite.
So no, time does not operate differently on different parts of the universe per se. It all depends on how it's moving relative to the observer.
It does, but the difference is negligible unless we're talking about the surface of a neutron star.
1) Velocity doesn't affect time, acceleration does. So if your twin flies to Mars and back, you age more quickly. But if your twin flies to Mars, and you join him after a year (following the same trajectory), you age the same. This is special relativity.
2) Acceleration due to gravity doesn't count. In fact, the opposite is true -- by standing on the ground, you are accelerating up at 32 feet per second squared. This is general relativity.
So, to answer your question. On the one hand, yes, if I am accelerating (not counting gravity), then I observe time pass more slowly. On the other hand, most of the universe is dominated by gravitational forces, so most systems wouldn't notice these effects.
The fascinating thing is that both (1) and (2) happen because of a very basic physics principle: if I can't use an experiment to tell two frames of reference apart, then the physics in the two frames of reference are identical.
For (1), I observe the same speed of light as someone moving at velocity v relative to me. Einstein used this simple axiom to derive special relativity. For (2), I can't tell the difference between free fall and being at rest (alternatively, I can't tell the difference between being on Earth and being in an elevator in space). This is because the inertial mass equals gravitational mass, a "coincidence" that dates back to Newton's law of gravitation. From this (and a lot of math) Einstein derived general relativity. Beautiful!
It isn't, GPS + ptp can give slaves on the same lan +/- 700ns very cheaply
This paper is one of the most interesting published in the last couple of years IMO. I remain surprised at how many people have overlooked it. I'm not sure why this blog post makes no mention of the work, in the past the Cockroach folks have been quite explicit about crediting the research documents they're drawing from.
Second, cloudera has a patent on this work: http://www.freepatentsonline.com/y2015/0156262.html
This blog post doesn't mention HLC because the explanation didn't require it. HLC boils down to a mechanism for taking the maximum physical wall time across >= 2 nodes, while still being able to provide monotonically increasing time via incrementing the logical component of the hybrid logical timestamp. In the blog post, this is referred to as "taking the maximum timestamp across requests". A segue into HLC would have served only to further complicate the explanation.
The work done by Sandeep Kulkarni, Murat Demirbas, David Alves, Todd Lipcon, Vijay Garg, and others was instrumental to our early design efforts. I am dismayed to see there's a patent pending, though both our design and open source implementation predate the patent filing.
"This application claims to the benefit of U.S. Provisional Patent Application No. 61/911,720, entitled “HYBRIDTIME and HYBRIDCLOCKS FOR CLOCK UNCERTAINTY REDUCTION IN A DISTRIBUTED COMPUTING ENVIRONMENT”, which was filed on Dec. 4, 2013, which is incorporated by reference herein in its entirety."
(which predates the creation of the cockroachdb repo and the hybrid logical clock paper).
and the source here: https://github.com/apache/incubator-kudu/blob/master/src/kud...
Both are probably more readable than patent-ese :)
You can plug them into each machine in the cluster periodically to sync them. Or you can plug it into a master node that connects with low-latency management interface separate from main data line. Occasionally, time server gets exclusive access to that line, assesses latency, and then syncs its time. Time server might be custom built to avoid its own skew or keep one of the timekeeping devices attached. Those are periodically shipped to a central location to resync themselves against an atomic clock or each other.
What yall think?
Google have a variant on this, where they use a GPS receiver in each data centre to provide an accurate time source for local machines.
Basically by accurate and precise timing, they are able to reconstruct and pinpoint the origin of a failure.
Should do a lot better than 7ms with performance implications.
The spanner paper is unclear how they deal with this, but my guess is that since they have accurately synchronized clocks, you'll never have to block long for that commitment to hold. Spanner also uses pessimistic locking, so for a R/W transaction, you can rely on locking reads to prevent the anomaly.
With cockroachdb, wouldn't this commitment imply that poorly synchronized clocks would lead to poor performance?
Do reads execute through raft? If not, how do you guarantee that behavior - relying on leader leases? If so, does the lease period guarantee disjointness in the timestamps a leader can process, or do you rely on the leader abdicating control via timeout?
Since it can push the write timestamp, does that mean the write transaction aborts if it was in serializable mode? Does that cause problems updating a value that is heavily read?
Passing around the max sequence number as a monotonic sequence indicator has a risk. A bogus sequence number near the max value can cause serious problems.
