Help forcing TSC on.

[finalturismo]

Guys iam trying to figure out how to force TSC clock source on.

The performance gains of using TSC is quite large if you have done your research on the issues, but is blocked because of improper time keeping do to cpu frequency scaling. If you disable C states from my understand TSC is safe to use and you get a large drop on latency and a large bump in performance.

Anyway its pretty hard to Google the issues about TSC and most of the community does not understand the performance gains by using TSC as the clock-source timer.

It seems like Linux devs have gone out of their way to block kernel command lines from re-enabling TSC and disabling watch dog services.....

Iam working on the ultimate KVM setup and this is one of the last hurdles i need to get over.


Anyway here is some information on why TSC is superior and how it is still accurate if you stop the CPU from scaling frequency...

If you want a truly live time Linux experience TSC is a must with a low latency kernel and will provide big performance increases in games and multimedia apps.

Its one of the biggest performance improvements we can do and it seems to be blocked on many levels.


https://blog.trailofbits.com/2019/10/03 ... chmarking/
https://www.codethink.co.uk/articles/20 ... e-latency/
https://github.com/trailofbits/tsc_freq_khz




TSC and reverse specter and meltdown patches make massive performance increases and help to build a truly live system...

If anyone wants to dive deep with me into this venture than lets get on it.

[eccerr0r]

kernel command line: clock=tsc

But you should look in your bootup sequence, most of the times the kernel will test if the tsc is working properly at boot time and refuse to use it if it finds it unstable. Most of the times it will indeed use the tsc, many of my machines automatically uses it without intervention.

I wouldn't say tsc makes your computer "faster" but rather it can know exactly when events need to happen and not need to poll or do spinloops for exact delays... that is if it's stable.

Note that TSC is what makes spectre/meltdown trivial to exploit, cpus without TSC are more difficult to reliably exploit spectre/meltdown.

[Ant P.]

None of the links you've provided support your assertion that this is some magical performance increase; the only one with any data at all changes half a dozen other settings and has the RT patchset.

[Anon-E-moose]

On my system tsc gets enabled without me doing anything

Code: Select all

$ grep tsc /var/log/dmesg 
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3599.637 MHz processor
[    0.492653] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x33e2fc81425, max_idle_ns: 440795370616 ns
[    0.854683] clocksource: Switched to clocksource tsc-early
[    1.924665] tsc: Refined TSC clocksource calibration: 3600.002 MHz
[    1.924674] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33e4559ce44, max_idle_ns: 440795364889 ns
[    1.924703] clocksource: Switched to clocksource tsc

[finalturismo]

None of the links you've provided support your assertion that this is some magical performance increase; the only one with any data at all changes half a dozen other settings and has the RT patchset.

Ive spent over 3 months tuning KVMs, with Clock source timers, timer resolution size, cpu pinning, system interrupte managements etc.... I can tell you from experience........ clock source drastically effect performance and anyone that has spent time playing with them knows this is true.

Time keeping and system interrupts vitally effect performance and if you want a true live computing experience you need TSC and the removal of specter and melt down patches.

Ive already done plenty of benchmarking and have seen the numbers for my self with other clock source timers.

TSC is a hardware based clock source while HPET is more emulated. HPET is specifically used because of the TSC problems with specific processors.

Once you dive deep down into timers its well known that TSC is MUCH better. This is common knowledge, but if you Google the issue you will see mostly information about the TSC problems.

HPET was implemented to mask the issue, go research your self. Also TSC is the done at the CPU level....

There are also plenty of benchmarks and the internet based on clock source timers. Go look it up your self before you start finger pointing.

I already have tons of heaven benchmarks when playing with timer resolution and clock source. Both guest and host are massively effected by clock source.

Also there are very few people who event attempt to deep dive into clock source so id recommend not flaming someone for something you dont know about.

Go start playing with timers, interrupt handling and clock sources and you will see huge differences. This isnt the guy that says, hey edit this registry key for 50% more performance.

Few have a truly real time Linux kernel running and there are certain steps you take in order to achieve it.

Higher timer resolution, system interrupt handling, TSC clock source, real time kernel or patch (not low latency, real time....)

In order to make TSC more accurate you need to get rid of all processor frequency scaling as this causes the timer to be inaccurate during frequency steps..... But help iam trying to explain months of research to someone that isnt even aware of what iam talking about hardly...

https://www.chromium.org/chromium-os/ho ... ronization
https://www.anandtech.com/show/12678/a- ... -results/4

Read the AnandTech link.... surprised i actually found that.... and those gains are small compared to what iam talking about...

Thats just turning of HPET..... anything latency related such as gaming is drastically effected by switching back to TSC....

If you can manage to get a real time kernel working with TSC and a high frequency resolution with proper interrupted handling your talking insane performance differences....

Also running a truly real time kernel properly configured is an experience in it self.

People that are aware of the issue go through hell and high water to get TSC working correctly.... but kernel devs seem to making this a pain when TSC is marked as unstable...

The amount of work i have spent getting rid of anything that messes with CPU frequency and the amount of times i have spent compiling Gentoo kernels is insane...

I have tons of heaven benchmarks to prove my points... now i just need to force TSC back on and finish the realtime kernel part... Was hoping there might be someone here who is aware of the issue

and has done it them self. This is one of those things you have to dive really really deep on the internet to get good info on, a 5 minute Google aint going to cut it.

[Anon-E-moose]

In order to make TSC more accurate you need to get rid of all processor frequency scaling as this causes the timer to be inaccurate...

Wrong, dead ... wrong, but it fits in with the rest of your brilliant posts.

But help iam trying to explain months of research to someone that isnt even aware of what iam talking about hardly...

I'm pretty sure you don't know what you're talking about, and your vast research of "using google" is laughable.

Good luck with your problem.


Edit to make Neddy happy (sorry)


ETA2: there are indeed some problems with SOME TSC implementations, certain motherboards, certain kernel (google for example with their patches), etc, but those are very specific problems, and there's nothing that bolsters your CONJECTURE about tsc and freq whether scaled or not.

[NeddySeagoon]

Play nicely together please team.

[finalturismo]

In order to make TSC more accurate you need to get rid of all processor frequency scaling as this causes the timer to be inaccurate...

Wrong, dead f'ing wrong, but it fits in with the rest of your brilliant posts.

But help iam trying to explain months of research to someone that isnt even aware of what iam talking about hardly...

I'm pretty sure you don't know what you're talking about, and your vast research of "using google" is laughable.

Good luck with your problem.

you obviously didnt look at the anandtech benchmarks....


Ok well here is a bug zilla post for people that are all aware of the TSC issues and why they are caused. Its common knowledge processor stepping effects time keeping...

So good job making your self not look so smart. This is common knowledge in the kernel dev community and people are still working to fix the issues.




https://bugzilla.kernel.org/show_bug.cgi?id=203183


"- intel_idle.max_cstate=7: this indirectly disables PC10, keeps TSC and HPET, clocksource and watchdog are in low difference within 62.5ms.
- tsc=reliable: this disables Linux kernel clocksource watchdog
- hpet=disable: this makes kernel choose another existing clocksource as watchdog"



Many of the kernel command lines have been changes and or blocks and Gentoo is already a bit different than most distros...

This was the issue i was trying to get help on.... Also i was trying to educate the people on TSC issue because it is true... iam not spewing a whole bunch of lies... iam an adult not a 5 year old...

Iam trying to better the community....

Time keeping has never been perfected on the processor and still an issue that needs to be addressed....

TSC was the best we had , but because of steppings, cstates, power management changes it broke TSC..... so certain steps have to be taken to reenable, make it more accurate and trick the kernel to use it again.

The performance improvement you get is vast and provable.... and i was making a big deal out of it to get people to research the issue it self.... because its one of those things people just arnt that well educated on...

This issue is present on most if not all newer CPUs.

When doing KVMS on TSC with a none bugged CPU... you dont have sound stuttering and audio crackling...

The things you have to do to get the crackling to stop on a duel CPU system with HPET being used as a clock source is insane...

Once you break that latency curve the crackling starts again.

[Anon-E-moose]

This is my last post to you, you don't know what you're talking about.

All your links look like you googled tsc or tsc problems and just listed everything you saw. Poor way of "research", very poor

Your last link of bugzilla didn't really have anything to do with tsc, per se, it was problems caused by an incorrect going to sleep on a very new processor (coffee lake) that wound up affecting tsc, did you get that, tsc was affected, not the prime problem

And that's the same with all your posts, ... I'll reiterate, you don't know what you're talking about re. tsc and problems.

Good luck, I won't waste any more time on you. *plonk*

[eccerr0r]

Yes using HPET and especially PIT incur bus IO penalties as both are hardware devices, and even worse for the PIT that it needs to now emulate ISA. But the number of instructions hopefully are minimal compared to the thousand of other instructions that need to be executed to decode A/V realtime.

Specifically there are many CPUs that indeed have problems with TSC not being a reliable clock source. In fact the TSC was not intended to be a timing source, rather it was meant for benchmarking but people have decided they want to use it for a timesource instead, ugh, and this messes up its initial purpose. Alas they decided to change the architecture to appease the software writers so it won't have to stay in C0...

For me, spending the extra power leaving the CPU at C0 all the time is a no go. HPET is the right option for me for those that eat tremendous power while keeping TSC up. In fact HPET should have always been the timing source after PIT got obsoleted, not TSC, except that TSC with the appeased implementation is even more accurate without inducing bus cycles.

[finalturismo]

This is my last post to you, you don't know what you're talking about.

All your links look like you googled tsc or tsc problems and just listed everything you saw. Poor way of "research", very poor

Your last link of bugzilla didn't really have anything to do with tsc, per se, it was problems caused by an incorrect going to sleep on a very new processor (coffee lake)

And that's the same with all your posts, ... I'll reiterate, you don't know what you're talking about re. tsc and problems.

Good luck, I won't waste any more time on you. *plonk*

Dude you arnt even reading anything , your just flaming everyone here can clearly see that.

Even one of the biggest hardware reviewers has posted benchmarks on the issue the differences are huge in any type of latency effected applications..

do you even know who Anandtech is?

[NeddySeagoon]

Locked for at least 24h to give everyone time to reflect on the guidelines about attacking the content of the post and not the individual making the post.

Anyone wanting to add a reasoned technical contribution to this thread please PM me.
The lock can be removed.