4 ms·
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
by 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 agoAccurate 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.