Performance Issue of RL9 on Raspberry Pi 4

Rocky Linux General
1

neofetch says the CPU is working @ 1.5 GHz, but the performance is far from normal.
When using 7z 22.01’s performance test it reports that the CPU frequency is only 0.6 GHz. I’ve tried to overclock it to 2.2 GHz by adding config.txt, but still only neofetch reports this frequency while CPU still working on 0.6 when doing 7z performance test.
Is it working on powersave mode? If so, how can we change it to schedutil🤔

          __wgliliiligw_,             root@raspberry-pi-4-rocky
       _williiiiiiliilililw,          -------------------------
     _%iiiiiilililiiiiiiiiiii_        OS: Rocky Linux 9.0 (Blue Onyx) aarch64
   .Qliiiililiiiiiiililililiilm.      Host: Raspberry Pi 4 Model B Rev 1.1
  _iiiiiliiiiiililiiiiiiiiiiliil,     Kernel: 5.15.55-v8.1.el9.altarch
 .lililiiilililiiiilililililiiiii,    Uptime: 36 mins
_liiiiiiliiiiiiiliiiiiF{iiiiiilili,   Packages: 735 (rpm)
jliililiiilililiiili@`  ~ililiiiiiL   Shell: bash 5.1.8
iiiliiiiliiiiiiili>`      ~liililii   Resolution: 2560x1440
liliiiliiilililii`         -9liiiil   Theme: Adwaita [GTK3]
iiiiiliiliiiiii~             "4lili   Icons: Adwaita [GTK3]
4ililiiiiilil~|      -w,       )4lf   Terminal: /dev/pts/0
-liiiiililiF'       _liig,       )'   CPU: BCM2835 (4) @ 1.500GHz
 )iiiliii@`       _QIililig,          Memory: 213MiB / 1849MiB
  )iiii>`       .Qliliiiililw
   )<>~       .mliiiiiliiiiiil,
            _gllilililiililii~
           giliiiiiiiiiiiiT`
          -^~$ililili@~~'


7-Zip (z) 22.01 (arm64) : Copyright (c) 1999-2022 Igor Pavlov : 2022-07-15
 64-bit arm_v:8 locale=zh_CN.UTF-8 Threads:4, ASM

Compiler: 9.2.1 20191025 GCC 9.2.1
Linux : 5.15.55-v8.1.el9.altarch : #1 SMP PREEMPT Tue Jul 26 04:16:30 UTC 2022 : aarch64
PageSize:4KB hwcap:887:CRC32:ASIMD
LE 

1T CPU Freq (MHz):   597   598   596   597   596   596   597
2T CPU Freq (MHz): 200% 597   199% 592  

RAM size:    1849 MB,  # CPU hardware threads:   4
RAM usage:    889 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       2361   306    750   2297  |      47329   385   1049   4038
23:       2314   322    733   2358  |      46794   385   1052   4049
24:       2240   324    744   2409  |      46123   386   1047   4048
25:       2170   329    753   2478  |      44745   384   1037   3982
----------------------------------  | ------------------------------
Avr:      2271   320    745   2386  |      46247   385   1046   4029
Tot:             353    896   3207
2

Hi! Generally speaking, the RPi’s clock speed is a function of temperature. The cores will automatically scale down as temperature goes up, to save themselves from frying. More details here: How Hot Is Too Hot for Raspberry Pi? - Blog - Raspberry Pi - element14 Community

My first question would be: What kind of cooling parts do you have on your device? I use passive heatsinks over some of the key chips myself, but an active fan is also an option. If you don’t have any, the processor is likely to get really hot, really fast.

Here’s a little handy script for grabbing the temperature of your pi - just save this to something like “rpi_temp.sh” and run it when you want your values:

#!/bin/bash
cpu=$(</sys/class/thermal/thermal_zone0/temp)
echo "$(bc <<< "${cpu} / 1000") C  ($(bc <<< "${cpu} / 1000 * 1.8 + 32") F)"

Check out your temps as you run the tests - I think anything above 75-80 C and throttling will start.

Thanks, hope this helps. I’ll fire up my own device to test later as well!
-Skip

3

O1CN015UsuJh1Jaef9sGOGV_!!2145451045
O1CN015UsuJh1Jaef9sGOGV_!!2145451045800×800 130 KB

I’m using this overkiller so temperature shouldn’t be a problem😅

1 Like
4

Hi,

perhaps (I’m guessing here!) this has rather something to do with how 7z “calculates” the CPUs frequency based upon the features it uses to perform compression. To be on the safe side, although probably a bit tedious, I’d consider running a standard Raspbian or maybe give DietPi a try and then check out what 7z reports on these OS.
If there is no big difference, then it’s probably a 7z thing. If there IS a difference in speed, then it’s a RL (or even RHEL?) thing. Which might mean that there is some kind of optimzation not available in the stack (packages, etc.) used by RL. But that’s just pure guessing as said.

Cheers, Thomas

5

Thanks for the reply. I did have other systems in the past such as Rocky Linux 8.6, Oracle Linux 8.6 (so might not be RHEL related), Ubuntu 22.04 and even an OpenWRT router system. None of them have any issues like this. But since I’ve got a spare SD card, I will try flashing RL9 again to see if the problem is gone ( if so then I’ll be more confused what caused this issue since the system is pretty much a clean one😂)

UPDATE:
I reflashed RL9 on a spare SD card and tested 7z on the absolutely clean system and it is still the same. By the way, I discovered this issue not by using 7z benchmark, but when using a KVM virtual machine. The performance was about 1/4 to 1/3 of Rocky Linux 8.6 and Ubuntu 22.04 and then I used 7z to do some performance test and found the CPU was stuck at 0.6 GHz🤔 So I think this issue can be easily reproduced?
My RPI 4B is 2GB RAM, version 1.1

6

Thanks for your research! I’ll investigate further and try to figure out why exactly Rocky 9 in particular has this issue. Super odd, because on the rpi, Rocky 8 and 9 actually have extremely similar kernel versions and firmware packages.

Will look into it more and let you know what I find! Anyone else want to help out, please feel free!

-Skip

7

Oh, one more thing - can you share your 7z performance test command? That way I can reproduce what you’re doing in the exact same way.

8

I downloaded 7z from
https://www.7-zip.org/a/7z2201-linux-arm64.tar.xz
and the command is just

./7zz b
1 Like
9

Hey, mystery solved! We have the “powersave” profile turned on the CPU governor for whatever reason by default, which locks the speed at 600 Mhz.

Fix it like this (as root):

  1. systemctl enable cpupower; systemctl start cpupower (To ensure the config file is present)
  2. Edit /etc/sysconfig/cpupower, make both the lines end like this: "frequency-set -g ondemand" (we’re changing “powersave” to “ondemand”)
  3. systemctl restart cpupower
  4. Check the CPU governor: cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor . It should now say “ondemand” and not “powersave”. You can also echo values to this file to change it on-the-fly, but the changes won’t survive reboots.

This governor controls how hard the CPU works. “powersave” (our accidental default) will keep it at the minimum frequency (600 Mhz) no matter what in order to conserve energy and keep things cool. “performance” will run at the maximum clock speed (1.5 Ghz) no matter what. “ondemand” is a happy medium that will scale the rate up or down depending on workload.

Thanks for finding this, and sorry it got overlooked. You can bet we’ll have it set correctly by default in the upcoming 9.1 release. In the meantime, I hope this helps!

-Skip

1 Like
10

Thanks very much! That proved my initial guess😅