Upgrade to 2.3 CPU Running Harder
-
How do I run ./show_cpufreq.sh ? I tried from command prompt under diagnostics. It shows as not a good command.
So are the lower run states missing from my CPU Xeon 5148?
This actually a script i made for myself because I'm lazy…
Just a sysctl with a grep to get current cpu speed. -
In the freeBsd patch quoted above they say
These CPU speed control techniques are usually unhelpful at best.
I can confirm this. On my Supermicro a1sri-2758f for example, enabling PowerD makes things worse. NAT throughput is only about 400Mbit/sec for the first 8-10 seconds - that's the time required for the CPU to scale up
I don't blame you for turning it off. But CPU scaling happens so quickly, the OS can't even keep up. That's why Intel moved so much of this power management into the silicon. Voltage and C-state changes happen before the OS even has a chance to find out. Whatever you were seeing is completely broken, and not caused solely by CPU frequency scaling.
It sounds like the software side of power management in FreeBSD isn't great, which is no surprise. This thread is about why 2.3 is running at higher clocks. Folks should benchmark their local workloads and determine which of the available settings strike,the right balance for them.
-
Did the changes recommended by Paftdunk and can confirm that it worked for me.
[2.3-RELEASE][admin@fw01.tessier-ashpool.int]/root: ./show_cpufreq.sh dev.cpu.0.freq: 149[2.3-RELEASE][admin@fw01.tessier-ashpool.int]/root: sysctl -a | grep freq_levels dev.cpu.0.freq_levels: 3193/9875 3192/9125 3059/8250 2926/7500 2793/6875 2660/6250 2527/5750 2394/5250 2261/4750 1978/4156 1695/3562 1413/2968 1197/2750 1047/2406 897/2062 748/1718 598/1375 448/1031 299/687 149/343 -
Just a sysctl with a grep to get current cpu speed.
Fwiw, sysctl can interrogate subgroups directly, allowing you to skip the grep. E.g.,
root@pfsense:~ # sysctl dev.cpu.0.freq dev.cpu.0.freq: 300 root@pfsense:~ # sysctl dev.cpu.0 dev.cpu.0.temperature: 33.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.coretemp.tjmax: 85.0C dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.delta: 52 dev.cpu.0.cx_usage: 100.00% 0.00% last 677us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/1 C2/2/148 dev.cpu.0.freq_levels: 2900/35000 2800/33218 2600/30093 2500/28743 2300/25796 2200/24202 2100/22958 1900/20234 1800/19072 1600/16509 1500/15121 1400/14056 1225/12299 1200/11711 1100/10435 962/9130 900/8522 800/7328 700/6412 600/5496 500/4580 400/3664 300/2748 200/1832 100/916 dev.cpu.0.freq: 300 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU -
I added these back to loader.conf and got throttling back on my VIA C7 chip, too.
hint.p4tcc.0.disabled="0"
hint.acpi_throttle.0.disabled="0"dev.cpu.0.freq_levels: 1007/-1 881/-1 755/-1 629/-1 503/-1 377/-1 251/-1 125/-1
dev.cpu.0.freq: 125 -
In the freeBsd patch quoted above they say
These CPU speed control techniques are usually unhelpful at best.
I can confirm this. On my Supermicro a1sri-2758f for example, enabling PowerD makes things worse. NAT throughput is only about 400Mbit/sec for the first 8-10 seconds - that's the time required for the CPU to scale up and allow NATting at 1Gbps. Enabling PowerD actually reduces performance, since network load appears in spikes, with CPU freq scaling all these spikes would be limited to 400 Mbit.
How does sysctl hw.acpi.cpu.cx_lowest=C2 affect NAT performance (with PowerD off)?
-
I'm also having troubles with CPU usage/utilization after the 2.3 upgrade. I'm running pfSense on an old-ish Core2Duo HP notebook with a rather noisy fan. With 2.2.6, the fan would spin up only when system utilization was quite high, for example with fast transfers over a OpenVPN tunnel. With 2.3 the fan is spinning at an audible level all the time, and will spin up very often, even when the box is "idling". I've already tried the methods desribed in this thread, but can't get the system to be "quiet" again.
One interesting thing is that the command "powerd -v" shows that the CPU is at its maximum freq nearly all the time, this looks like this: "load 14%, current freq 2000 MHz ( 0), wanted freq 3521 MHz". Every few seconds there's an entry like "changing clock speed from 2000 MHz to 1750 MHz", but the clock speed changes to the max again right after that (meaning the system doesn't stay at the lower frequency). This happens with "Adaptive" and "Hiadaptive".
The problem with my and other systems is probably not only noise levels, but also heat generation. If the box is sitting in an enclosed space, excessive heat generation could lead to overheating over time.
Is there anything that can be done to maybe decrease the max cpu frequency, or make powerd "ramp up" slower? It'd also be interesting to hear if other people also have this problem, and what the devs think about this issue.
-
Saschal, try sysctl hw.acpi.cpu.cx_lowest=Cmax to lower temperature a little, but don't add it to System Tunables until you know it's stable. Also make sure you're running the latest BIOS.
See sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage
-
One interesting thing is that the command "powerd -v" shows that the CPU is at its maximum freq nearly all the time, this looks like this: "load 14%, current freq 2000 MHz ( 0), wanted freq 3521 MHz". Every few seconds there's an entry like "changing clock speed from 2000 MHz to 1750 MHz", but the clock speed changes to the max again right after that (meaning the system doesn't stay at the lower frequency). This happens with "Adaptive" and "Hiadaptive".
I may be able to help. If you have already tried adding the below to loader.conf,
hint.p4tcc.0.disabled="0" hint.acpi_throttle.0.disabled="0"leave it there because you'll need it and see what FreeBSD has chosen for the timecounter and what choices are available.
[2.3-RELEASE][root@fw.local]/root: sysctl kern.timecounter.hardware kern.timecounter.hardware: i8254 [2.3-RELEASE][root@fw.local]/root: sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)In my case, TSC was initially chosen by FreeBSD. I was able to change it to i8254 (the next lower quality) by adding kern.timecounter.hardware i8254 to System/Advanced/System Tunables tab. You would add whatever the second quality is on your hardware. Rebooted and powerd worked as expected. My lowly VIA C7 box now ramps nearly immediately and starts throttling after 4-5 seconds. Although this will probably result in a face/palm from anyone who knows FreeBSD, it worked for me! :o
-
Interesting. See if you can enable HPET in BIOS, since it is preferred.
kern.timecounter.choice: TSC(800) HPET(950) ACPI-fast(900) i8254(0) dummy(-1000000)
