Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

On 2022-04-14, Stefan Sperling <stsp@stsp.name> 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