Port-xen archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ntpd looses sync on domU
Emmanuel Dreyfus <manu%netbsd.org@localhost> writes:
> Hello
>
> The setup is Xen 4.1.8 (xenkernel418-20240909nb1 from pkgsrc), with
> NetBSD-10.0/amd64 dom0 and domU.
>
> From time to time, I experience time keeping trouble on a small set
> of domUs. The clock drifts a lot, loosing hours in a few hours. ntpd
> is unable to cope, and the only remeidiation is to reboot the domU.
> Oddly, the dom0 and other domU running on the same dom0 have no clock
> trouble.
>
> I recently discovered that switching kern.timecounter.hardware from
> xen_system_time to clockinterrupt helped a lot. The drift remain
> but is much smaller, and ntpd is able to keep an almost correct time.
> It still reports being unsync, thought.
>
> It seems also running ntpd with -G lets it sync after a while. But
> even when pll nano kernel status is reached, the numbers reported
> by ntpq -c peers show there is something wrong.
>
> - On the time-sick domU
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *ntp1.example.ne 145.238.80.80 2 u 29 64 377 7.812 -18.042 369.214
> +ntp2.example.ne 192.0.2.20 3 u 32 64 377 7.812 +962.94 660.459
>
> - On the dom0:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *ntp1.example.ne 145.238.80.80 2 u 1018 1024 377 0.430 +7.106 6.703
> +ntp2.example.ne 192.0.2.20 3 u 218 1024 377 1.528 +6.619 6.455
>
> - On another domU running on the same dom0:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *ntp1.example.ne 145.238.80.80 2 u 247 256 377 0.405 +3.995 0.931
> +ntp1.example.ne 192.0.2.20 3 u 213 256 377 1.607 +2.156 1.112
>
>
> Anyone already experienced that?
Yes, sometimes when I had used pure PV DOMUs with more than one vcpu.
The in tree ntpd couldn't deal with that in my world, and I ended up
using chronyd from pkgsrc which could manage to keep the guest synced.
When I moved to PVH DOMUs the problem with ntpd for me went away. I
believe that ntpd will stop trying to correct the time if the drift is
more than 500 and chronyd will continue to try up to at least 750 and
deals with oscillators that wobble around a lot (part of the effort
behind chronyd was to deal with moble laptops that come and go from
wireless neworks, or networks in general, and that isn't much different
from a wobbly DOMU guest it seems).
Pure PV DOMUs with one 1 vcpu have never been a problem for me.
--
Brad Spencer - brad%anduin.eldar.org@localhost
Home |
Main Index |
Thread Index |
Old Index