host, bhyve vm and ntpd

[Ian Lepore]

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.

-- Ian