Now that we can set time via ntpquery -s fairly accurately (it's a one-shot adjustment), we can evaluate how well serenity's clock keeps time.

I ran su; ntpquery -s; for i in $(seq 1000) { sleep 1; echo $i; ntpquery } to see how much the clock gains over 1000 seconds, and it gained 3.5s. Then I tried su; ntpquery -s; for i in $(seq 12) { sleep 1800; echo $i; ntpquery } to check every 30 min over 6 hours. At the end of the 6h, the clock was 13s late.

After 20h of uptime, I checked again, by then it was 32.8s late.

Eventually we'll have a long-running NTP service that keeps adjusting the clock, but maybe the OS should be able to keep time better even without an internet connection.

--

I read the timekeeping code a bit, and I think we use the HPETComparator code, which should tick at 1000 Hz even. TimeManagement::epoch_time() assumes 1000Hz exactly instead of using ticks_per_second() but at least for the HPET that's not a source of error. So not sure where exactly we lose time, but I figured I'd file at least a bug for it.