4 ms·

I feel like this deserves a deep dive of its own. Were the clocks drifting substantially over a reasonable time period between syncs (e.g. 24 hours)? Was SNTP n

I feel like this deserves a deep dive of its own. Were the clocks drifting substantially over a reasonable time period between syncs (e.g. 24 hours)? Was SNTP not acting reliably? Did they try hosting a local time server?

01HNNWZ0MV43FF 2y ago
I was on an IoT project once and surprised to find that when blocked from ntp, PC clocks drift pretty quick. A couple milliseconds per day would not surprise me. It looked to me like the fleet did consistently fall behind, which seems like thoughtful design - syncing would always cause them to skip ahead and never rewind time
- Someone 2y ago
  > It looked to me like the fleet did consistently fall behind, which seems like thoughtful design Thoughtful, but I think it isn’t necessary with ‘modern' NTP algorithms. They lose time by slowing down a clock derived from their hardware clock for a while, not by moving the hardware time back (https://serverfault.com/a/94691 https://serverfault.com/a/94691, https://community.hpe.com/t5/operating-system-hp-ux/ntp-atomic-clock-time-going-backwards/m-p/2717879/highlight/true#M62287 https://community.hpe.com/t5/operating-system-hp-ux/ntp-atom...)
- crote 2y ago
  Accurate timekeeping is hard. Computers generally don't need long-term clock stability, so nobody is going to invest a lot of money into it. Why bother putting expensive timekeeping hardware in a machine to avoid clock drift when you can also just sync from ntp once a day? If anything, I'd consider "milliseconds per day" to be extremely good. Regular crystal oscillators have an error of 20 PPM or so, which means a worst-case drift of ~2 seconds per day.
varun_ch 2y ago
Did not get the chance to try much at! We just observed that clocks could be synchronized, but the next time we checked they would no longer be. I agree that this is definitely something that could also be interesting to look into in the future.
- simondotau 2y ago
  Was the sync issue observed before or after replacing ChromeOS with a raw Linux distro? I believe ChromeOS has a number of issues with time sync.

01HNNWZ0MV43FF 2y ago

I was on an IoT project once and surprised to find that when blocked from ntp, PC clocks drift pretty quick. A couple milliseconds per day would not surprise me. It looked to me like the fleet did consistently fall behind, which seems like thoughtful design - syncing would always cause them to skip ahead and never rewind time

Someone 2y ago
> It looked to me like the fleet did consistently fall behind, which seems like thoughtful design Thoughtful, but I think it isn’t necessary with ‘modern' NTP algorithms. They lose time by slowing down a clock derived from their hardware clock for a while, not by moving the hardware time back (https://serverfault.com/a/94691 https://serverfault.com/a/94691, https://community.hpe.com/t5/operating-system-hp-ux/ntp-atomic-clock-time-going-backwards/m-p/2717879/highlight/true#M62287 https://community.hpe.com/t5/operating-system-hp-ux/ntp-atom...)
crote 2y ago
Accurate timekeeping is hard. Computers generally don't need long-term clock stability, so nobody is going to invest a lot of money into it. Why bother putting expensive timekeeping hardware in a machine to avoid clock drift when you can also just sync from ntp once a day? If anything, I'd consider "milliseconds per day" to be extremely good. Regular crystal oscillators have an error of 20 PPM or so, which means a worst-case drift of ~2 seconds per day.

varun_ch 2y ago

Did not get the chance to try much at! We just observed that clocks could be synchronized, but the next time we checked they would no longer be. I agree that this is definitely something that could also be interesting to look into in the future.

simondotau 2y ago
Was the sync issue observed before or after replacing ChromeOS with a raw Linux distro? I believe ChromeOS has a number of issues with time sync.