“I don’t know who’s doing it yet, but I’d bet datacenters in the future will offer dedicated HW interfaces for bounded-accuracy time.”
That’s funny because it was my exact proposal to deal with Google’s problems. Idea was an ultra-reliable, battery-powered ASIC that basically kept time that it synchronized to microseconds or whatever with an atomic clock. You plug it into a master clock to synchronize it. You plug it into a system to synchronize that. They can synchronize each other, too. Maybe.
Anyway, you have someone take one of these to atomic clock for master time. Then, you take it to each of your data centers to plug into their time servers or appliances. Those sync up the servers. There’s already ultra-low, latency, NTP products offered for HFT and such. If that’s not feasible, you plug them into the DB servers themselves. Once they’re all synced, the Spanner, write window can close downward from the 30 seconds or so it’s currently at to seconds or milliseconds. Periodically resync them.
Note: This job is also so boring and easy with enough spare time for FOSS coding that I’d consider applying. Especially at the standard, pay rate at Google. (toothy grin)
Note 2: I haven’t elaborated too much in public because I’m pretty sure someone will patent a vague copy of it then slam whoever builds it. If they haven’t already. In any case, the hardware issues would be countered a bit by using old, process nodes with less reliability issues. Silicon-on-Insulator for less interferences by external stuff. TMR inside of the circuit with rad-hard gates. Can use a few of the device manufactured in different batches send by different routes if one wants. I’d be shocked if such a device failed.
Google already does this with GPS and atomic clocks in their data centers; what’s the benefit of having it be a mobile device? That it’s coming from a single source rather than a broadcast signal?
Yes. That’s what I have in mind as a non-expert on managing time or distributed signals. ;) I recall reading their delay was about how things could skew with the multiple sources and destinations involved. One source they all sync to with no latency might eliminate much of that. I’m working at too high a level to be sure but it’s already a thing in HFT with special, NTP servers. I think a pluggable board with high-speed I/O as connector might have similar benefits.
I feel like the GPS/atomic clock combos they have are probably already aware of those problems, but for people with multiple geographically dispersed data centers and no Google-level time infrastructure, shipping a small device back and forth could probably get pretty close to what they have for sure.
“I don’t know who’s doing it yet, but I’d bet datacenters in the future will offer dedicated HW interfaces for bounded-accuracy time.”
That’s funny because it was my exact proposal to deal with Google’s problems. Idea was an ultra-reliable, battery-powered ASIC that basically kept time that it synchronized to microseconds or whatever with an atomic clock. You plug it into a master clock to synchronize it. You plug it into a system to synchronize that. They can synchronize each other, too. Maybe.
Anyway, you have someone take one of these to atomic clock for master time. Then, you take it to each of your data centers to plug into their time servers or appliances. Those sync up the servers. There’s already ultra-low, latency, NTP products offered for HFT and such. If that’s not feasible, you plug them into the DB servers themselves. Once they’re all synced, the Spanner, write window can close downward from the 30 seconds or so it’s currently at to seconds or milliseconds. Periodically resync them.
Note: This job is also so boring and easy with enough spare time for FOSS coding that I’d consider applying. Especially at the standard, pay rate at Google. (toothy grin)
Note 2: I haven’t elaborated too much in public because I’m pretty sure someone will patent a vague copy of it then slam whoever builds it. If they haven’t already. In any case, the hardware issues would be countered a bit by using old, process nodes with less reliability issues. Silicon-on-Insulator for less interferences by external stuff. TMR inside of the circuit with rad-hard gates. Can use a few of the device manufactured in different batches send by different routes if one wants. I’d be shocked if such a device failed.
Google already does this with GPS and atomic clocks in their data centers; what’s the benefit of having it be a mobile device? That it’s coming from a single source rather than a broadcast signal?
Yes. That’s what I have in mind as a non-expert on managing time or distributed signals. ;) I recall reading their delay was about how things could skew with the multiple sources and destinations involved. One source they all sync to with no latency might eliminate much of that. I’m working at too high a level to be sure but it’s already a thing in HFT with special, NTP servers. I think a pluggable board with high-speed I/O as connector might have similar benefits.
I feel like the GPS/atomic clock combos they have are probably already aware of those problems, but for people with multiple geographically dispersed data centers and no Google-level time infrastructure, shipping a small device back and forth could probably get pretty close to what they have for sure.