Comment by elfchief | Hacker News Reader

Comment by elfchief | Hacker News Reader

Parent Full thread

The problem with atomic clocks in general is that they have very good short term stability, but not-so-great long-term stability. So they are very good at measuring the amount of time that has passed between two events, but not as great for telling you exactly what time an event happened.

The other problem is that there's not really such thing as a single, true time. Precision timekeeping is one of those places where relativity matters -- differences in altitude and the geology of the earth under your feet at a particular point change how fast any particular clock 'ticks'.

So to accommodate these differences, if you want events to be synchronized across multiple locations over a long period, you both need a single agreed-upon "current time", and some way to get information about that time information to the sites that need it.

You could surely do this with directly connected wires that were very carefully measured, but that gets expensive very quickly. The GPS system already requires super-precise time just to function, so it makes for a great distribution mechanism of "what time is it" information, where the people running the GPS system are bothered with all the details of figuring out and standardizing a single time, and you 'just' have to listen.

The GPS folks also keep track of things like how fast the GPS standard clock is drifting from the UTC standard clock (since no two clocks will agree over the long term, period). And this is actually where the problem happened -- Two of the parameters broadcast (A0 and A1) were incorrect, and it's these parameters that are used to specify the current time difference between the GPS master clock and the UTC master clock (the GPS master clock is disciplined to be as close to UTC as possible, but is always off by a minute amount, and that's what A0/A1 represent).

Pretty much it boils down to, much as it is in distributed systems, "there is no now". Even with maximum care and the highest quality clocks, there's really not a definition of 'now' that's consistent across more than a single location. GPS is currently the closest thing we have to a globally-distributed definition of 'now'.

Yep and "simultaneous" is not simple either as Einstein figured out in 1905: "So we see that we cannot attach any absolute signification to the concept of simultaneity, but that two events which, viewed from a system of co-ordinates, are simultaneous, can no longer be looked upon as simultaneous events when envisaged from a system which is in motion relatively to that system."

https://www.fourmilab.ch/etexts/einstein/specrel/www/

    > atomic clocks in general is that they have very good
    > short term stability, but not-so-great long-term
    > stability

Well... The normal number to look at is the "Allan Variance". Over a timescale of days (100'000 seconds) a good rubidium will achieve about 10^-12, which is 10ns. A hydrogen maser will have 10^-13 or 10^-14 over even longer timescales. This is pretty great long-term stability in my book. A good, but undisciplined, quartz oscillator will have 10^-12 over timescales of hours.

http://ivs.nict.go.jp/mirror/publications/gm2002/takahei/img... http://www.ke5fx.com/rb.htm http://www.thinksrs.com/assets/instr/PRS10/PRS10diag2LG.gif

By definition, anything steered by GPS will have infinite precision for infinitely long time-scales, as GPS time and UTC time ultimately are steered such that they are within a certain tolerance of each other.

http://www.leapsecond.com/pages/tbolt-tc/

And UTC time is the pretty elaborate average of ensembles of atomic clocks, hence atomic clocks produce the international reference time there is.

You can, of course, improve the long-term stability of any clock by locking it to a GPS (or other means of time-signal distribution). And for a good Caseium that might only require you to look at the phase, and slightly nudge a potentiometer (magnetic correction field adjustment) on the front by a tiny amount every week. But atomic clocks in general are pretty darn impressive.

UPDATE: This presentaiton has all the interesting plots combined, it seems: http://www.hipster.net/ShadNygren_Atomic_Clocks_for_Amateur_... (pages 45 and following).

Nice presentation! Thanks for the link!

The particular nit you pick here is a fair one, if you take my comment literally, rather than as the (over?)simplification of a complex concept I was trying to summarize.

Yes, in absolute terms, an atomic clock will have excellent stability over the long term in its own frame of reference. As long as you don't need your atomic clock to match any other clock in the universe, the long-term stability is excellent.

The particular topic being discussed here, though, is equipment that is designed to synchronize events across a large area. Even atomic clocks that are literally 100% accurate will diverge if installed in different locations. So if you want your atomic clock to actually be able to tell you what time it is (in a way that matches up closely with anyone else), you have to constantly be adjusting it to match a common standard (e.g. UTC)

These adjustments are a form of instability, since to correct for changes, you have to make your seconds either faster or slower than they actually are locally, on a constantly-changing basis, or you have to step your time and have less (or more) than (Y - X) time actually elapse between timestamps X and Y.

As soon as you move beyond a single frame of reference, you can't have both short and long term stability.

I suppose I could have used a different word than 'stability', but that seemed to get across the underlying effect best. I suppose another way of saying it (that is more correct) is that atomic clocks are great for telling you how much time has passed (in your local reference frame), but not so great for telling you what time it is. GPS is great for telling you what time it is, but not so great for telling you how much time has passed (in your local reference frame).

(The best clocks for timekeeping, of course, are atomic clocks disciplined by a common reference like GPS, which gives you the option of deciding your own long term vs. short term tradeoff however you'd like. But the original question was "why do we need GPS at all, and not just atomic clocks?".)

Google is also working on a globally distributed `now': http://research.google.com/archive/spanner.html

Of course, they make use of GPS, but also add their own atomic clocks.

Even Google's "now" is still a little fuzzy -- their system doesn't so much define "now" as it defines the uncertainty around "now", which you can take advantage of for figuring out ordering. This paragraph (from section 1 of their paper) summarizes it pretty well:

> The key enabler of these properties is a new TrueTime > API and its implementation. The API directly exposes > clock uncertainty, and the guarantees on Spanner’s timestamps > depend on the bounds that the implementation provides. > If the uncertainty is large, Spanner slows down to > wait out that uncertainty.

...so really, GPS and atomic clocks aren't for defining "now" they're for providing a keeping the window of uncertainty around "now" to a small value. The value mentioned in the paper for this is "generally less than 10ms", which is pretty good for a large-scale distributed system, but massive in terms of precision timekeeping. It is, after all, an uncertainty that's three orders of magnitude larger than the GPS glitch that started this discussion...

Reply on news.ycombinator.com