On 2022/04/15 22:02, Tom Smyth wrote:
> 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
Thanks for the suggestions - since the change I made in the last mail
("I've changed mine to acpihpet0 and it seems much happier", i.e. setting
the kern.timecounter.hardware sysctl to acpihpet0, based on Stefan's
pointer) the time has stayed in sync.
The machine is on what looks like the closest thing to "power saving"
(option in machine config is "best experience") - since I leave this
machine turned on, at around 0.30GBP/kWh power cost, and often with
only ~50% of power generation where I live being low carbon unless
it's particularly windy (https://www.carbonintensity.org.uk/#regional,
https://www.gridwatch.templar.co.uk/) I'd like to keep it like that
if possible :)
> 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.
