24.7 CPU Temps

[meyergru]

Sorry, just wanted to help, not fight. Good luck to find the problem.

[meyergru]

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.

[irrenarzt]

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.

[MenschAergereDichNicht]

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

[irrenarzt]

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?

[passeri]

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.

[N0ttyT3chy]

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.

[inorx]

Deleted as construtive solution oriented contributions do not seem to be respected.

[franco]

Maybe it's time to stop obsessing over temperature differences in a known good CPU temperature range. Technology definitely does not care how you like your temperature to be reported anymore.  ;)


Cheers,
Franco

[inorx]

N150 running opnsense: UI reports core tempreture +15 degrees above cli.
N305 running proxmox: UI reports core tempreature with 0 degree difference to cli.

These are facts, not obessions. Just to put that right.

I have understood you're not interested in improving this and contribution is not welcome.

[passeri]

@inorx, temperature measurements may be momentary facts. The obsession is over the display.

If the GUI tells me my routers are running in the 35-70 range (actually 50-54 in my case) then why would I care what it "really" is? I know that number will be lower anyway. If the GUI consistently shows 70 or so while CPU and load factors are low then check the thermal connections, ambient air, ventilation. If load, CPU and thermals are all high then the issues are load and performance.

Temperature display is a crude measure. Rarely does anyone need it "accurately" and if you do, there is sysctl dev.cpu but something else will also need cross-checking.

I thought your approach to measurement was interesting, by the way, but in my experience it just does not really matter.

[franco]

> These are facts, not obessions. Just to put that right.

The important bit is asking to address the skew reported by the hardware in a software that has one single shared way of asking both hardware for their temperatures.  All we can do is obscure the fact that the hardware reports its temperature hotter than the other hardware and I don't want to obscure that any more than I've already done, because in reality I don't even know which of these two platforms needs to apply the skew and which doesn't.


Cheers,
Franco