Anyone know why my CPU speeds would more than double with this release? The increase specifically aligns to when I upgraded from CU195 to CU196. Nothing else has changed.
“model_string”: “Intel(R) N100”
What’s the used governor?
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Have you rebooted since the version 195 before upgrade?
For me, the frequency graph changes almost every time I reboot:
I deduced that the data collection function isn’t really adapted to this processor.
But apparently, this has no impact on the firewall’s operation or temperature.
performance
performance
performance
performance
Then it is your CPU deciding to change its clock speed. We are targeting the maximum clock speed at all times.
1 Like
I rebooted and now the CPU is back down to where it was before the change. This behavior seems very strange! Why would the CPU frequency change just because of a reboot?
Also can I make the cpupower changes permanent on reboot?
This is your CPU deciding what it likes to do. Maybe a firmware update can help?
2 Likes
| Governor | Description |
|---|---|
| performance | Run the CPU at the maximum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq. |
| powersave | Run the CPU at the minimum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq. |
| userspace | Run the CPU at user specified frequencies, configurable via /sys/devices/system/cpu/cpuX/cpufreq/scaling_setspeed. |
| ondemand | Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases. |
| conservative | Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand. |
| schedutil | Scheduler-driven CPU frequency selection |
1 Like
echo schedutil | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Even my personal hypervisors run fine with schedutil.
Set governor, for example schedutil (permanent):
Instead of adding a kernel parameter In GRUB, open/edit the crontab with: crontab -e and add the following in a new line at the bottom:
@reboot echo "schedutil" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
With cpufrequtils installed you may edit the /etc/default/cpufrequtils and change to GOVERNOR="schedutil"
Or you add a kernel parameter by editing the cmdline: nano /etc/kernel/cmdline. Add a line GRUB_CMDLINE_LINUX_DEFAULT="quiet cpufreq.default_governor=schedutil", safe the file, do Grub Update and finally update-initramfs -u.
Edit: If your CPU supports Intel Speed Shift, you may not need to change anything. With the governor performance and Intel Speed Shift enabled, the clock will still be reduced.
1 Like
I don’t know why, but cpupower says I only have performance or powersave as options. I thought ondemand was supposed to be the default.
Install the addon cpufrequtils and try again.
This add-on is deprecated.
1 Like
Yes, with core 197 it will be replaced.
This processor constantly changes its frequency as needed
See with :
watch -n 0.5 "grep MHz /proc/cpuinfo"
On console.
There’s no point in trying to fix its frequency.
Edit : Doing so unnecessarily reduces its performance.
For minimal power consumption gains.
1 Like
If you look at the graph I originally posted above, you’ll see that frequency changing is not the issue. It is that there is some elevated level of CPU use that changes when reboots happen. It is a factor of ~2x depending on the reboot. Currently this reboot it is now back to the lower end of frequency.
All else being the same, it’s not normal. It doesn’t scale up and down, it becomes range bound.
I doubt that. The kernel provides several CPU governors which can be configured and here it’s performance and therefore never changes the CPU frequency.
It is supposed to stay up there. We don’t want to clock down. As some people have already stated, this will change with the next update.
If you have an Intel CPU schedutil is not supported but you can use powersave instead if you prefer that. You can run the command as usual in rc.local.
1 Like
Since I don’t run IPFire on native hardware anymore, I can only tell that the N100 and N305 support for example schedutil because it’s in use with proxmox.
OT: this topic should be outsourced, because it has nothing to do with core 196.
2 Likes
Yes, the Celeron series, Atom series and probably a few other smaller processors don’t support P-state, but the larger ones only support that.
I deduced that it’s the way the graph is constructed that gives this irregular appearance.
I haven’t noticed anything abnormal in the way IPFire works.
Yes: The subject of this post has nothing to do with this “problem” (which isn’t one).