I’ve got a handful of Dell Latitude 5520s that I’ve been tasked with chucking Linux on and Tumbleweed seemed like a good idea to try out. Everything installs fine but I noticed having a couple of them running Ubuntu that the Tumbleweed machines were consistently ~20% slower running stuff like Blender.
The good ol’ BMW render takes consistently around 2 minutes and 30 seconds on Ubuntu 24.04.1 LTS and 24.10, as well as Fedora Workstation 41. The same machines when Tumbleweed is installed complete the same render in about 3 minutes and 15 seconds. I didn’t have a Leap ISO handy but its downloading now so I can give it a crack.
I had a look at clock speeds and thermals to see if it was a throttling thing, there doesn’t appear to be any thermal throttling going on with any of the OSes. All of them jump into PL2 when an all core load starts and run at 4GHz until PL1 kicks in and they drop down to the base clock of 2.6GHz. They sometimes go up a little bit, I’ve seen 2.9GHz all-core while running the s-tui stress test while staying within the ~28W PL1 limit.
Its not the same in Tumbleweed though, clock speeds are consistently 400MHz lower under an all-core load. 2.2GHz during Blender and 2.5GHz under the s-tui stress test. The clock speed difference makes the performance difference check out.
I’ve tried a couple of things, the easiest being the power profile presented in Gnome. The SMBIOS power profiles don’t make a difference, neither does changing the cpufreq governor between performance and powersave. Disabling intel_pstate in GRUB and using acpi-cpufreq also hasn’t done the trick. If anything it seems to flip between 2.1GHz and 2.2GHz more without intel_pstate.
Any ideas? I like Tumbleweed so far and would like to keep the new software thing.
Welcome to the forum good you found out it has to do with processor speed being limited in Tumbleweed.
Looks like you are running on a laptop with a ~28W limit. I am not sure how you detected the cpu clocks are lower (which tools) but can you run something I am familiar with and that has nice output:
Sure can, here’s what turbostat reckons when running a Blender job on Tumbleweed. The clock speeds match what I’m seeing in btop, s-tui, the Vitals Gnome extension, etc.
I set the governor back to the default powersave option after testing if setting it to performance had any impact. Confirmed that it doesn’t.
localhost:~> sudo cpupower frequency-info
analyzing CPU 5:
driver: intel_pstate
CPUs which run at the same hardware frequency: 5
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 4.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 4.40 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.09 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
I’ll fire up Fedora and do the same there. Will provide an edit in a few minutes.
Cheers for having a look, pretty interest to see what the go is.
I don’t have those files on these 1145G7s either unfortunately.
Not sure that the ten second interval was sufficient to capture the PL2 boost accurately. Seems like Tau is only ~8 seconds. Here’s something a little more granular, cut just after the CPU settles into PL1 boost.
s-tui makes it a little prettier. You can see the spike up to 60W while PL2 is active before temperature and power limits start arm wrestling the clock frequency into the PL1 state.
Interestingly the short duration one/two core boost clocks still hit 4.4GHz in Tumbleweed. Had a look at what the power limits and tau values are supposed to be but they don’t make much sense.
Any ideas why? I don’t have any idea what sets these values, I always thought the device manufacturer set them depending on how they’d designed the VRMs and cooling solution.
Nice to see the s-tui pictures, I installed it and looks great but it give me not more insight.
What is good about this problem is that you have one OS running fine and the other OS showing the problem on the same computer which that solving the problem should be a matter of dumping all settings and comparing them. Easier said then done but you could start by running o both OS’s:
cd /sys/devices/system/cpu
find ./ -type f | xargs tail -n +1
Save that output to a file and compare the files for both OS’s.