Fresh install of Neon 6.3 runs slow (REALLY slow!)

incans · February 27, 2025, 3:49pm

SUMMARY

A fresh install of KDE Neon 6.3 on my newer “machine 2” machine is up to 5 times slower than NixOS+KDE(5) on an older slower machine, and I don’t know why!

BACKGROUND

I installed KDE Neon 6.3 on an NVME drive in my main PC just over a week ago. It is dual-booted with Win10, which is on a separate drive.

From the outset the machine seemed sluggish, but “it feels slow” isn’t useful data. So, to try to put some facts together I span up an older machine I have that is loaded with KDE on NixOS and ran some comparison tests. This was basic stuff just using my phone as a stopwatch, but I don’t need precision as the results are pretty dramatic.

To be clear the older machine (“machine 1”) is lower spec hardware in every respect, CPU, RAM, Disk, you name it.

OBSERVATIONS

“Machine 2” (the one running Neon 6.3) doesn’t show any obvious reasons for being slow. CPU load is moderate to low, RAM use and disk I/O are minimal, no swapping.

The only possible “smoking gun” I have found so far is the the measured buffered read performance of the nvme drive i’m running Neon from looks unreasonably low, but this is using hdparm which I know isn’t really designed for SSD testing so I don’t know how meaningful these numbers are.

I have checked the forum and there are quite a few raising performance issues with Plasma 6, but I haven’t found anything quite the same (or as extreme) as this.

SOME COMPARITIVE MEASUREMENTS

MACHINE CONFIGURATIONS

Machine 2 (the newer one)

Operating System: KDE neon 6.3
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.11.0-17-generic (64-bit)
Graphics Platform: Wayland
Processors: Intel® i7-6700K 4 Core 8 Thread @ 4.60GHz
Memory: 32 GiB RAM
GPU: AMD Radeon RX 6700 XT
Motherboard: Gigabyte Z170X-GamingG1
Primary Disk: Orico 4TB NVME (Gen4 but limited to Gen 2 by motherboard)

Machine 1 (the old one)

Operating System: NixOS 24.11
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.6.44 (64-bit)
Graphics Platform: Wayland
Processors: Intel® Core™ i7-4770K 4 Core 8 Thread @ 4.00GHz
Memory: 16 GiB RAM
GPU: Intel® HD 4600 Onboard Graphics
Motherboard: Asus Z97M
Primary Disk: Crucial 512GB SATA3 SSD

SOME MORE DETAILED MEASUREMENTS

Machine 2 (the newer one)

$ hdparm -Tt /dev/nvme0n1
/dev/nvme0n1:
Timing cached reads: 43456 MB in 1.97 seconds = 22075.65 MB/sec
Timing buffered disk reads: 1360 MB in 3.00 seconds = 453.21 MB/sec

hdparm -Tt /dev/nvme1n1
/dev/nvme1n1:
Timing cached reads: 42822 MB in 1.97 seconds = 21748.21 MB/sec
Timing buffered disk reads: 7952 MB in 3.00 seconds = 2649.83 MB/sec

incans · February 27, 2025, 3:56pm

One thing that may or may not be relevant.

On “machine 2” (the one running slow) a USB device on the motherboard seems to have gone bad, so I get an endless stream of warnings of the form usb usb2-port3: Cannot enable. Maybe the USB cable is bad? in the console as the machine is booting.

Could this be causing performance problems? maybe by forcing endless re-scans of the IO devices?

johnandmegh · February 28, 2025, 4:41am

Hi - it’s definitely possible that a bad hardware device could cause cascading problems. One thing that might help narrow down possibilities is to check if similar performance issues occur when booting from a live USB, rather than the existing installed system.

Running off a USB will always be slower, of course, but it sounds like you’re getting “worse than USB” speeds as it stands now - so that might help diagnose whether or not something specific to that installation is causing trouble?

You could also try booting into a live USB of a completely different distribution, like Fedora KDE Plasma Desktop, to see if perhaps there’s something Neon-specific involved?

incans · February 28, 2025, 2:37pm

Ok, I booted from the Live image.

Supercially I would say the performance is fine, given that is IS a live image. I find this interesting though, In the live image (booted from USB):-

As the default user for the installer (“neon”) the result is-

$ time lshw
...
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.
real    0m0.387s
user    0m0.162s
sys     0m0.074s

but if I run it as root (which the program says it needs)-

# time lshw
[the word USB is displayed for as long as the program takes to run)
...

real    0m37.773s
user    0m0.962s
sys     0m0.081s

So, that particular command runs 100 times slower as root(!), but the impact is primarily in terms of real (“wall clock”) time. I have no idea what means, but it seems significant.

I am beginning to feel that either this machine or the OS install are borked. I’m also finding Ubuntu, at least in its LTS form, to be a bit clunky and old-fashioned feeling.

As it happens I have some new hardware to install. I think I might wipe this setup before I burn any more time on it, and try another base distro, but probably still with KDE as the DE, because despite the flaky bits I do like it…

incans · March 1, 2025, 1:58am

Just to bring a level of closure to this, I transferred this same installation of Neon over to another hardware platform, a more modern Ryzen 7700 AM5 system.

On this machine running the same command again, as a normal user and as root gives these results-

$ whoami
user

$ time lshw
...
real    0m0.201s
user    0m0.112s
sys     0m0.070s


$ whoami
root

$ time lshw
...
real    0m0.827s
user    0m0.711s
sys     0m0.066s

This looks like a sane result. The time to run as root is 4x slower than a normal user, vs. 100x, and the difference is almost all in terms of user CPU time, not idle real time.

My tentative conclusion is that the failing USB device on my other motherboard was causing a bottleneck, maybe triggering re-initialisation of IO devices, or re-scanning the configuration.

Not like anything I have seen before.

incans · March 2, 2025, 1:08pm

I think I have finally identified the root cause of this issue, and a workaround. And it’s pretty bizarre. I’m updating this in case anyone else runs into the same issu, because it had me stumped for days.

Summary- The Problem

Symptoms:

Machine (specifically the desktop UI) running very slow. Login, opening apps and browsing files with Dolphin were all affected
Desktop update/redraw problems, like panel widgets having no content
dmesg shows a continuous stream of warnings of the form usbX-portY: Cannot enable. Maybe the USB cable is bad?
lsusb shows the USB device that is reporting errors as a chain of hubs with no external devices plugged in, and the number of ports looks odd (in my case a 4 port hub had only 2 ports enumerated)
The lsusb command runs extremely slowly (up to 100x slower than the normal sub-1s response BUT ONLY if-

lsusb is run as root
lsusb is run with no options. Note lsusb -t or lsusb -tv do not behave the same

The Crazy Part

Over the last couple of days I rebuilt the machine experiencing this problem with-

A different motherboard (AMD AM5)
A different CPU (Ryzen 7 7700), RAM (DDR5) and cooler
A different base distro (EndeavourOS, but still KDE Plasma 6 DE)
A different kernel

And the same thing is till happening ?!

Identifying the Culprit. A Workaround

I mentioned above that the USB device that was spitting out all the error messages had no external devices shown as connected. That tends to eliminate a bad USB peripheral as a cause, as all my USB peripherals are working correctly.

However just to prove the point I progressively disconnected all my external hubs and devices, and also swapped them to different motherboard ports, without any change.

In the end, it was the “no external devices connected” state of the device that was the hint.

My new motherboard (ASRock B650 LiveMixer) has a lot of USB ports, especially on the rear panel. The same is true of my old Z170 board. I run all my main desktop devices (keyboard, mouse, tablet, camera etc.) through a 4x4 USB matrix switch, which gives me a “poor man’s KVM” to switch the devices between machines. This means I only use a couple of rear USB ports on the motherboard, the rest are empty.

I moved the main USB3 connection from the USB switch to different ports on the motherboard until I finally found the ports that are connected to the mystery controller. On the B650 this turned out to be the USB 5.1 ports nearest the top of the IO panel which are controlled by an ASMedia ASM1074 High-Speed hub

With an external device connected to one of these ports, the stream of errors reported by dmesg stopped, and the chronic performance problems seems to have gone away!

Tentative Conclusion

Some on-board USB controller chipsets, including at least the ASMedia ASM1074, but probably others as well, under Linux kernel versions between 6.11 and 6.13, but again probably including others, can fail to initialise properly if no external USB devices are connected. This can lead to symptoms including kernel errors and significant (and unpredictable) performance impacts.

The indicators for this include-

Kernel errors of the form usbX-portY: Cannot enable. Maybe the USB cable is bad?
The performance of the lsusb command is much slower (up to 100x) when run as root/sudo than when it is run by a normal user
Slow and unpredictable interactive performance, especially for desktop activities such as running programs and navigating the file system

It may be possible to work around the problem by either-

Connecting at least one external USB device to a port controlled by the problem controller
Disabling the problem controller in the kernel (I have not identified how this is done)