3 ms·
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
by 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 agoI 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 agoI 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.