Re: System clock is slow

On Mar 10, 2020, at 9:24 AM, Theron <theron.tarigo_at_gmail.com> 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.

May take a while. ntpq -c peer should show a line with a leading *.
Though likely unrelated to your problem.

>> 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

In an old (amd 8150) -12.1 machine I see
kern.timecounter.hardware: TSC-low
kern.timecounter.tc.TSC-low.frequency: 1806045908
machdep.tsc_freq: 3612091816

In a new ryzen -current machine:
kern.timecounter.hardware: TSC
kern.timecounter.tc.TSC.frequency: 2096123148
machdep.tsc_freq: 2096123148

> 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).


As I understand it, if the user doesn't *explicitly* disable
frequency calibration, it must be calibrated. It may still be
skipped if there are no legacy devices. See around tsc.c:300.

What does sysctl machdep.disable_tsc_calibration return? Do you
see a line like the following in dmesg?

Skipping TSC calibration since no legacy devices reported by FADT and CPUID works

The Commit log says this:

    x86: Fall back to leaf 0x16 if TSC frequency is obtained by CPUID and
    leaf 0x15 is not functional.

    This should improve automatic TSC frequency determination on
    Skylake/Kabylake/... families, where 0x15 exists but does not provide
    all necessary information.  SDM contains relatively strong wording
    against such uses of 0x16, but Intel does not give us any other way to
    obtain the frequency. Linux did the same in the commit
    604dc9170f2435d27da5039a3efd757dceadc684.

    Based on submission by: Neel Chauhan <neel_at_neelc.org>
    PR:     240475
    Reviewed by:    markj
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D21777

> 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?

Have you looked at hpet(4), timecounters(4), clocks(7) manpages?
I don't know how up-to-date these manpages are....