Bug 244705 - /usr/src/sys/x86/x86/tsc.c: System Clock is 0.3% slow since r352684
Summary: /usr/src/sys/x86/x86/tsc.c: System Clock is 0.3% slow since r352684
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-03-09 23:41 UTC by Theron Tarigo
Modified: 2020-08-11 17:55 UTC (History)
4 users (show)

See Also:


Attachments
reverts the breaking change (1.29 KB, patch)
2020-03-09 23:41 UTC, Theron Tarigo
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Theron Tarigo freebsd_committer 2020-03-09 23:41:30 UTC
Created attachment 212294 [details]
reverts the breaking change

After switching from 12.1-RELEASE to CURRENT I noticed audio driver appeared to be consuming samples too fast by about 0.3%.  However after verifying audio devices are working properly I discovered that system clock is actually slow by 0.3% (confirmed by using ntpdate to compare with time server).

This is not a hardware fault since I can reliably get correct clock by booting 12.1-RELEASE or CURRENT r352683 but slow clock with CURRENT since r352684 unless reverting that change.

hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
Comment 1 Greg V 2020-04-04 15:06:54 UTC
On my Ryzen system, r352684 (or something.. but nothing else TSC related happened recently) caused the TSC to go completely nuts, time is quickly becoming off by many minutes, I looked at the clock yesterday and it was 3 hours behind :D

kern.timecounter.hardware=HPET seems to be better (-14 sec desync from NTP in an hour without an NTP daemon, that's not crazy and should be manageable by NTP)
Comment 2 Mark Johnston freebsd_committer 2020-06-04 15:54:11 UTC
Does the problem persist after r359997?
Comment 3 Mark Johnston freebsd_committer 2020-08-11 17:55:15 UTC
Please re-open if the problem indeed persists on head after r359997.