Hello all, On 12.09.22 15:00, Matthias Petermann wrote:
CONCLUSION- Due to the root cause (well explained in [1]) the clocks in the VMs are potentially running slow.- The root cause can be mitigated by a higher HZ in the host kernel compared to the guest kernel.- ntpd can be configured to cope well with the deviations that remain, so that installation of 3rd party software (chrony) is not necessarily required.- The clocks run to the second with the described ntpd configuration- With chrony I had initially obtained a similarly good result, but then preferred to get by with the means of the base system (which is why I gave ntpd another try)
It remains exciting... the joy about the stable clock in the VMs didn't last long this time, too, unfortunately. Today I ran a backup again for the first time since the clock has been stable. For this I basically run a "zfs send | nc" on the host.
While this process is running, the clocks of the VMs continuously start to slow down again. The rate of change is so variable that ntpd seems to suspend stepping, now for two hours.
With renice I have now adjusted the priority of the processes: - "zfs send" + "nc": +20 - qemu VM processes: -20Furthermore I changed the scheduler algorithm for the qemu processes to SCHED_FIFO with schedctl (in the manpage this mode is associated with real time - I thought this can't be wrong for my problem ;-))
This seems to have stabilized the situation, stepping resumes and despite running backup the clocks are accurate. In the iostat running on the host, I can see about 15% less bandwidth in terms of I/O throughput which is fine for me.
Now, however, I have violated the principles of experimental theory by changing two parameters at once. Until I have the opportunity to repeat the experiment - does anyone have a guess which of the two changes might be decisive?
Kind regards Matthias
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature