5 ms·

Can any wise person comment on the potential impact of this on distributed systems? If they were cheap enough to pop in a server.

ahelwer 12y ago
Google already uses atomic clocks in Spanner, if that's what you're thinking of.
ISL 12y ago
In the near term, not much. I think Spanner is using GPS synchronized Rubidium clocks, which form an excellent combination. If you want to do much, much better (these new optical clocks are sensitive to the change in gravitational potential of centimeters), you'd need one of these. The primary utility of these clocks in the near term is improved precision physical tests. In the long run, they may form better standards to replace Cesium. Another way to see this is that few, if any, industrial users have their own Cesium or Cesium-competitive optical clocks, which are a factor 1000-ish worse than these new clocks.
- darkmighty 12y ago
  A neat thing about those seems that you shouldn't even need persistent GPS to keep them synched. \for most applications an once-in-a-lifetime sync should be enough.
burke 12y ago
You still wouldn't be able to trust them. Google's Spanner goes really far down this line of reasoning. Read the paper; it's great. Basically, highly-precise clocks in a machine-local context would substantially reduce drift, but you can still never really synchronize two clocks reliably across a network (potentially asynchronous send and receive times make it basically impossible) Maybe there's some literature on this I haven't read, but I don't think it would eliminate the kind of work you currently have to do to solve this problem (ie. what Spanner has done), though it would certainly narrow the bars on their TrueTime values quite a bit.
- darkmighty 12y ago
  I think a very basic reason it shouldn't be possible is that for really accurate sync each device has an unkown bias (innacuracy) besides just high std dev (imprecision) with relation to it's network/processing behavior. If you average out a lot of samples you can get rid of all imprecision (albeit very slowly), but you essentially need a very accurate clock to find the bias, so it makes the whole network approach useless. I would guess you couldn't even solve for bias with a clock once and then keep using the network, because the bias should be time-varying.
- fmstephe 12y ago
  I was really thinking that the lack of drift in these clocks means we don't need to periodically sync them. If they are synced initially, without a network, we can rely on them indefinitely.

ahelwer 12y ago

Google already uses atomic clocks in Spanner, if that's what you're thinking of.

ISL 12y ago

In the near term, not much. I think Spanner is using GPS synchronized Rubidium clocks, which form an excellent combination. If you want to do much, much better (these new optical clocks are sensitive to the change in gravitational potential of centimeters), you'd need one of these. The primary utility of these clocks in the near term is improved precision physical tests. In the long run, they may form better standards to replace Cesium. Another way to see this is that few, if any, industrial users have their own Cesium or Cesium-competitive optical clocks, which are a factor 1000-ish worse than these new clocks.

darkmighty 12y ago
A neat thing about those seems that you shouldn't even need persistent GPS to keep them synched. \for most applications an once-in-a-lifetime sync should be enough.

burke 12y ago

You still wouldn't be able to trust them. Google's Spanner goes really far down this line of reasoning. Read the paper; it's great. Basically, highly-precise clocks in a machine-local context would substantially reduce drift, but you can still never really synchronize two clocks reliably across a network (potentially asynchronous send and receive times make it basically impossible) Maybe there's some literature on this I haven't read, but I don't think it would eliminate the kind of work you currently have to do to solve this problem (ie. what Spanner has done), though it would certainly narrow the bars on their TrueTime values quite a bit.

darkmighty 12y ago
I think a very basic reason it shouldn't be possible is that for really accurate sync each device has an unkown bias (innacuracy) besides just high std dev (imprecision) with relation to it's network/processing behavior. If you average out a lot of samples you can get rid of all imprecision (albeit very slowly), but you essentially need a very accurate clock to find the bias, so it makes the whole network approach useless. I would guess you couldn't even solve for bias with a clock once and then keep using the network, because the bias should be time-varying.
fmstephe 12y ago
I was really thinking that the lack of drift in these clocks means we don't need to periodically sync them. If they are synced initially, without a network, we can rely on them indefinitely.