Hacker News Reader

Comment by preinheimer | Hacker News Reader

The author tried, but the clocks wouldn’t stay in sync. It’s in a sidenote expandable section.

> Unfortunately, these Chromebooks could not reliably keep track of time within milliseconds of each other, so this method didn't work for us.

View on HN

I don't know if syncing the videos would work because of playback issues over time but the aquarium pages sync their clocks every second just asking the server the time (demo time not wall time) over web-sockets and then subtracting 1/2 of the time it took to get a response. I suspect the technique works better for time based animations than video since video require seeking to change the time.

PTP [1] is a common approach to time sync in these scenarios. It provides sub-microsecond accuracy for when working on a LAN. This is used behind most products, software, and protocol suites in the real-time media space.

[1]: https://networklessons.com/ip-services/introduction-to-preci...

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?

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

> 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://community.hpe.com/t5/operating-system-hp-ux/ntp-atom...)

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.

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.

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.

Reply on news.ycombinator.com