Extremely slow performance on Qubes 4.1

User Support 4.1
#1

Hello! After installing Qubes 4.1 on my desktop computer, I still cannot use it, since Qubes is extremely slow and laggy. My hardware requirements does fit what is necessary:

16 GiB of ECC RAM
2.5 GHz Xeon processor
120 GiB SSD storage

It is slow in a way that the mouse and the applications laggs and delay in opening. The sys-net and sys-firewall VMs take about 10 minutes to start.
Using Qubes in those conditions is similar to use a modern OS on a 256 MiB computer. (If you did it, you know what I’m talking about)

I’ve tried some commands in case the processor was set to slow performance, but nothing changed.

Does anyone have a clue?

#2

You need more memory. Too have a happy qube 32gb at least of memory. Outside of this Maybe time too replace the SSD,they don’t last forever. Even the best ones go out after a while.

#3

I don’t think so… 16 GB of ram is recommended on the documentation.

Besides, before 4.1, I was using 4.0.4 on a much slower hardware, and everything worked just fine.

2 Likes
#4

What do top, free mem and iotop --only say in dom0 (iotop not installed by default) ?

PS: I don’t think that’s a memory size problem, I’m currently -testing- Qubes 4.1 with 3GB, it works well with minimal VMs (sys-net + sys-firewall set at 300MB, dom0_mem min/max set at 1152). dom0 mem usage is around 500MB after boot, 650MB after both VM have started.

1 Like
#5

top says there is 3064.5 MiB free on dom0, and that it’s using about 0.8% of processor’s power.

free mem says there are 3380476 available.

iotop is not installed

So i think memory is not the problem here

#6

Ah I forgot xl top, and check also dmesg and xl dmesg for errors. Maybe it’s a hardware/driver problem ?
It’s only a guess but you may try to disable autoballooning, by disabling it for your VMs and setting dom0 mem in grub config (by setting min and max at the same value, dom0 will use a fixed size of memory).
I don’t know if that happens also on “real installs” (i run Qubes nested), but I had strange results when setting some weird amounts of RAM. Maybe the same problem appears when dom0 uses that same amount of RAM (between 2.5 and 3GB) ?
But it’s strange that you have only 3GB free (what about cached RAM ?) with only 3 VMs started.
Is the system also unusable when there are no VMs running ?

#7

Top also says I have a total of 3891.0 MB of memory, and the Qubes domains says dom0 has 4080 MB. I also have a 10GB swap, but top says it has 0.0 MB used.

Yup. Right now only dom0 is up and still extremely slow. Opening and using the dom0 terminal emulator lagged. Basicaly, the whole GUI is slow, but opening the terminal on tty2 seemed to work without problem.

xl top says dom0 is using 4177920 (25% of the total memory) and about 5% of cpu power.

I’ve run dmasg and xl dmasg, but i don’t know read the output, and it seems to not have any error code. But what would you suggest me to look for on dmasg?

#8

I’ll throw this out there that I’m also having an impossible time using Qubes on hardware that used to run it just fine a few months ago. (Just did a fresh install yesterday.) I’ve got 32GB of RAM. And most of the time it completely freezes on the password prompts (disk and user passwords). I have been able to login twice, but I am unable to get to a point where I can see if there are any pending updates without the system freezing.

#9

This may help pinpointing the source of the problem. Graphics driver issue ? As it’s a desktop, try a GPU from a different brand. But you would have to tweak xorg.conf to only use the new GPU/driver, and maybe blacklist the old one via modprobe.
If it’s a graphic/driver problem, xl dmesg won’t help. Hell, I don’t think even dmesg could ? Hard for me to tell what to look after ! You’ll have to read everything … You could also use journalctl -b 0 -p 0..3, to only display major errors. Increase the 3 to 4 or 5 to display more (but less impactful) errors.
Another guess, as the VT ttys are working, you could try to update dom0 from there.

This is also indicative of what may be the source of the problem. But is it a Qubes 4.1 problem ? A kernel problem ?

You should both compare your systems and kernel/Qubes versions, what version worked and not.

1 Like
#10

@zithro I think you are right. Right after I posted, I swapped graphics cards and it seems to be working a lot better. (I need to reinstall because none of the template VMs got set-up and working through that now.) For context, I swapped my NVIDIA Quatro P1000 card for an AMD (unsure exact model right now).

1 Like
#11

I also thought it might be something with GPU, but even the audio is glitched. Does laggy audio have something to do with GPU if I’m not using HDMI?
If it really is a GPU issue I think installing Nvidia driver might work

#12

Nice! What model is it? My is a Nvidia GeForce 8400.

#13

Nice to read ! Also context is nice for future readers.
I’ve often read there are less problems with AMD GPUs, but that may be just me. Or the fact they open source(d?) their drivers, so the kernel can use or create supported ones.

Are you using the audio from the GPU or from a dedicated audio card ?
Anyways, as it’s a different driver, maybe not, dunno. On my system, both the AMD GPU and the integrated MoBo soundcard use the module snd_hda_intel.
But maybe an error in a driver may trip the kernel and you have side effects. You can try to create heavy IO on the SSD to see if that’s slow too.

#14

Well yes guys, base install 16gb memory “base” install is the clue. If you want to run hvm’s along side of domians up and running at same time more memory is needed and speed for processing…

They keep adding more power and safety along with privacy.

Qubes provides so much to work and play with why limit yourself…

#15

Writing back to confirm, ditching the Nvidia Quatro P1000 and going to the AMD Radeon 680 fixed all my issues. I’m on:
Qubes 4.1
Kernel 5.10.90-1.fc32
Xen version: 4.14.3

3 Likes
#16

Was your audio also laggy when using Nvidia card? I mean, I am not using HDMI, so my audio device in use should in theory be the integrated audio card.

#17

I’m not sure but everything was laggy. Template VMs didn’t get installed. Often I couldn’t enter my password with the keyboard. I was never able to get it running far enough with NVIDIA to test audio. Although I agree that the GPU shouldn’t have a direct effect on audio, it inherently could. If the system is having issues with the GPU in general, it can have a cascading effect throughout the system. If you can, try another graphics card and see if that fixes it, I’d bet that it does. (unfortunately, I’ve seen a lot of issues with NVIDIA cards on Qubes)

#18

Depends on your alsa/pulse config