Hi Ian, All!

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 suppose the answer is "yes", the patch helped. Here are two samples
(host for bhyve VM without your patch and after patching):

The command was:
% for t in `jot 1000`; do ntpq -pn; sleep 64; done

The patch made the system to stabilize the process.
Ian, thank you!

WBR, bsam
freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to