Date: Tue, 10 Mar 2020 12:24:24 -0400 From: Theron <theron.tarigo@gmail.com> To: Peter Jeremy <peter@rulingia.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, kib@freebsd.org, neel@neelc.org Subject: Re: System clock is slow Message-ID: <a2603db8-f3e9-fa9d-b2cf-a80e55dc926e@gmail.com> In-Reply-To: <20200310053833.GD3091@server.rulingia.com> References: <989cd36a-e015-940a-dfe2-851c6fdf4734@gmail.com> <20200310053833.GD3091@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?) 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). 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. > 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?a2603db8-f3e9-fa9d-b2cf-a80e55dc926e>