On Sun, 2017-10-22 at 11:31 +0300, Boris Samorodov wrote: > 22.10.2017 01:15, Ian Lepore ÐÉÛÅÔ: > > > > On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote: > > > > > > Ian Lepore writes: > > > > > > > > > > > > Beyond that, I'm not sure what else to try. šIt might be necessary to > > > > get some bhyve developers involved (I know almost nothing about it). > > > NTPD behaves more normally on uniprocessor VMs. > > > > > > A FreeBSD bhyve-guest running on a freebsd host will select a > > > different timecounter depending on whether it is a multiprocessor or a > > > uniprocessor.ššMy uniprocessor bhyve-vm selected TSC-low as the best > > > timecounter in a uniprocessor.ššNTP functions there as expected. > > > > > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000) > > > kern.timecounter.hardware: TSC-low > > > > > > The very same VM, when given two total CPUs, selected HPET (if I > > > recall) and the timekeeping with NTPD was unreliable, with many > > > step-resets to the clock. > > > > > Hmm, I just had glance at the code inšsys/amd64/vmm/io/vhpet.c and it > > looks right. šI wonder if this is just a simple roundoff error in > > converting between 10.0MHz and SBT units? šIf so, that could be wished > > away easily by using a power-of-2 frequency for the virtual HPET. šI > > wonder if the attached patch is all that's needed? > I've tried the patch (at bhyve guest) and nothing has changed. Should > the patched system be tested at bhyve guest or bhyve host? > Oh, I'm sorry, I should have mentioned that's for the host side. -- IanReceived on Sun Oct 22 2017 - 14:02:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC