Re: System clock is slow

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