| View previous topic :: View next topic |
| Author |
Message |
manu_leo
Guru
Joined: 20 Jan 2014
Posts: 513
Location: India
|
 Posted: Mon Sep 26, 2016 8:10 am Post subject: tsc clock source missing from available_clocksource . |
 |
|
Hi Experts, I need tsc to be set as the available clock source however I donot see it under available clock sources.
| Quote: | # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
|
| Quote: | # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
|
Is there some kernel changes which has to be done to make tsc visible ? On my other servers I do see this time source along with hpet and acpi_pm.
Thanks for all the help in advance |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Sep 26, 2016 3:59 pm Post subject: |
|
|
| Post output of `dmesg | fgrep -i tsc`, that should show whether it had a tsc driver or not. |
|
| Back to top |
|
|
manu_leo
Guru
Joined: 20 Jan 2014
Posts: 513
Location: India
|
| Posted: Tue Sep 27, 2016 7:37 am Post subject: |
|
|
Thanks Ant, here is what I see :-
| Code: | /sys/devices/system/clocksource/clocksource0 # dmesg | grep -i tsc
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 3458.084 MHz processor
[ 3.025224] tsc: Refined TSC clocksource calibration: 3458.000 MHz
[ 3.025419] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x31d854e00f0, max_idle_ns: 440795240752 ns
[ 4.025509] clocksource: Switched to clocksource tsc
[257898.790543] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as unstable because the skew is too large:
[257898.790551] clocksource: 'tsc' cs_now: 32b78453bdd5c cs_last: 329fc9ec78d9e mask: ffffffffffffffff
[803947.451880] clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode
[803956.706758] clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode
[807101.681139] clocksource: Override clocksource tsc is not HRT compatible - cannot switch while in HRT/NOHZ mode
|
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Sep 27, 2016 5:11 pm Post subject: |
|
|
| manu_leo wrote: |
| Code: | | [257898.790543] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as unstable because the skew is too large: |
|
That's your problem, the kernel is disabling the tsc because it's too inaccurate. This is normal, it's why we have hpet/acpi timers in the first place.
What exactly do you need tsc for? |
|
| Back to top |
|
|
finalturismo
Guru
Joined: 06 Jan 2020
Posts: 410
|
| Posted: Sun Oct 18, 2020 3:37 am Post subject: |
|
|
| Ant P. wrote: | | manu_leo wrote: |
| Code: | | [257898.790543] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as unstable because the skew is too large: |
|
That's your problem, the kernel is disabling the tsc because it's too inaccurate. This is normal, it's why we have hpet/acpi timers in the first place.
What exactly do you need tsc for? |
So iam bringing up an old post regarding this. I upgraded from dual e5-2690 cpus that were using the TSC clock source. My KVMs happen to work much better with the TSC clock-source. I did some reading and found out TSC is great in terms of performance but many of the new processors have some short comings so instead HPET was selected as a primary clock sources for many modern CPUs. Anyway.... for my E5-2687WV2 CPUs iam unable to select this as a clock-source and i was wondering if there is anyway to force the kernel to use this. I have done some reading and many of the TSC issues are related to C stepping and the CPU changes its power states which causes the TSC clock source to become inaccurate and not stable. Anyway it took me 2 months to get my KVMs running good with the HPET clock source by passing through a NVME drive to the KVM(massively reduced I/O, because it does not have to access the virtual disk file). For some reason using the virtual disk file causes more I/O and has lots of problems with HEPT. Passing through the NVME is able to fix this issue. Dont ask me how i know this, it took me 2 months of trial and error to get to the bottom of my audio and fps stuttering. I now know 100% its all related to I/O and the clock source timer. So even though me passing though my NVME to my VM solved my issue, its not all the way solved. I know i can push higher frames if i can switch to a TSC clock timer. (They dont get interrupter like HPET when you have TSC running good) Anyway i have don't alot of the prerequisites for making my CPU work decent with the timer i just need to figure out how to force Gentoo to use it again. Any ideas on what i do? |
|
| Back to top |
|
|
finalturismo
Guru
Joined: 06 Jan 2020
Posts: 410
|
| Posted: Fri Nov 06, 2020 3:55 am Post subject: |
|
|
| bump |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Nov 06, 2020 11:04 am Post subject: |
|
|
| Quote: | | Any ideas on what i do? |
Yeah, quit bumping old threads and then starting yet another thread about tsc.
 a
Edit to add: you're going to get the same answer as last time, your tsc implementation is broken, get a better motherboard/cpu OR learn to live with what you have.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
|
Portage & Programming
