I noticed that IPFire has started taxing my cpu more since Jun 24. Normally I switch on everything, but any ideas as to which component specifically caused the hike? IpFire still works fine, but I might need more cpu capacity if the trend continues. So looking to understand mostly. TIA
Mine doesn’t show any jump in the cpu frequency, just the usual up and down of around 50MHz.
Maybe something was changed in the driver for your cpu in the update from CU185 to CU186, which was released on June 13th 2024.
In CU186 the kernel was updated from 6.6.15 to 6.6.32. Maybe something changed the frequency settings of your processor or changed the way the number was calculated.
There certainly isn’t any increase in the loading of the cpu system. The CPU usage level has stayed between 0.8% and 7% of usage on my system over the last year.
I would not worry about needing more cpu capacity unless your cpu usage of the blue and red colours together are filling most of the graph.
I noted it is using pstate in passive mode, perhaps that’s the reason
Perhaps if I remove the cpufrequtils package, it might go back to active mode…
I tried pstate in active mode, it got worse, like it was almost to trigger happy, max to min and back at breathtakning speed. So I went back to passive and set the governor to conservative. This lowered the cpu speed best. As long as I don’t need the higher frequencies my reasoning is simple, higher speed = more heat = higher risk of failure. It’s a passively cooled system and in the summer it needs a cool head. It has not impacted the responsiveness of the FW at all, so I am still wondering why is it clocking higher than it needs to be? As was pointed out, still 99% running idle, which makes it weirder in my mind. Anyway, clocks are now more to the lower end of the scale, where they should be, given the amount of idle time.
I think I disagree with this statement - for a couple of reasons:
First of all the amount of compute that you will need is roughly the same, no matter if the CPU clock is lower or higher. Processing a single data packet takes the same amount of CPU cycles.
If your CPU was now in absolute deep sleep and would wake up to process a packet, there might be two options how to do this: Either clock to the absolute maximum and process the packet as fast as possible, or just wake up a little bit and take your time. Back in the day of the Intel Pentium 4, other laws applied to this, but with a modern processor, the second option is the worst as it usually consumes more energy. That is why constantly clocking up and down is better and by the way will give you a network with less latency. So we would always configure IPFire to run in the first mode and actually clock up the CPU whenever it is needed.
Secondly, we just assume that your hardware can do this. If your system actually struggles in the summer, then it is a bad design. I would say that most (if not all) smaller IPFire systems are passively cooled these days and I can at least only vouch for the Lightning Wire Labs appliances, that you can run them on 100% CPU all of the time, even on a hot summer day when the air con does not keep your office remotely cold any more. And as mentioned above, clocking down is potentially generate more heat.
I have to agree with @ms on this.
Through experiments that I have done before, a stable clock speed where there is the least amount of frequency drift, is the best conditions of the least of amount of heat and best sustained transfer rate has been observed.
The processor is a N4200 Pentium, FYI. It was clocking just under 1Ghz before and since june last year it averages around 1.8Ghz, with a bigger variance… Heat is always dissipated energy and it stresses the circuit. By setting it to conservative, I see the followiing. Average is now around 1.1Ghz, which is only marginally higher than it was before., CPU temp is down 5 deg C, coming to around 38C. There is no change in the performance of the network, everything works fine. I do see CPU speed go to max, but now perhaps once or twice a day, instead of every minute. In other words, instead of being trigger happy, it is more deliberate. And yes, it needs the same cycles, but if the logic setting the clock speed is consistently setting it higher than it needs to be, it wastes energy. With a component that is on all the time, this is a consideration.
Now this might be because this is not a current model, and I might be seeing the gap of new software on ageing components. But in this case, if the average is 900Mhz, and then doubles in a short period, when the demand on the network is constant, it points to a change in the behaviour of the system. I set the CPU governor to be more careful and it now averages around 1.1 Ghz, which makes more sense to me. Thermally, things are where they were before, perhaps up a degree, but that’s fine. If the system is idle for 90%+ of the time, there is no reason it should suddenly double the clockspeed, that number has not really changed. Now if I saw that something was gobbling up the clocks, and the speed increase was related to altered processing speeds, I’d agree, and there would be no change required. But as that was looked at based on the first response, I ruled that out.
As for the cooling, passive systems rely on the delta in temp, so any cooling capacity you have, is lower when the ambient temp goes up. Now if the component you’re cooling is getting hotter, you are simply reducing cooling capacity from both ends. So if I can do something about one end, it keeps my reserve higher for the odd super hot day, when I might need it. So it therefore a way to secure a continued working system. And running at 100% all the time is like clipping in an audio amp, no headroom is simply not a desirable state.
Any system has an operational bandwidth, and I want mine to hover in the lower half of that bandwidth. When it starts working in the higher end, I need to find out why, given there’s no computational increase, or increase traffic, no new components between before and after, my options are, reconfig or buy a new appliance. I tried active p_state, didn’t work out and then a new gov, and that brought me enough results to let it stay where it is now. It was never a question of can it handle it, it could, but the way it was handled had changed for no reason. We’re now back where we were and everything is still working, being handled. Throughput is still the same, speedtests have not changed and frankly, my ISP is a bigger worry there than my CPU governor.
Have you activated IDS or some new setting that might cause additional CPU work? Maybe you should also try to shut the system down, wait a minute and re-start again.
IPFire without cpufreq-utils installed set the cpu to “performance” and with cpufreq-utils installed it defaults to “on_demand” on cpu’s that support it.
But “pstate” cpu’s does not support “on_demand” so it set it to “powersave”.
So if you install cpufreq-utils the system on pstate cpu’s is much slower…
Have kept the conervative governor. I think this image shows it best:
This is over a year. No config options have been changed during this period. You see it jump up, and then calm down when i force the governor. It has settled just above the average of before, but generally well down from what it was. So for now I am assuming the logic of governor has changed and conservative is more like the old logic.