After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking
-
Those values just reflect the sysctls for the cpu frequency.
Check:
sysctl -a | grep freqCheck it with and without the dashboard being displayed in a browser.
Steve
-
@stephenw10 Thank you for your expert guidance
as usual, this is always appreciated. And...when not following it, I usually pay a painful price. In this case, I've had to go back to 2.6CE, as my 23.01RC upgrade has been highly unstable...and I suspect it is because I "upgraded" the Realtek driver package to 198, and ran into a slew of problems, not just with crazy processor overclocking reporting. You have been very helpful with that one in another post string on the netgate forum.So...given a strongly possible "bad" upgrade with a bad driver to 23.01RC that may have resulted in numerous consequences, I'm going to put this issue on pause. I've gone back to 2.6CE with the known good 197 Realtek driver package, and will probably attempt another upgrade next weekend.
As always, thank you for your expert advice. I'm going to keep this post and (once I go back to 23.01RC), reference it if I see the "bad" overclocking reporting.
-
Mmm, I'm seeing similar results. But try running:
sysctl dev.cpu | grep freqinstead.
It appears the loading created by running 'sysctl -a' is sufficient to cause the CPU to ramp up to max speed with the hiadaptive profile selected.Steve
-
@stephenw10 at the time, I also saw high CPU clocking with PowerD set merely to adaptive.
Having gone back to 2.6CE, it is showing more what I was used to...much lower clocking
CPU Type Intel(R) Core(TM) i3-8145U CPU @ 2.10GHz
Current: 500 MHz, Max: 2301 MHz
2 CPUs: 1 package(s) x 2 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No -
Yes, it appears the powerd code is a lot more responsive in 23.01 such that merely having the dashboard open will cause it to ramp up to the maximum frequency.
-
@stephenw10 THAT is crazy to overclock for the dashboard...especially since 2.6CE shows such a low processor hit with the dashboard open...
So...the question is, if this is "real" overclocking, its bad for any system...lots of power draw, lots of heat...for just a dashboard console being reviewed. I'd nudge that should get a formal bug/issue report. If it's illusory...reporting high values, but reality is different...its a minor thing, that can be addressed at leisure.
-
@stephenw10 said in After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking:
Yes, it appears the powerd code is a lot more responsive in 23.01 such that merely having the dashboard open will cause it to ramp up to the maximum frequency.
That means this issue is also present in 2.7.0 CE? (powerd is part of freeBSD)
-
@stephenw10 said in After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking:
Yes, it appears the powerd code is a lot more responsive in 23.01 such that merely having the dashboard open will cause it to ramp up to the maximum frequency.
Would a use of powerdxx be helpful?
-
Potentially. It's a lot more configurable.
For most firewall users it's not a high priority though.
You could open a feature request.
-
@stephenw10 said in After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking:
You could open a feature request.
I think I wait until 2.7.0 is out and if the problem persist I'll make that feature request.
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
F fireodo referenced this topic on
-
This problem has persisted beyond the 23.01RC stage. So much so that I reverted back to 22.05 (yay ZFS).
These temps were taken during the same types of general firewall usage. The 23.01 temps were taken just before I reverted to 22.05 and those temps were taken after they had settled a bit.
[22.05-RELEASE][root@endpoint]/root: sysctl hw.model hw.machine hw.ncpu
hw.model: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
hw.machine: amd64
hw.ncpu: 8[22.05-RELEASE][root@endpoint]/root: sysctl -a | grep "dev.cpu.*.temperature"
dev.cpu.7.temperature: 65.0C
dev.cpu.6.temperature: 65.0C
dev.cpu.5.temperature: 66.0C
dev.cpu.4.temperature: 67.0C
dev.cpu.3.temperature: 68.0C
dev.cpu.2.temperature: 68.0C
dev.cpu.1.temperature: 67.0C
dev.cpu.0.temperature: 68.0CAnd the nasty temps in 23.01
[23.01-RELEASE][root@ENDPOINT]/root: sysctl -a | grep "dev.cpu.*.temperature"
dev.cpu.7.temperature: 91.0C
dev.cpu.6.temperature: 91.0C
dev.cpu.5.temperature: 91.0C
dev.cpu.4.temperature: 92.0C
dev.cpu.3.temperature: 94.0C
dev.cpu.2.temperature: 95.0C
dev.cpu.1.temperature: 93.0C
dev.cpu.0.temperature: 94.0C -
@kc515 See if this thread helps
https://forum.netgate.com/topic/177918/issues-with-cpu-frequency-after-upgrade-23-01/4 -
Thanks Steve, will check it out after COB today.
-
A C2758 won't have Speed Shift. What is that device, is it passively cooled?
.> 90°C is worryingly hot in any circumstances.
-
Passive heatsink on die but I am dragging air across that with 3 back mounted 2" Noctua fans.
Apologies for the partial answer, re-read your post.
It's a SuperMicro MBD-A1SRI-2758F-O with 32GB DDR3 Ram housed in a SuperMicro CSE-505-203B 1u chassis with 3 Noctua NF-A4x20 PWM fans pulling air out the back.
-
@stephenw10
As you correctly stated, dev.hwpstate_intel.X.epp had no effect on the issue. I had all 8 cores set to almost max efficiency and it's clear my CPU does not support it.dev.hwpstate_intel.0.epp CPU 0 Speed Shift Level 95
dev.hwpstate_intel.1.epp CPU 1 Speed Shift Level 95
dev.hwpstate_intel.2.epp CPU 2 Speed Shift Level 95
dev.hwpstate_intel.3.epp CPU 3 Speed Shift Level 95
dev.hwpstate_intel.4.epp CPU 4 Speed Shift Level 95
dev.hwpstate_intel.5.epp CPU 5 Speed Shift Level 95
dev.hwpstate_intel.6.epp CPU 6 Speed Shift Level 95
dev.hwpstate_intel.7.epp CPU 7 Speed Shift Level 95I didn't let it get as far in to thermal runaway this time but it was continuing to climb and the CPU stayed close to the max rated speed of 2600Mhz.
Max Speed: 2600 MHz Current Speed: 2400 MHzDid a quick snapshot of what was going on before I rebooted in to 22.05 again.
There was a busy grep that I didn't initiate running but otherwise idling along.[23.01-RELEASE][root@ENDPOINT]/root: top
last pid: 77152; load averages: 1.88, 1.90, 1.69 up 0+00:55:47 11:53:34
68 processes: 3 running, 65 sleeping
CPU: 14.4% user, 0.4% nice, 3.8% system, 0.0% interrupt, 81.4% idle
Mem: 895M Active, 317M Inact, 688M Wired, 29G Free
ARC: 173M Total, 62M MFU, 104M MRU, 152K Anon, 1127K Header, 4973K Other
114M Compressed, 271M Uncompressed, 2.38:1 Ratio
Swap: 2048M Total, 2048M FreePID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
87135 root 1 134 0 338M 311M CPU3 3 2:13 98.63% grep
87013 unbound 8 20 0 183M 129M kqread 0 1:07 9.24% unbound
482 root 1 68 0 144M 81M accept 7 0:53 1.03% php-fpm
13618 root 1 20 0 71M 43M piperd 7 0:02 0.24% php
59673 root 1 68 20 13M 3148K piperd 5 0:01 0.24% sh
88623 root 1 20 0 14M 4104K CPU1 1 0:00 0.18% top
95918 root 1 20 0 31M 11M kqread 5 0:14 0.13% nginx[23.01-RELEASE][root@ENDPOINT]/root: ps -ef 87135
PID TT STAT TIME COMMAND
87135 - R 4:24.67 LOGNAME=root LANG=C.UTF-8 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin PWD=/root USER=root HOME=/root SHELL=/bin/sh MM_CHARSET=UTF-8 BLOCKSIZE=K grep -vF -f /tmp/dnsbl_tld_remove.tsp /var/unbound/pfb_dnsbl.tLet me know if there is any other info that would help track this down.
Thanks,
KC515 -
Hmm, well I would say you definitely need to look at your cooling solution there because that should never get that hot. Even running at 100% on all cores. Do the fans not spin up with CPU temp?
But that grep seems unexpected. Looks like pfBlocker converting it's lists for TLD which requires a lot of CPU cycles but it should finish after a few minutes.
Steve
-
@stephenw10 It never did until 23.01. Been running CE and 22.0X for little over a year and average CPU temp hovers around 65C.
If the cooling solution worked under the older versions and still does, something has to be afoot with the 23.01 C2758 combo.
-
@stephenw10 said in After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking:
But that grep seems unexpected. Looks like pfBlocker converting it's lists for TLD which requires a lot of CPU cycles but it should finish after a few minutes.
I’ve noticed the same huge grep spikes which I never saw before. You can also see it if you force an update in the GUI and the panel showing progress will actually time out and need to be told to go into view again several times during an update.
I got mine under a bit more control by turning off de duplication and CDIR processing.
-
@stephenw10 said in After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking:
Looks like pfBlocker converting it's lists for TLD which requires a lot of CPU cycles but it should finish after a few minutes.
Normally, but there's a bug in recent versions where it can take quite a long time. Workaround is to disable the Wildcard Blocking (TLD) option.
