Is 4.3 sluggish for you?

[khal]

Mine is desktop

[WhiteShadow]

@khal

I’m having freezes (and sometimes full system crashes)

Could be hardware issues not related to Qubes.

[khal]

Thanks yes, sounds like a RAM problem but it tested fine back then. I’ll test again.

[WhiteShadow]

Check CPU:

Hard Freeze, Usually When Idle. Possibly AMD related

[TheMailman]

@Euwiiwueir

qvm-clone and qvm-create are for me noticeably faster in 4.3 vs 4.2

@Euwiiwueir

qvm-clone and qvm-create are for me noticeably faster in 4.3 vs 4.2

Yes, I agree with that.

@Invictus

Subjectively speaking, I tolerate any minor imperfections because the graphical interface has been improved,

I can’t say I have noticed any GUI upgrades? New icons or something maybe but mostly I haven’t noticed any changes. I don’t have any Windows Qubes so I can’t compare there.

@Zrubi

Qubes 4.3 runs smoother than any previous release

“Smoother” is vague to me.

@KitsuneNoBaka

Is this on laptop? If yes, then search in BIOS for igfx power savings/turbo/scaling and disable it.

Good idea. Not an option in my BIOS but maybe I’ll update the BIOS at some point.

[dkzkz]

I don’t know for all of you guys but i feel like debian template are far more slower than fedora template.

[dreamscomethrough]

@Euwiiwueir

You might try:

[user@dom0 ~]$ qvm-service --disable sys-net minimal-netvm

To see if that speeds it up for you. Re-enable this way:

[user@dom0 ~]$ qvm-service --enable sys-net minimal-netvm

It does solves that actually, thanks. But I will keep the minimal-netvm anyways as it’s more secure this way. I don’t mind to wait 15sec to connect for the first time compare to trading security over it

[networkman]

It feels a little less responsive at times.

I wonder if reported crashes and the subjective experiences with the new version are related to Dom0 memory leaks. Feel free to monitor and report back.

[Zrubi]

@TheMailman

“Smoother” is vague to me.

while “sluggish” is a precisely measurable thing, right?!

I don’t want to convince you. This is just what I feel. And yes, it is not measurable, not even a technical term, and also very much subjective.

The whole point is to let others know, that not everybody feel the issue.
So in short - and an answer for the question in the topic title:

No, my Qubes 4.3 - on my device - is not ‘sluggish’.

[palainp]

It runs as 4.2 for me, except I now have a constant 20-30% CPU usage in dom0 (visible with xentop, it turns into 2-3% in the tray icon due to 10 VCPUs for dom0).
I have not dug enough (nothing obvious visible with top in a dom0 terminal) but I suspect that this usage drains battery power and now I have to plug my laptop sooner

[HardcodedNonce]

Starting the System (Framework 13" AMD) takes much longer than with 4.2

Attaching mouse and keyboard takes sometimes more than 5 minutes. Often i disconnect both to be presented with the dom0 prompt upon disconnecting.

Attaching USB devices cameras, microphone and USB sticks work fine) take sometimes up to a minute.

So yes, imo it is much worse than 4.2.

[ben-grande]

@barto

For example, even after removing the preloaded disposables, and with only sys-net (combined with USB), sys-firewall, and sys-whonix running, starting a disposable Tor browser takes ~60% more time than on R4.2!

Whonix and every other template became larger and heavier. There are ways to time startup of a qube, you can do this for a stopped anon-whonix:

time qvm-run -p --service anon-whonix qubes.WaitForSession

And from a running anon-whonix:

time qvm-run -p --service anon-whonix janondisttorbrowser.desktop

You can do this same experiment on R4.2 and R4.3 and compare the differences.

[ben-grande]

@unman

Same. Even using the optimizations from 4.2 I notice this.
I stopped preloading disposables because of the performance hit, and I
use a lot of disposables.

Can you expand on this a bit? How much RAM do you have? Is this the same report of not being able to start a disposable because the system doesn’t have enough RAM?

[ben-grande]

@Zrubi

@TheMailman

“Smoother” is vague to me.

while “sluggish” is a precisely measurable thing, right?!

I don’t want to convince you. This is just what I feel. And yes, it is not measurable, not even a technical term, and also very much subjective.

The whole point is to let others know, that not everybody feel the issue.
So in short - and an answer for the question in the topic title:

No, my Qubes 4.3 - on my device - is not ‘sluggish’.

I agree with this. Somethings are not even related to Qubes, such as Torbrowser startup or AMD being unfriendly to work with when it needs patching the kernel. If you report numbers in a reproducible manner, showing the command being run and the output, alongside the resources being consumed by other qubes, some dom0 logs, such as qmemman and qubesd, I might be able to help or redirect to github issues if can’t help.

Your distribution of choice on domUs are becoming bloated each year, just compare the enlargement:

• Index of /r4.1/templates-itl/rpm/
• Index of /r4.2/templates-itl/rpm/
• Index of /r4.3/templates-itl/rpm/

One of the reasons minimal-(netvm|usbvm) was introduced, to prevent some services from starting in sys-(net|usb) (which can’t redistribute because memory management is disabled for qubes with PCI devices).

Therefore, I think it is important to distinguish speed of Qubes components from speed of domU components of your distro of choice.

A lot of performance tests were introduced recently, one of them is qube startup, execution and cleanup in case of disposables.

• Qubes OS openQA: qubesos-4.3-update-x86_64-Build2026012704-devel-system_tests_dispvm_perf@hw7 test results

Unfortunately, this is the only test with graphs and the test doesn’t run on R4.2 openqa.

You can browser more:

• Qubes OS openQA: Test summary

Search for _perf@hw.

[barto]

@ben-grande

Whonix and every other template became larger and heavier.

Fair enough.

@ben-grande

can do this for a stopped anon-whonix:

The second command is wrong, should read:
time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser

Anyway, thank you for taking time to look into this! The results of the timed commands are pasted below.
Note that the hardware is pretty much identical (same CPU, 32Gb of RAM) and I didn’t have anything else running, except for the 3 qubes necessary to start anon-whonix: sys-net, sys-firewall, and sys-whonix .

R4.2.4 timings

[user@dom0 ~]$ cat /etc/qubes-release 
Qubes release 4.2.4 (R4.2)
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ qvm-ls -t --running
NAME            STATE    CLASS    LABEL  TEMPLATE           NETVM
dom0            Running  AdminVM  black  -                  -
sys-net         Running  AppVM    red    default-net-dvm    -
└─sys-firewall  Running  DispVM   green  default-net-dvm    sys-net
  └─sys-whonix  Running  AppVM    black  whonix-gateway-17  sys-firewall
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ time qvm-run -p --service anon-whonix qubes.WaitForSession

real	0m9.240s
user	0m0.059s
sys	0m0.050s
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ qvm-shutdown --wait anon-whonix
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ time qvm-run -p --service anon-whonix qubes.WaitForSession

real	0m9.424s
user	0m0.093s
sys	0m0.070s
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ qvm-shutdown --wait anon-whonix
[user@dom0 ~]$ 
[user@dom0 ~]$ 
[user@dom0 ~]$ time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on anon-whonix

real	0m9.660s
user	0m0.061s
sys	0m0.040s
[user@dom0 ~]$ qvm-shutdown --wait anon-whonix
[user@dom0 ~]$ time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on anon-whonix

real	0m10.385s
user	0m0.056s
sys	0m0.035s
[user@dom0 ~]$

R4.3.0 timings

user@dom0:~$ cat /etc/qubes-release 
Qubes release 4.3.0 (R4.3)
user@dom0:~$ 
user@dom0:~$ qvm-ls -t --running
NAME                    STATE    CLASS    LABEL  TEMPLATE           NETVM
dom0                    Running  AdminVM  black  -                  -
sys-net                 Running  DispVM   red    default-net-dvm    -
└─sys-firewall          Running  DispVM   green  default-dvm        sys-net
  └─sys-whonix          Running  AppVM    black  whonix-gateway-18  sys-firewall
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ time qvm-run -p --service anon-whonix qubes.WaitForSession

real	0m16.693s
user	0m0.118s
sys	0m0.066s
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ qvm-shutdown --wait anon-whonix
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ time qvm-run -p --service anon-whonix qubes.WaitForSession

real	0m13.668s
user	0m0.112s
sys	0m0.065s
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ qvm-shutdown --wait anon-whonix


user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on anon-whonix

real	0m14.642s
user	0m0.104s
sys	0m0.041s
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ qvm-shutdown --wait anon-whonix
user@dom0:~$ 
user@dom0:~$ 
user@dom0:~$ time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on anon-whonix

real	0m14.418s
user	0m0.099s
sys	0m0.041s
user@dom0:~$ 
user@dom0:~$

R4.3.0 feels sluggish!

[barto]

@barto

R4.3.0 feels sluggish!

Actually, there are differences between the R4.2.4 and R4.3.0 installs:

1. the latter is a fresh install
2. the latter uses a combined, disposable, sys-net + sys-usb
3. because of #2, there exists a qvm-features/qubesdb-read construct to pass info to the disposable sys-net (wifi credentials)

I’ll reinstall R430 in a clean, simple, configuration and run the timings again.

[renehoj]

Are you using the same version of Whonix in both 4.2 and 4.3?

[unman]

Can you expand on this a bit? How much RAM do you have? Is this the same report of not being able to start a disposable because the system doesn’t have enough RAM?

I generally have 16GB RAM, with some tweaks in the system. I find that
preloading generally does not provide a benefit for me. That is, heavy
use of disposables reduces the claimed benefit and impacts work adversely.
I see that there have been changes to address some issues, but they do
not seem to have resolved the basic issue. For occasional use, a preloaded
disposable starts somewhat faster, but that is not how I use them. (Also,
it pains me to have multiple qubes sitting about unused.)

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

[ben-grande]

@barto

The second command is wrong, should read:
time qvm-run -a --service anon-whonix qubes.StartApp+janondisttorbrowser

Thanks.

On R4.2, you used -a on qvm-run, while on R4.3, you used -p. The -p as I suggested, is not so nice for .desktop, because it holds until the app closes manually, while -p makes sense for qubes.WaitForSession.

This is from automatic tests:

• https://openqa.qubes-os.org/tests/165816/file/system_tests-dispvm_perf-whonix-workstation-18_graph_00_specs.png
• https://openqa.qubes-os.org/tests/165816/file/system_tests-dispvm_perf-whonix-workstation-18_graph_04_line_01_05_response_gui-small.png

From these tests, it took ~9 seconds for the “Dom0 runs GUI app in a disposable (API)”.

Automatic tests have increased the memory (initial memory to boot before qmemman starts) from 400 to 500 and maxmem from 4000 to 5000. Can you please try it and report?

qvm-prefs anon-whonix maxmem 5000
qvm-prefs anon-whonix memory 500

I followed the same steps as you, same qubes running.

• With 400-4000, I got 12s on qubes.WaitForSession.
• With 500-5000, I got 10-11s on qubes.WaitForSession.
• With 800-5000, I got 9.5s on qubes.WaitForSession.

You may increase memory even more to see different results. No need to increase maxmem beyong 4000 or 5000 though.

Also, please don’t hold qui-domains open or place your mouse over the system tray, there is something there that makes it spike on CPU.

My first anon-whonix with 400-4000 memory, took 14s, but, on subsequent tries (after shutting it down), it took 9.5 seconds. I think this is because the browser is creating a cache.

[ben-grande]

@unman

For occasional use, a preloaded
disposable starts somewhat faster, but that is not how I use them.

Can you share a bit more about how you use disposables, so maybe we could improve your workflow? Also, there was a new feature introduced, preload-dispvm-delay, please see man qvm-features. It adds a delay in seconds to start another disposables after one has been used.

@unman

(Also,
it pains me to have multiple qubes sitting about unused.)

They normally consume between 320-400 MiB and can’t be redistributed after pause. Which I understand, that in memory constrained systems, might be too much.