3 ms·

Why not just synchronize to GPS time? It is pretty straightforward to get hardware timestamp on the 1PPS from the GPS. And then your time is as precise as the

Why not just synchronize to GPS time? It is pretty straightforward to get hardware timestamp on the 1PPS from the GPS. And then your time is as precise as the GPS clock, which can have a rubidium standard.

mcshicks 5y ago
I wonder the exact same thing. I worked on CDMA infrastructure in the 90s and that's exactly how we did it.
netizen-936824 5y ago
How long would it take for the sync operation with communication latency? How reliable is the method (how robust)?
wmf 5y ago
Then you need a GPS receiver in each server and a bunch of amps and cables to distribute the signal to every receiver.
- KennyBlanken 5y ago
  1PPS signal distribution is not a complex or remotely difficult problem.
  - dan-robertson 5y ago
    For some reason companies that care a lot about clock sync don’t seem to do this so perhaps there is some other reason.
    - dchichkov 5y ago
      A local GPS-disciplined NTP server, distributing time over 1GbE or 10GbE goes a long way. I can't think of any application, besides HFT and maybe some science experiments that need better precision. And even in HFT, it is silly to try to use your x64 system time to get nanosecond precision. Even if you are really good, using bare hardware, all your code and data is in L2, an x64 system would still be giving you 100ns level jitter. No matter what you do. What you want is to have your network card (or FPGA) timestamping the packets accurately. And then releasing these packets at a precise timestamp. Saying that, maybe Clockwork is doing something completely different. And not in nanosecond level, but at a millisecond level. They talk about "measure true one-way delays of a packet or remote procedure call, discover network bottlenecks and "hiccups" (outages lasting a few seconds), and identify underperforming VMs arising from "noisy neighbors." Now, that could indeed be useful.
gpderetta 5y ago
This is routinely done in some industries like finance.

mcshicks 5y ago

I wonder the exact same thing. I worked on CDMA infrastructure in the 90s and that's exactly how we did it.

netizen-936824 5y ago

How long would it take for the sync operation with communication latency? How reliable is the method (how robust)?

wmf 5y ago

Then you need a GPS receiver in each server and a bunch of amps and cables to distribute the signal to every receiver.

KennyBlanken 5y ago
1PPS signal distribution is not a complex or remotely difficult problem.
- dan-robertson 5y ago
  For some reason companies that care a lot about clock sync don’t seem to do this so perhaps there is some other reason.
  - dchichkov 5y ago
    A local GPS-disciplined NTP server, distributing time over 1GbE or 10GbE goes a long way. I can't think of any application, besides HFT and maybe some science experiments that need better precision. And even in HFT, it is silly to try to use your x64 system time to get nanosecond precision. Even if you are really good, using bare hardware, all your code and data is in L2, an x64 system would still be giving you 100ns level jitter. No matter what you do. What you want is to have your network card (or FPGA) timestamping the packets accurately. And then releasing these packets at a precise timestamp. Saying that, maybe Clockwork is doing something completely different. And not in nanosecond level, but at a millisecond level. They talk about "measure true one-way delays of a packet or remote procedure call, discover network bottlenecks and "hiccups" (outages lasting a few seconds), and identify underperforming VMs arising from "noisy neighbors." Now, that could indeed be useful.

gpderetta 5y ago

This is routinely done in some industries like finance.