Worse performance when power supply plugged in!

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

You can have a look at the output of dmesg, if it contains entries saying something like thermal throttling (don't remember the exact wording) it's because the cpu gets too hot and throttles in order to avoid overheating. I have an asus i7 laptop that does exactly this, but does it when on battery too :( It's simply not able to cool the cpu enough when it's running full tilt...:S Though I prefer lower max performance to xruns...

Have a look at /sys/devices/system/cpu/intel_pstate, which contains several files that you can use to set max multiplier, turn turbo off, etc. Documentation at: https://www.kernel.org/doc/html/v4.12/a ... state.html

For instance if you write 1 to no_turbo (as root), it won't try to set any turbo P state.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

Re: Worse performance when power supply plugged in!

Post by Musicteacher »

Hi Jack, I had answered this in the other thread (KDE for music stuff).

Of course a modern cpu cannot permanently run on the highest turbo-boost frequency. So I have made a test with prime95 do find out, what the highest frequency is that my cpu can run when on 100% multithreaded use. That is 1.8 gHz. So I have set the frequency to that value instead of using the performance-governor.

If I disable turbo-boost completely, I get 1.6 gHz only.

The only other thing that would be possible is to de-activate 3 of the 4 cores. Then the last core can run on 3.4 gHz permanently. But as music-stuff usually is multithreaded, this probably does not make sense.

Summary: Disable higher c-states than c1, keep the cpu running on a constant rate (highest rate does not really make sense) gives good audio-performance.
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

I seem to have no problem to let the intel pstate driver change frequency, it causes no xruns, but of course makes it hard to compare CPU/DSP load between different scenarios as numbers become kind of meaningless.

Even my laptop is happy with changing frequencies. The only problem I have with this on the laptop is when the CPU becomes too warm and it gets throttled. Using the sysfs entries I can set the max multiplier and disable turbo. So it kind of gives me the best as much as it can run at a lower freq and still scale up without causing thermal shutdowns. The latter which is what caused me xrun problems. YMMW and all that :) Still happy you found a solution.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

Re: Worse performance when power supply plugged in!

Post by Musicteacher »

I had a rehearsal last evening. This time I was there early and set up things and stuff.

In the beginning, I had the occasional xrun. Later on, there weren't any more, even though I reduced the buffersize to 64 bit / 2 periods.
So this confirms that not the power supply is the problem but loading the battery is. When the battery was fully loaded, no more xruns occured.
For gigs, I will make sure that the battery is fully loaded.

Interestingly, on a musical side, I noticed that I am much more sensitive to latency when playing guitar. It seems that on piano I am used to some latency, maybe, because it always takes time for the hammer to hit the string. The mechanics of a piano are quite complex, whereas on the guitar you directly feel how you strike the string and expect the sound to be heard instantly.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: Worse performance when power supply plugged in!

Post by CrocoDuck »

Musicteacher wrote:Interestingly, on a musical side, I noticed that I am much more sensitive to latency when playing guitar. It seems that on piano I am used to some latency, maybe, because it always takes time for the hammer to hit the string. The mechanics of a piano are quite complex, whereas on the guitar you directly feel how you strike the string and expect the sound to be heard instantly.
Hi there! I have been skimming through the thread and I saw this. I though it could be interesting if I dropped by to link a blog post I wrote on the topic:

https://thecrocoduckspond.wordpress.com ... ive-study/

According to experimental result, latency perception is indeed correlated, among many things, with the instrument being played. This was found also among subjects skilled with multiple instruments. My post is pretty long and perhaps boring, but maybe 4 people on earth will find it interesting.
User avatar
milo
Established Member
Posts: 1242
Joined: Wed Sep 06, 2017 2:55 am
Location: Southern Utah, USA
Has thanked: 275 times
Been thanked: 218 times
Contact:

Re: Worse performance when power supply plugged in!

Post by milo »

CrocoDuck wrote:I though it could be interesting if I dropped by to link a blog post I wrote on the topic
Thanks for sharing that blog post, CrocoDuck. It was a very interesting read. (1 down; only 3 more interested people to find!)

It got me thinking about using latency as a stereo effect in a mixdown. I have experimented with that a bit in the past, and it sounds really good on headphones. But the effect doesn't work as well when listening through speakers, and when you play the mixdown through a single speaker (like your phone), you get a strange filtering effect. Now, thanks to your article, I know how that happens and what it is called.
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

Re: Worse performance when power supply plugged in!

Post by Musicteacher »

Thank you, too! I skipped through the article (I knew quite a bit of that before).

In the article, there was a distinction between "guitarists" and "piano players". I am that in one person, and found it interesting that I still percieved latency much worse with guitar. So it is not a personal thing, but an instrumental think!

Back to technical things: Would it be possible that not the battery-loading (physically) gets in the way of music-performance, but the process that reports battery status? (software wise). Is there a daemon that can be turned off so the system is agnostic of the battery status? This would be really interesting (and helpful, as it might be that in-performance the battery drops by self-unloading and is re-loaded just in the wrong moment and a crack occurs). Unfortunately it is not possible for me to remove the battery (which would be a good solution).
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

I notice higher latency more on drums and guitar. With bass and keys I notice it less.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: Worse performance when power supply plugged in!

Post by CrocoDuck »

Musicteacher wrote:Back to technical things: Would it be possible that not the battery-loading (physically) gets in the way of music-performance, but the process that reports battery status? (software wise). Is there a daemon that can be turned off so the system is agnostic of the battery status? This would be really interesting (and helpful, as it might be that in-performance the battery drops by self-unloading and is re-loaded just in the wrong moment and a crack occurs). Unfortunately it is not possible for me to remove the battery (which would be a good solution).
I only skimmed to the thread, and I cannot do a proper read now, so maybe you already provided this info, but what power management system are you using? If it is TLP, you should be able to stop the service entirely.
CrocoDuck
Established Member
Posts: 1133
Joined: Sat May 05, 2012 6:12 pm
Been thanked: 17 times

Re: Worse performance when power supply plugged in!

Post by CrocoDuck »

OK, I finally managed to read the thread properly.
Musicteacher wrote:I'm on arch, rt-kernel 5.0.5 .

I do:

I summarize what I do on my system:
- use linux-rt kernel (which does not seem to make a real difference, at least as shown by xruncounter)
- set cpu governor to performance
- disable hyperthreading
- suspend baloo (with the command balooctl suspend )
- disable compositing
- disable kde power managemend
- set kde to plane-mode (this disables wlan + bluetooth)
- set realtime irq optimizations (rtirq start)
Musicteacher wrote:tlp is not installed.
So, about this:
Musicteacher wrote:Back to technical things: Would it be possible that not the battery-loading (physically) gets in the way of music-performance, but the process that reports battery status? (software wise). Is there a daemon that can be turned off so the system is agnostic of the battery status? This would be really interesting (and helpful, as it might be that in-performance the battery drops by self-unloading and is re-loaded just in the wrong moment and a crack occurs). Unfortunately it is not possible for me to remove the battery (which would be a good solution).
If you did not install any daemon yourself, I guess your KDE might have pulled one in as a dependency, or maybe it has some built-in battery polling thing. Maybe you could check both the dependency graph of KDE and what kind of battery related functionality KDE itself has.

There might be the possibility that the kernel is doing something. I am on Arch too, and I too noticed that Arch Linux stock kernel has recently gained very good audio performances, to the point I do not need rt anymore. You could try to install linux or linux-lts and see whether that changes anything.
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

Could it be the hardware itself? BIOS code or something like that.

Do cyclictest results get worse when charging the battery?
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

Re: Worse performance when power supply plugged in!

Post by Musicteacher »

Hi,

do you have a doc on cyclictest for audio profiling?

I have never used that, and the docs are not so simple.
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

Not really :)

Try with "sudo cyclictest -m -Sp98 -i100 -d0 --smi"

You'd want the max to be lower than say 100us & no SMIs.

This measure indicates how long it takes the kernel to schedule a thread. If there are huge delays then it will indicate some problem with the system. It's less of a problem with SMP systems, but in the final analysis if the audio threads are scheduled later then you lose time to do the audio processing.

Having a RT kernel helps with this, but also with a normal kernel it's a test that can show if there are hardware problems. Best to run it for longer times and to load down the system (you can use "hackbench -l 100000" for this). But in your case, it would be interesting to see if the max goes up when the power supply is plugged in.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: Worse performance when power supply plugged in!

Post by merlyn »

There's a guide here:

https://www.mixxx.org/wiki/doku.php/adj ... io_latency

Scroll down a bit. On that guide it recommends running cyclictest as a normal user. When you start cyclictest you can watch the 'Max' field while you plug the power supply in.
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

Re: Worse performance when power supply plugged in!

Post by Jack Winter »

merlyn wrote:There's a guide here:

https://www.mixxx.org/wiki/doku.php/adj ... io_latency

Scroll down a bit. On that guide it recommends running cyclictest as a normal user. When you start cyclictest you can watch the 'Max' field while you plug the power supply in.
Because :)

"Do not run the above commands via sudo! If you cannot run these as an unprivileged user, then your /etc/security/limits.conf change did not work."

I added the sudo to indicate that the command would have to be run as root, as most likely a user will not be able to use the --smi option. /dev/cpu/*/msr would only be readable by root..
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
Post Reply