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): --- https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.10000000.txt https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.16777216.txt --- 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, bsamReceived on Tue Oct 24 2017 - 19:44:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC