24.7 CPU Temps

Started by ProximusAl, July 26, 2024, 03:28:26 PM

Previous topic - Next topic
Sorry, just wanted to help, not fight. Good luck to find the problem.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

On a side note: in /usr/local/etc/filter_tables.conf, you will find <ttl> (time-to-live) tags. For me, all GeoIP rhythms seem to be 86400. If they are at 1 minute for you, that would explain it. You can look at the last change times in /var/db/aliastables to find out which alias is causing this.

Also, there is an undocumented tag <updatefreq> in config.xml, which is probably translated into <ttl>, if set. IDK how that was modified if it is not exposed in the GUI, but who knows?

All I can say is that calling update_tables.py manually takes 4 seconds here but modifies only a few aliases. I imagine that processing of geoip aliases takes a lot longer, but in my case, this is done once per day only.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

I apologize if I sounded argumentative, was just trying to relay what I'm seeing. I genuinely only take issue with one person in this thread.

One note, I'm currently limited to what I can access via web GUI...

I checked my config.xml and <updatefreq> was only set for one 1 alias (not the Geoblock), of which I updated it so it's no longer set either... That had no impact, however.

Playing with Geoblock further, I have to get the number of current table entries below 100,000 (only 1/10th of the Geoblock list) for there to be any impact to temps and utilization.

I'm also curious about what exactly is happening when update_tables.py runs and the task it's performing, since it's not actually updating the aliases. If it were, I assume I'd see changes to the "Last updated" timestamp everytime it runs. However, the time stamp is only updating once a day based on Cron schedule.

For me the following somehow works:

Setting the tunable "dev.hwpstate_intel.*.epp" to 80 seems to avoid too much spiking of the CPU and results in a sane behaviour of the temperature widget.

I missed the fact that for newer CPUs the powerd daemon does not work.
As i don't need very much processing power for my setup there is no need for higher frequencies.

Hardware: J6412 Protectli VP2420

Sorry to bring up an old thread, but this latest 24.7.7 update seems to have helped reduce the CPU utilization problem. I'm still not at pre-24.7 levels, but it's definitely a welcome steep drop I can see in my health reporting charts. Another user in the update thread on Reddit has posted the same positive observation.

Does anyone know what changed that improved this?

Holy Heisenberg, Batman.

Sorry, that related to the general problem of measuring temps affecting temps, and I am not sure how to delete it from this context.
Deciso DEC697
+crowdsec +wireguard

Did not want to start a new thread on cpu temps if possible. Have read through this thread and am trying to understand as best as is possible. I'm not at all very well educated with opnsense/firewalls and such. After the update to 27.7.7 my protectli unit is 20c higher from high 40c to high 60c. I have had a usb fan (not drawing power from unit) since first install. I see the spikes, yes, but it never goes down to even 50's c. I also lost my zenarmor cloud connection and haven't been able to reconnect. Need an "opnsense for dummies" type of reply as so much written here is above my level of comprehension. Thanks for your understanding.