Hacker News Reader

Comment by greggman25 | Hacker News Reader

I worked at Google when Chromebook shipped. They put out a call for decorations for the lobby and I proposed something similar to this but they said "no" :( Maybe because I asked for 40-64 machines :P

I would not have tried to sync video though. Instead I'd have made time based animations and use the network the synchronize the clocks.

you can see an example here: https://www.youtube.com/watch?v=64TcBiqmVko

It's 8 machines running Chrome. The only thing synchronized are the settings and the time.

They machines do not have to be in a grid either. I was inspired by the Boston Science Museum's virtual aquarium

View on HN

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.

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.

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...

If you have fixed media (as opposed to realtime dynamically generated or streamed etc) this trick can go a very long way - or even if it is generative, if the time is used to drive the animation. It just requires good clock sync, like you said, which can be non trivial (especially if audio is involved where desync of even 20-30ms becomes very noticeable). But yeah, with NTP/PTP you can get v v far.

Reply on news.ycombinator.com