From owner-freebsd-current@freebsd.org Tue Mar 10 17:52:38 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 97CF126B795 for ; Tue, 10 Mar 2020 17:52:38 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 48cN3804Tbz4DRl; Tue, 10 Mar 2020 17:52:35 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mob.bitblocks.com (mob.bitblocks.com [192.168.125.11]) by mail.bitblocks.com (Postfix) with ESMTP id 9FA6A156E45D; Tue, 10 Mar 2020 10:51:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: System clock is slow From: Bakul Shah In-Reply-To: Date: Tue, 10 Mar 2020 10:51:52 -0700 Cc: Peter Jeremy , FreeBSD Current , kib@freebsd.org, neel@neelc.org Content-Transfer-Encoding: quoted-printable Message-Id: <26FD35E4-DA43-4963-A5ED-9FE6FB0E0FCA@bitblocks.com> References: <989cd36a-e015-940a-dfe2-851c6fdf4734@gmail.com> <20200310053833.GD3091@server.rulingia.com> To: Theron X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 48cN3804Tbz4DRl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@bitblocks.com designates 173.228.5.8 as permitted sender) smtp.mailfrom=bakul@bitblocks.com X-Spamd-Result: default: False [-3.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.228.5.8/29]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bitblocks.com]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.91)[ip: (-5.95), ipnet: 173.228.0.0/20(-2.98), asn: 46375(-0.55), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:46375, ipnet:173.228.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:52:38 -0000 On Mar 10, 2020, at 9:24 AM, Theron 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 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....=