On Mon, Dec 18, 2023 at 02:02:47AM +0000, Chris Narkiewicz wrote:
> I'm running OpenBSD 7.4 in qemu VM on my laptop. After hibernation,
> vm clock is delayed.
>
> ntpd works in background, but it fails to adjust the clock:
>
> reply from 162.159.200.1: offset 0.005599 delay 0.013842, next query 32s
> reply from 139.162.219.252: offset 0.007199 delay 0.011274, next query 30s
> reply from 162.159.200.123: offset 0.007154 delay 0.010765, next query 31s
> reply from 131.111.8.61: offset 0.007642 delay 0.016057, next query 30s
> adjusting local clock by 4686.953122s
> (...)
> reply from 83.151.207.133: offset 0.011828 delay 0.014193, next query 33s
> reply from 139.162.219.252: offset 0.009902 delay 0.011271, next query 32s
> reply from 131.111.8.61: offset 0.010350 delay 0.015616, next query 33s
> adjusting local clock by 4686.164970s
> reply from 162.159.200.1: offset 0.013156 delay 0.011764, next query 34s
> reply from 131.111.8.61: offset 0.013905 delay 0.017363, next query 30s
> adjusting local clock by 4686.001301s
>
> However, the lock does not budge at all. I can still manually set
> the clock by date -s HHMM.
>
> Not sure how to debug it. Is it because I'm using vm and it doesn't
> support?
>
> diso# dmesg | grep pvclock
> pvclock0 at pvbus0
>
> Best regards,
> Chris Narkiewicz
>
The offset is first 4686.953122s and a bit later 4686.001301s. So ntpd
works, the offset gets smaller. ntpd *only* moves the clocks in one go
(setting) on boot. After that, it adjusts the clock by making it tick
a bit slower of faster. That takes time.
Dunno why the clock is wrong after hibernation though, that's a
different issue.
-Otto
