Desktop responsiveness under load

I just upgraded my OLD [email protected] workstation to a Ryzen 3700x and while a lot of things are A LOT faster, actual perceivable responsiveness while under load is pretty bad, especially w.r.t. video and audio playing. Playing back a youtube video while doing a big compile job (make -j16) will make the video just stop updating and audio breaks up and chops.

I’ve tried adjusting pulseaudio’s settings and limited the priority of the compile job, updated my bios to the latest one with ABBA, but it’s still a problem.

If anyone knows what might be causing this or any useful information and can tell me I’d be greatful.

more information required
distro
kernel version
desktop environment
ram

1 Like

Ok,

Running:

Debian Sid,
Kernel 5.2.0-2-amd64 / 5.2.9-2
KDE Plasma
64GB DDR4 3200

Old system was similar, except 32GB ddr3 1866 ram.

Old system didn’t show the same issue. It was just slower.

Nothing to do with your hardware, but I had a similar issue under Windows using Chrome to play YT Videos. Constantly moving the mouse over the video itself whilst a video was playing would cause frame drops, to the point where I could freeze the video and the audio played fine.

Firefox didn’t exhibit this behaviour on the same machine. Never did get to the bottom of it - I just stopped using Chrome.

I only mention this as you don’t specify if it’s just video playing in a browser, or does a stand-alone player for video or audio exhibit the same issue?

I’ve not tried playing a video straight up, but will next time it gets to a heavy compile load point.

Mouse really doesn’t have anything to do with it as far as I can tell. I should probably try chrome, but I decided to stop using it recently.

edit: playing a movie via mplayer seems to be fine, at least better than firefox+youtube. so I suppose thats a lead.

keep in mind that linux does not support hardware video decoding in web browsers. Keep in mind that the core/thread type of your old CPU is different than your new one. The old CPU was 8/8 while your new CPU is 8/16. Doing heavy work on all 8 cores can impact more than just 8 threads.

The old cpu was also much slower, with lower memory bandwidth etc. Slower IO speeds as well. Also, the FX series wasn’t quite 8 cores. It shared a lot of logic, including the floating point unit and instruction decoding/dispatching IIRC. I never really had an issue loading up the FX except when under low memory situations.

From what I remember the linux kernel has had a lot of work put into it to make desktop responsiveness as smooth as possible so theoretically this shouldn’t even be a thing.

Just thinking, but I can really only think of two potential causes, how zen2 cpus are /odd/ and that I’m using the nouveau driver with my new RTX 2060 Super. could be they just suck hard and firefox is choking on them. Previous box had a R9 390 using the OSS radeon driver (and sometimes the newer amdgpu driver to play with vulkan). I think trying out the binary drivers will be the thing I try next.

dont ever do that

3 Likes

Sounds like you’re lacking GPU acceleration.

sudo apt install nvidia-driver

Yeah, I just installed the nvidia driver. I just don’t think that kind of lag should actually happen. If it plays back normal with low over all cpu load, it /should/ play fine with other lower priority tasks loading the cpu.

And yeah, just started my test again. Same problem. Youtube player stops updating and audio starts to delay and chop. It even seems to make it eat up the buffer so it has to buffer and downgrade the quality. Odd.

So there we go. Using the hw accelerated video drivers did not fix the problem.

edit: Desktop responsiveness under load is actually worse now! because of the animations I presume. That’s now lagging out, where as before there were no animations.

If playing a video with mplayer works fine, have you confirmed that Firefox is set to use video acceleration?

1 Like

It looks like its enabled, and set to 8 threads. At least when I uncheck the use recommended checkbox has the use hardware checkbox checked, and limit set to 8.

I don’t think thread count matters all that much.

So far, all the things I can think of have been accounted for. Are you getting any errors if you run the browser through the terminal and watch the output?

You might be hitting a bug in Sid that needs to be reported.

So far I’m not seeing any output at all from firefox in the command line. I tried to find some kind of debug or verbose(ity) option, but found nothing so far.

Thought it might be some kind of io issue, so I made sure all my nvme drives were going through the cpu (as much as possible). The nvme drive the build is using is in the primary nvme slot that is tied to the cpu, and i just moved the os nvme to a cpu tied slot. Same problems. :frowning:

After my last big test, X decided to peg a core. I went to a text terminal (which took a minute or so) and decided to kill firefox. I was unable to get back to X and then the pc locked up.

So, now my best guess is ryzen/bios overclocking issues (wrong voltages, PBO etc), or the gpu could be having issues (hw or driver). The behavior I’ve been seeing reminds me of hardware and/or overclocking problems.

Did you ever try to look at the output of dmesg?

It may give you more to go on, especially if you re experiencing hardware issues.

There was some occasional errors in there but nothing that made me worry much at the time. I think by the time the problem got bad enough it was too late to dmesg…

I’ve done some memtest runs. Each stick seems to test fine. Each slot seems to be fine but when all four are loaded I get failures within 5 to 10 minutes :frowning:

I’ll post another thread about this in a hw forum.

Have you tried running the compile through nice?

i.e., instead of just make -j16
nice make -j16

nice will de-prioritise the compile and allow foreground tasks to have higher priority. so instead of shitty desktop response and audio drops, your compile’s cpu scheduling is after everything else has been taken care of…

i.e., it will still make use of up to 16 cores via spawning 16 threads, but if anything else has higher scheduling priority (e.g., everything else not running via nice) it will get priority over the CPU as required.

could even get reasonably snappy desktop performance doing background compiles back in the days of single cores with nice :smiley:

Essentially, no matter how many cores you have, if you tell make to use them all… make will use them all. Without de-prioritising that to less priority than interactive stuff… it will compete with interactive stuff on equal footing. Except with 16 threads to schedule vs. possibly 1 for your audio…). Which you probably don’t want…

see “man nice” for more details.

I’ve tried that, but things are a bit complicated.

The build runs in docker, and I’ve configured docker to limit cpu time, but the build system is some convoluted bs that’s hard to configure. Building Android AOSP. It can and will spawn off far more jobs than you ask for because reasons.

Starting to think they’ve broken passing -j, at least for the java tasks. Hopefully then they’ve internally parallelized the native/C/C++ compile jobs without passing -j. we shall see on my next attempt.