Date: Tue, 10 Mar 2020 10:51:52 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Theron <theron.tarigo@gmail.com> Cc: Peter Jeremy <peter@rulingia.com>, FreeBSD Current <freebsd-current@freebsd.org>, kib@freebsd.org, neel@neelc.org Subject: Re: System clock is slow Message-ID: <26FD35E4-DA43-4963-A5ED-9FE6FB0E0FCA@bitblocks.com> 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 Mar 10, 2020, at 9:24 AM, Theron <theron.tarigo@gmail.com> wrote:
>=20
> 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)?
>=20
> 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?
>=20
> 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.
>=20
> /*
> * 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.
> */
>=20
> 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@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....=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26FD35E4-DA43-4963-A5ED-9FE6FB0E0FCA>