Hello Stuart, What is the EFI / BIOS Power management / CPU power management Performance setting set to ? if the CPU is throttled back (due to low usage) is that affecting the time keeping ? It might be worth trying OS Controlled or Performance (as a test) it may be set to power saving or balanced
I hope this helps, ( and thanks for your patience with my previous impulsive (albeit trying to help) replies earlier Tom Smyth On Fri, 15 Apr 2022 at 11:12, Stuart Henderson <[email protected]> wrote: > > 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 > > -- Kindest regards, Tom Smyth.
