After upgrade from 2.6CE to 23.01RC pfSense Plus CPU Type info shows very high CPU clocking

RK0

So, after upgrading from 2.6CE to 23.01RC pfSense Plus, under System Information > CPU Type the info shown on the current CPU clocking rate is generally shown to be SUPER high...much higher than before under 2.6CE...with the processor perpetually held in an overclocked state.

This is with PowerD set to "adaptive", which is the setting I used for both 2.6CE and 23.01RC.

Example info cut and pasted from CPU Type session, note "Current" indicates an overclocking state, exceeding the processor normal base frequency of 2300Mhz per ...which the i3-8145U can do, its just pretty much ALWAYS shown as being held in an overclocked state per the processer specs at https://ark.intel.com/content/www/us/en/ark/products/149090/intel-core-i38145u-processor-4m-cache-up-to-3-90-ghz.html, whereas before it would generally range between 400-800Mhz in pfSense 2.6CE, spiking beyond that only occasionally.
I added the bold text in the cut and paste below to show the sustained overclocking value

Intel(R) Core(TM) i3-8145U CPU @ 2.10GHz
Current: 3705 MHz, Max: 2300 MHz
2 CPUs : 1 package(s) x 2 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

Also curious...processor load average shows as pretty low, so usually overclocking would be unnecessary

Load average: 0.44, 0.41, 0.32

CPU usage is also low, generally in the 11%-20% range.

The system does seem to be functioning normally, and temperatures are in a reasonable range...which also makes me think CPU clocking after the upgrade to 23.01RC is being erroneously reported as higher than it actually is.

Would that constitute a bug, if the CPU clocking performance is erroneously reported in 23.01RC with possibly an incorrect value?

RK0

Some additional info...

I set PowerD to minimum, just to see what the processor clocking values would be....

They still show the processor held in a perpetual overclocking state
Intel(R) Core(TM) i3-8145U CPU @ 2.10GHz
Current: 3405 MHz, Max: 2300 MHz
2 CPUs : 1 package(s) x 2 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

Again however, processor Load average remains low at
Load average: 0.41, 0.40, 0.35

and CPU usage remains low, going from a low of 10% to a high generally of under 20%

This would again imply an incorrect clocking state being polled and presented. Not a big bug if so, as long as the system is not ACTUALLY being held perpetually in an overclocked state.

stephenw10

Those values just reflect the sysctls for the cpu frequency.

Check: sysctl -a | grep freq

Check it with and without the dashboard being displayed in a browser.

Steve

RK0

@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.

stephenw10

Mmm, I'm seeing similar results. But try running: sysctl dev.cpu | grep freq instead.
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

RK0

@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

stephenw10

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.

RK0

@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.

fireodo

@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)

fireodo

@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?

stephenw10

Potentially. It's a lot more configurable.

For most firewall users it's not a high priority though.

You could open a feature request.

fireodo

@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.

KC515

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.0C

And 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

SteveITS

@kc515 See if this thread helps
https://forum.netgate.com/topic/177918/issues-with-cpu-frequency-after-upgrade-23-01/4

KC515

@steveits

Thanks Steve, will check it out after COB today.

stephenw10

A C2758 won't have Speed Shift. What is that device, is it passively cooled?

.> 90°C is worryingly hot in any circumstances.

KC515

@stephenw10

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.

KC515

@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 95

I 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 MHz

Did 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 Free

PID 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.t

Let me know if there is any other info that would help track this down.

Thanks,
KC515

stephenw10

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

KC515

@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.