After installing update 197, I’ve noticed a significant drop in CPU core frequencies on my Intel N100, 8Gb RAM system. As shown in the image I’ve attached, this behavior aligns with the update notes, which mention improvements in energy efficiency and CPU temperature. From that perspective, I think it’s a great enhancement.
However, I’m experiencing a noticeable performance hit, particularly with QOS enabled. Before the update, I had a 600Mbps connection capped at 590Mbps via QOS, and it consistently reached that limit without issue. Now, post-update, I can’t get past 530Mbps with QOS active.
It seems the new frequency scaling is limiting the CPU’s ability to handle traffic shaping as efficiently as before. Is there any way to manually configure or override the CPU frequency behavior to allow higher performance? I’d prefer to go back to the previous performance levels, even if it means slightly higher power consumption—the system felt much more responsive and capable.
Thanks in advance for any insights or suggestions!
After doing a bit of research, I came across another topic that mentioned the possibility of manually setting the CPU governor. I noticed that the /etc/sysconfig/cpupower file didn’t exist on my system, so I created it myself and added the following line:
GOVERNOR=“performance”
After applying the change and switching to the performance governor, I did notice a slight improvement in throughput with QOS enabled. The system feels a bit more responsive, and the CPU frequencies are now staying consistently higher.
That said, it’s still not quite at the level it was before update 197. I’m getting better results than with ondemand, but I’m still falling short of the previous performance ceiling I had before the frequency scaling changes.
Considering that N100 are soldered-on SoC, would you please share the mainboard manifacturer and model? The same if the device is one of the many small boxes available on the market.
Don’t forget that some of these boxes/mainboard allows to configure PowerLimit (PL) on bios, and test/tweak settings among power availability and governor could lead to a balanced result about efficient power consumption while delivering adequate (for your standard) performances.
Since 15 years there’s actual no need to have full bore power request from a lot of CPUs… it’s only wasted energy.
I would find it very surprising if clocking down the CPU would have this kind of impact, because it should simply clock back up when it is being needed.
Did you make any other configuration changes since then? It could simply be that the benchmark is not free from any environmental influences as you are quite close to the value that you actually want.
I should clarify that my tests haven’t been exhaustive—I’m a home user and don’t have access to lab-grade tools or multiple systems for comparison. That said, I’ve consistently run speed tests using the Ookla CLI tool from the IPFire server’s command line, along with Cloudflare’s speed test.
With QOS enabled, I’ve observed clear differences in maximum throughput depending on whether the CPU governor is set to performance or left at powersafe. The performance mode consistently gives better results. Additionally, when I disable QOS entirely, I reach my full contracted speed, which is expected behaviour..
Unfortunately, I didn’t run these tests before upgrading to version 197, so I can’t provide direct comparisons with 196. However, I started investigating this because I noticed a general drop in responsiveness and throughput after the upgrade, which led me to explore CPU frequency behavior and governor settings.
I use the IPFire speedtest-cli with a script that runs it every 2 hours and collects the data for me.
Each time you run the speedtest it uses a different server but even if you specify the same server each time the path between you and that server will vary.
My data is running at an average of 1000Mbps but the spread in values is between 1090Mbps down to 900Mbps so around +/- 10% spread for the majority of measurements but there is also a significant tail that goes down to 300Mbps.
This tail is influenced by a few issues with the test itself
A path can be chosen by the test that has a very limited speed performance because the speed in these tests will be influenced both by speed capability of the slowest part of the path used.
The test is carried out on a path with a sudden high traffic burst.
Some of the measurements in the slower tail are linked to the use of a range of servers that are not capable of running at a speed to test my 1000Mbps connection. They are always slower performing in all measurements when they are used.
The path distance in the tests varies between 20km and 50 km with occasional tests ending up at several 100km.
It sounds like you configured your bandwidth to be 2% below the connection speed, and you are now measuring 10% below your configured bandwidth. As has been suggested, those numbers are within the margin of normal variation, especially with QoS in the picture.
You might try testing at different times of day to see if speed correlates with that. Also, disable QoS and test speeds over different times of day. You might find that whatever drop in speed you noticed is not tied to the changes in CU197.
Hello @micaco , I hope that following words will help the prosecution of the topic.
Your observations are interesting, but on this side of Internet no one knows your environment… except
SoC, RAM
however with no information on how it’s delivered at your place, plus the observation you delivered.
What follows is some sort of description which should deliver a better understanding of your setup.
Hi,
I’m running IPfire on a old desktop computer repurposed as firewall.
Hardware is HP DeskPro 490 G3, Intel i7 6700, 8gb of DDR3 1333 RAM, latest bios available (02.47 Rev.A).
GREEN network is on the integrated network card, RTL8111 chip
RED network uses TP-Link PCIe ethernet (TG-3468) with RTL8169 chip on board.
Old SATA SSD as storage.
RED network is configured as 172.30.128.0/24, using the ISP CPE as gateway (SFP connection for FTTH). ISP delivers to me 600d/250u mbit/s
GREEN network is configured as 192.168.99.254/24
I have configured on my IPFire installation QOS, nut, ncdu, cpufrequtils and I use it as DHCP server for my GREEN network
This would provide context and information for a better understanding of your status and… what might happen.
just to confirm that the CPU freq is affecting also my topic (see previous reply). In my case it is a Intel Celeron CPU N2930, 16Gb ram, 16Gb mSATA (MLC), RED/GREEN/ORANGE/BLUE on 4 different eth ports ( NF9HG :: JNF9HG :: Intel Celeron Bay Trail N2930 :: JETWAY COMPUTER CORP. ) System has been running for many years 24/7 without a single problem, with core 197 I noticed issues and raising the clock fixed all of them (at least for now..)
see the reply from Juan Moreno:
”I noticed that the /etc/sysconfig/cpupower file didn’t exist on my system, so I created it myself and added the following line:
GOVERNOR=“performance” “
login via ssh as root, create the file and set the governor. You can modify frequencies with the “cpupower” command in console.
cpupower frequency-info
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: Cannot determine or is not supported.
hardware limits: 700 MHz - 3.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 700 MHz and 3.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.70 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
I have switched to “performamce” - and immediately the CPU jumped to 3,38 Ghz from 1,700 Ghz
cpupower frequency-set --governor performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
[root@ipfire sysconfig]# cpupower frequency-info
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: Cannot determine or is not supported.
hardware limits: 700 MHz - 3.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 700 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.38 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
I have seen a drastic reduction in cpu frequency on three different IPFires I manage. But, I have not noticed any reduction in performance on any of them.
I have noticed in the graphs that the average load is slightly higher since cpu frequencies dropped. But as far as I can tell, there is no noticeable impact to users’ network performance.
Here is a different IPFire with a weaker processor. It’s easier to see the load change at the time of update on Sept 21. Again, no noticeable difference in networking performance.
Hardware Overview:
IPFire Installation:
Network Infrastructure:
