Re: host, bhyve vm and ntpd

22.10.2017 18:22, Rodney W. Grimes пишет:
> [ Charset UTF-8 unsupported, converting... ]
>> 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?
> 
> I believe the suggested patch would have to be made to the bhyve
> host

OK, I'd do it tomorrow and report back.

>.  Also on the host and guest what are the values of
> 	sysctl kern.timecounter.tc.HPET
> 	sysctl kern.timecounter.tc.i8254

Here they are:
---
bhyve-host% sysctl kern.timecounter.tc.HPET
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 2138094157
kern.timecounter.tc.HPET.mask: 4294967295

bhyve-host% sysctl kern.timecounter.tc.i8254
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 54883
kern.timecounter.tc.i8254.mask: 65535
---
bhyve-guest% sysctl kern.timecounter.tc.HPET
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 10000000
kern.timecounter.tc.HPET.counter: 969429421
kern.timecounter.tc.HPET.mask: 4294967295

bhyve-guest% sysctl kern.timecounter.tc.i8254
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 39893
kern.timecounter.tc.i8254.mask: 65535
---

> Getting good ntpd behavior in a VM guest of any kind is sometimes a
> non trivial thing to do.

As a side note, I have a CentOS-7 bhyve VM at the same host.
And it was enough to run chronyd with default config. Which stepped
twice and is stable (no messages) for several days, current log:
---
Oct 19 16:01:03 c.vpn systemd[1]: Starting NTP client/server...
Oct 19 16:01:03 c.vpn chronyd[27043]: chronyd version 3.1 starting
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND
+ASYNCDNS +IPV6 +DEBUG)
Oct 19 16:01:03 c.vpn chronyd[27043]: Frequency 0.000 +/- 1000000.000
ppm read from /var/lib/chrony/drift
Oct 19 16:01:03 c.vpn systemd[1]: Started NTP client/server.
Oct 19 16:01:07 c.vpn chronyd[27043]: Selected source XX.XX.XX.1
Oct 19 16:01:07 c.vpn chronyd[27043]: System clock wrong by -44.392782
seconds, adjustment started
Oct 19 16:00:23 c.vpn chronyd[27043]: System clock was stepped by
-44.392782 seconds
Oct 19 16:00:34 c.vpn chronyd[27043]: System clock was stepped by
0.000001 seconds
---

-- 
WBR, bsam