Threadirqs kernel option with generic kernels

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

User avatar
thetotalchaos
Established Member
Posts: 211
Joined: Mon Sep 29, 2014 8:29 pm
Has thanked: 53 times
Been thanked: 9 times
Contact:

Re: Threadirqs kernel option with generic kernels

Post by thetotalchaos »

lilith wrote: Fri Mar 20, 2020 9:15 pm As far as I understand it slowly increases the DSP load and detects at which DSP load the first xruns appears. In addition it also shows the number of cycles. If your system is well configured you should reach 95% or more. What I don't understand is if a DAW that runs with higher priority in the background affects the outcome of xruncounter. E.g. when running xruncounter alone I generally get much better results compared to running xruncounter plus a DAW.
Logically it should measure on its own. Otherwise its just a xrun display. Although if you play the way you are doing, you can have a better idea how heavy are some particular applications.
So the goal is to mark an xrun at 95% DSP?
You can listen to my music at: https://totalchaos-music.bandcamp.com/

Take a journey to wonderland with The Butterfly Effect 2016
https://totalchaos-music.bandcamp.com/a ... fly-effect
User avatar
lilith
Established Member
Posts: 1698
Joined: Fri May 27, 2016 11:41 pm
Location: bLACK fOREST
Has thanked: 117 times
Been thanked: 57 times
Contact:

Re: Threadirqs kernel option with generic kernels

Post by lilith »

thetotalchaos wrote: Fri Mar 20, 2020 9:58 pm
lilith wrote: Fri Mar 20, 2020 9:15 pm As far as I understand it slowly increases the DSP load and detects at which DSP load the first xruns appears. In addition it also shows the number of cycles. If your system is well configured you should reach 95% or more. What I don't understand is if a DAW that runs with higher priority in the background affects the outcome of xruncounter. E.g. when running xruncounter alone I generally get much better results compared to running xruncounter plus a DAW.
Logically it should measure on its own. Otherwise its just a xrun display. Although if you play the way you are doing, you can have a better idea how heavy are some particular applications.
So the goal is to mark an xrun at 95% DSP?
Yes, I have the feeling that the Renoise / VST DSP load is fluctuating a lot with sharp peaks and I should not expect to reach > 90% (or even much less) with running Renoise and xruncounter. A value of 95% means that all you threads are processed within 95% of the available time, so I guess that's a good value.
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: Threadirqs kernel option with generic kernels

Post by tramp »

thetotalchaos wrote: Fri Mar 20, 2020 9:58 pm Logically it should measure on its own. Otherwise its just a xrun display.
Nope. xruncounter is a stress test. It will force a xrun anyway by increasing the dsp load on any callback since xruns appears. It messure the CPU load and the dsp load to give you a hint if your system is setup well for pro audio usage. Regardless if you use a other jack aware application at the same time or not.
As pointed out already, when the results been worse with Renoise for example, running aside, it's a clear hint that Renoise (or one of the plugins it use) produce spikes in the dsp load. As the dsp load is a average value you couldn't see the spices in the dsp load values, but you should properly see them in the CPU load values.
So, when all cores goes to 100% it's likely that you produce a xrun, regardless what the dsp load value shows.
It's even possible when just one core reach 100% and do a context switch.

That's why I pointed out earlier that in my experiences it is much more important to have the best matching boot parameters for your board/cpu combo, then any priority switching you could do.
You all may have noticed the effect of the CPU governor settings, were without setting it to performance you can't reach a good stable audio system. There a a couple of more switches for the cpu's which have by far more influence on the performance of your system, then anything you could do with the priority settings.
On the road again.
User avatar
thetotalchaos
Established Member
Posts: 211
Joined: Mon Sep 29, 2014 8:29 pm
Has thanked: 53 times
Been thanked: 9 times
Contact:

Re: Threadirqs kernel option with generic kernels

Post by thetotalchaos »

tramp wrote: Sat Mar 21, 2020 4:56 am There a a couple of more switches for the cpu's which have by far more influence on the performance of your system, then anything you could do with the priority settings.
Give me an example for that "CPU switches"?.
The idea for the CPU governor is to save power. And logically this will decrease the performance, incl, DSP performance.
You can listen to my music at: https://totalchaos-music.bandcamp.com/

Take a journey to wonderland with The Butterfly Effect 2016
https://totalchaos-music.bandcamp.com/a ... fly-effect
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: Threadirqs kernel option with generic kernels

Post by tramp »

thetotalchaos wrote: Sat Mar 21, 2020 11:42 am Give me an example for that "CPU switches"?.
okay, here are the ones I use.

Code: Select all

intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 idle=poll
With those boot parameters added, it makes no difference any-more, to give my sound-card a higher priority.
here is a bit background knowledge about those:
https://stackoverflow.com/questions/121 ... ux-kernels
On the road again.
Post Reply