On 2022-04-14, Stefan Sperling <[email protected]> wrote: > On Thu, Apr 14, 2022 at 09:26:41PM -0000, Stuart Henderson wrote: >> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and >> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope >> with it. From boot: >> >> 2022-04-14T13:58:19.844Z ntpd[26996]: adjusting local clock by 1.745061s >> 2022-04-14T13:59:24.070Z ntpd[26996]: adjusting local clock by 1.504470s >> 2022-04-14T14:03:51.176Z ntpd[26996]: adjusting local clock by 2.430486s >> 2022-04-14T14:07:40.299Z ntpd[26996]: adjusting local clock by 2.411118s >> 2022-04-14T14:11:51.540Z ntpd[26996]: adjusting local clock by 3.173884s >> 2022-04-14T14:15:03.534Z ntpd[26996]: adjusting local clock by 3.109722s >> 2022-04-14T14:16:04.848Z ntpd[26996]: adjusting local clock by 3.185755s >> 2022-04-14T14:17:40.286Z ntpd[26996]: adjusting local clock by 3.575126s >> 2022-04-14T14:18:45.582Z ntpd[26996]: adjusting local clock by 4.231518s >> 2022-04-14T14:22:27.618Z ntpd[26996]: adjusting local clock by 4.231999s >> 2022-04-14T14:25:41.618Z ntpd[26996]: adjusting local clock by 4.844904s >> 2022-04-14T14:29:58.888Z ntpd[26996]: adjusting local clock by 4.451876s >> 2022-04-14T14:32:41.628Z ntpd[26996]: adjusting local clock by 5.250357s >> >> etc. No difference whether qemu-ga is used or not. No difference between >> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case) >> and passing through as "common KVM processor". The guest does detect and >> use pvclock(4). >> >> $ sysctl kern.timecounter >> kern.timecounter.tick=1 >> kern.timecounter.timestepwarnings=0 >> kern.timecounter.hardware=pvclock0 >> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) >> acpitimer0(1000) >> >> Anyone have ideas of things I could try that are less wrong than >> running rdate from cron? Thanks. > > I have a -current built-a-week-ago guest on stock Debian KVM, no problems > with time-keeping. It picks acpihpet as timecounter instead of pvclock: > > $ sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=acpihpet0 > kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) > acpitimer0(1000)
Interesting - I would have expected the opposite. I've changed mine to acpihpet0 and it seems much happier. Your value of 500 indicates that the PVCLOCK_TSC_STABLE flag wasn't set by the host, I guess that's dependent on host cpu features. Summarising other responses: - Q35 vs i440FX emulated hw setting: no difference - AMD EPYC performance tuning guide: cpu load is pretty low, I think this is unlikely to be relevant - kvm_intel/parameters/preemption_timer: seems Intel-only and reports are that it's not needed for newer KVM
