Date: Tue, 10 Mar 2020 20:57:40 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Theron <theron.tarigo@gmail.com> Cc: Peter Jeremy <peter@rulingia.com>, FreeBSD Current <freebsd-current@freebsd.org>, neel@neelc.org Subject: Re: System clock is slow Message-ID: <20200310185740.GA1992@kib.kiev.ua> In-Reply-To: <a2603db8-f3e9-fa9d-b2cf-a80e55dc926e@gmail.com> References: <989cd36a-e015-940a-dfe2-851c6fdf4734@gmail.com> <20200310053833.GD3091@server.rulingia.com> <a2603db8-f3e9-fa9d-b2cf-a80e55dc926e@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 10, 2020 at 12:24:24PM -0400, Theron wrote: > On 2020-03-10 01:38, Peter Jeremy wrote: > > Are you running NTP? If so, is NTP maintaining lock and what is the > > reported PLL frequency (ntpq -c kerni)? > > Didn't show any useful difference, "kernel status: pll unsync" when I tested > this. > > > What does "sysctl kern.timecounter" report and have you tried using > > any of the alternative timecounters listed in kern.timecounter.choice? > > Indeed that reveals the problem: > kern.timecounter.hardware: TSC-low > (before regression) > kern.timecounter.tc.TSC-low.frequency: 1296053807 > (after regression) > kern.timecounter.tc.TSC-low.frequency: 1300000000 > > (why are these tsc_freq divided by two?) Because it is TSC-low, not TSC timecounter. > > Through some printf's in tsc.c I've determined that the 2.6e9 value is from > 0x16 CPUID which Intel says is only a nominal value not to be used, whereas > 2.592e9 value is from calibration. > > /* > * Calculate TSC frequency using information from the CPUID leaf 0x15 > * 'Time Stamp Counter and Nominal Core Crystal Clock'. If leaf 0x15 > * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor > * Frequency Information'. Leaf 0x16 is described in the SDM as > * informational only, but if 0x15 did not work, and TSC calibration > * is disabled, it is the best we can get at all. It should still be > * an improvement over the parsing of the CPU model name in > * tsc_freq_intel(), when available. > */ > > The implementation logic for when to use tsc_freq_cpuid() looks wrong to me; > it doesn't match what this comment implies. Fallback to calibration when > calibration is unspecified should proceed when 0x15 fails regardless of what > 0x16 does. (CC'd the authors). Problem is that there are enough machines in wild that do not have ISA clock in chipset, or BIOS did not bothered configuring the chipset to make 8254 emulation operational. Worse, the supposedly intended way for BIOS to report the absense of the PC AT hardware through the FADT legacy devices flag is broken on every machine I looked at. The result of calibration on machine without ISA timer makes the machine unusable at all. The removal of 8254 emulation coincides with addition of the 0x15/0x16 CPUID leafs, so our choice is to do the configuration based on the widest possible compatibility. I was told that fallback to 0x16 is also used by Linux. You can set machdep.disable_tsc_calibration tunable to 0 to force calibration if it works for you. > > Switching to HPET or ACPI-fast gives the expected results. Would there be > any reason to not use HPET provided I can cope with the performance > implications? > The name of the ACPI option varies haphazardly between "ACPI-fast" and > "ACPI-safe" between reboots, I guess it is sensitive to some buggy vendor > firmware. Use HPET if you want, again by manual enable. BTW, please install sysutils/x86info and provide the output of x86info -r > > > Are you overclocking your CPU (or doing anything else non-standard)? > > I had previously used powerd to let the CPU underclock to 700MHz when idle. > Now, I've lost all control over CPU frequency (either by powerd or by > sysctl) since there is some in-kernel cpufreq driver which I can't figure > out how to disable. It's very much an annoyance, but I think unrelated to > the timecounter problem. > > Theron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200310185740.GA1992>