PowerD causes repeating syslog message

[stephenw10]

What CPU is this? Do you have P-states available?
You should also disable P4 steps (unless you have a P4-M)

hint.p4tcc.0.disabled=1

How many levels do you see available in dev.cpu.0.freq_levels?

This is a useful read: https://wiki.freebsd.org/TuningPowerConsumption

Steve

[markn62]

AMD A6-6400K Richland 3.9GHz socket FM2 dual-core.  I think it has the RL-A1 enhanced speed steps.

[2.1-RC2][admin@pfsense.router]/(9);sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 3900/21266 3600/17212 3100/12350 2600/9225 2200/6075 1800/3977

There were more levels before adding the acpi hint that went all the way down to 250Mhz. The dashboard reports anywhere from 400Mhz to 2100Mhz with PowerD enabled.

[markn62]

What does hint.p4tcc.0.disabled=1 do?  Maybe I lost the objective here.  Are we trying to eliminate an unwanted logging of CPU speed changes leaving the PowerD and the CPU to function as designed?  Or are we trying to reduce the number of steps so the error goes away and we constrain the power levels available to us to just a few near the upper range of steppings?

The AMD A6-6400K appears to have 5 Low power P states.
Re: http://www.cpu-world.com/CPUs/Bulldozer/AMD-A6-Series%20A6-6400K.html

[stephenw10]

ACPI throttling does almost nothing useful and adds many extra unnecessary steps such that the cpu is constantly changing speed. P4TCC only controls CPU frequency and not voltage. Real 'speedstep' (or equivalent) controls frequency and voltage and is by far the best method to use. The others only confuse matters.

I was trying eliminate anything that might be causing powerd to try to set a state that the cpu is not capable of. The error seems to indicate powerd is trying to set the cpu to particular P-state and failing. Since all the P-state values are handed to powerd from the bios DSDT table via ACPI it may be that your bios is reporting an invalid state. Have you got the most recent bios? You could try to find which state is failing by killing powerd manually setting the frequency. E.g.

sysctl dev.cpu.0.freq=2600

Then check with no parameter that the change took

sysctl dev.cpu.0.freq

Usually the first core controls the others assuming the speeds are not variable across the cores.  ;)

To be honest I have found that on modern CPU with many C states greater savings are available via that anyway. I spent a long time trying to get speedstep working on a Core2 CPU and in the end couldn't see any measurable drop in power consumption.  ::)

The error you are seeing could also be because it's trying to change the frequency to fast. It won't change because a change is already in progress.

Steve

[stephenw10]

Ah just seen your edit!
There you go then the CPU has only 5 states but the bios is reporting 6.
Which one is wrong?

Steve

[markn62]

Steve,
This box uses AHCI rather than ACPI.  To me the terms are interchangeable but thought I should mention in case it matters.  The reference link, in my earlier post, shows 5 steppings but doesn't have the base CPU speed of 3.9MHz listed as one of it's steppings.  So I think it's a typo and there really are six.  I was getting about 12 before adding the acpi hint.  I haven't tried adding the p4tcc hint yet.  I'd try the p4 hint now if it can be envolked without a reboot via loader.conf because the box is in service.  Otherwise I'll have to hold off til the early AM hours.  You think adding the p4tcc will help?  So what options are there other than disabling PowerD?  Do you know how to slow the stepping changes if needed?

Frequency 3900 MHz
Turbo frequency 4100 MHz
Boosted P states [1] #1: 4100 MHz, 1.275V
#2: 4000 MHz, 1.15V

Low power features PowerNow!
Low power P states [1]
#1: 3600 MHz, 0.925V
#2: 3100 MHz, 0.775V
#3: 2600 MHz, 0.65V
#4: 2200 MHz, 0.45V
#5: 1800 MHz, 0.25V

[markn62]

Issuing fixed frequency commands it appears the first failed but tried again later and it worked, timing?  It seems that this command "sysctl dev.cpu.0.freq=xxxx" sets the lowest frequency in a range from 3900Mhz down, it doesn't fix the CPU at the selected frequency.  So when frequency is not forced but only requested it reveals wherever the CPU happens to be within the range at that time.  Does appear to report correctly each frequency step from 1800 to 3900.

_[2.1-RC2][admin@pfsense.router]/(2): sysctl dev.cpu.0.freq=1800
dev.cpu.0.freq: 3600
sysctl: dev.cpu.0.freq: Device not configured

[2.1-RC2][admin@pfsense.router]/(3): sysctl dev.cpu.0.freq=3600
dev.cpu.0.freq: 1800 -> 3600

[2.1-RC2][admin@pfsense.router]/(4): sysctl dev.cpu.0.freq=2200
dev.cpu.0.freq: 1800 -> 2200

[2.1-RC2][admin@pfsense.router]/(5): sysctl dev.cpu.0.freq=2600
dev.cpu.0.freq: 1800 -> 2600

[2.1-RC2][admin@pfsense.router]/(6): sysctl dev.cpu.0.freq
dev.cpu.0.freq: 3600

[2.1-RC2][admin@pfsense.router]/(7): sysctl dev.cpu.0.freq=3100
dev.cpu.0.freq: 1800 -> 3100

[2.1-RC2][admin@pfsense.router]/(8): sysctl dev.cpu.0.freq
dev.cpu.0.freq: 1800

[2.1-RC2][admin@pfsense.router]/(9): sysctl dev.cpu.0.freq=3600
dev.cpu.0.freq: 1800 -> 3600

[2.1-RC2][admin@pfsense.router]/(10): sysctl dev.cpu.0.freq
dev.cpu.0.freq: 1800

[2.1-RC2][admin@pfsense.router]/(12): sysctl dev.cpu.0.freq=3600
dev.cpu.0.freq: 1800 -> 3600

[2.1-RC2][admin@pfsense.router]/(13): sysctl dev.cpu.0.freq=3900
dev.cpu.0.freq: 1800 -> 3900_

[stephenw10]

Did you disable powerd or kill it? Otherwise you're always fighting against it.
Is there any reason you are trying this?

Steve

[markn62]

Not sure your question Steve.  As mentioned in my first post to this thread until now I've had PowerD enabled.  Isn't that the idea?  If I disable PowerD I get no log errors, and the CPU stays maxed at 3.9Ghz.  Same happens if I set PowerD on Maximum performance, sits @ 3.9Mhz.

I'd rather not burn up 65 watts with the CPU average load at <3%.  I upgraded this box as a full install because I wanted the monitor tools and sized the CPU for future needs.  Replaced box was running at 50% CPU.

Suppose I could avoid the error by fixing to a slower speed if I had the correct command .  It seems the command you provided only sets the lower limit.  Auto PowerD would be nice especially if capped at 1800Mhz so it doesn't wallow around the very low end and change steps too frequently.

Maybe with this box it is what it is.  Either put up with the log entries or don't use PowerD.  Not seeing too many other options surface.

[markn62]

[2.1-RC2][admin@pfsense.router]/(7): sysctl dev.cpu.0

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=_PR_.P000
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1800
dev.cpu.0.freq_levels: 3900/21266 3600/17212 3100/12350 2600/9225 2200/6075 1800/3977
dev.cpu.0.cx_supported: C1/100
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% last 95us

[kejianshi]

Frustration is sometimes a good thing.  It lets us know when to give up.

Is there a bulb burning unnecessarily somewhere you could turn off to save energy?

Edit:  I think mine is using 65W also according to spec.

I need to get one of these to check it:

http://www.hydrogalaxy.com/growing-lights/lighting-accessories/kill-a-watt/?gclid=CJKf8v60tbkCFRFp7Aod4i0A1Q

[stephenw10]

I see your lowest c state is c1. That might be a better way to save power. Are there any c state options in the BIOS?
Have you actually measured the power consumption? It's probably not actually using 65W. My own experience was that the real power saving was barely measurable.

Steve

[stephenw10]

This thread might explain what's happening in your case. If so there's not a lot can be done though it's not a problem at least.
http://freebsd.1045724.n5.nabble.com/stable-9-broken-hwpstate-calls-td5709583.html

Steve

[markn62]

Funny Keji, I know this sounds trivial.  Any power savings tied to a UPS is a necessary consideration.  The BIOS manual states nothing related to C1.

Interestingly, with only the throttle hint entered since a reboot and changing PowerD to HiAdaptive for both A/C and battery I now get variable CPU speeds from 1800 to 3900 and no log errors.  Lucky combo?  I know FreeBsd 8.3 defaults to Adaptive so I would think I could have got lucky by making them match, not different.  I'll look into this further in the context of the PowerD settings, loader.conf entries and actual idle pwr usage.

Thanks Steve and others for your help on this.  Been a healthy learning curve jumping from McAfee (formerly Snapgear) embedded products to PfSense.  A bit more involved but interesting nonetheless.

[kejianshi]

If you have it working for a while without error and I load pfsense onto something tiny I might scam off your effort later.

I will also be building a small ups soon - so it might help.

[markn62]

I think I better see the problem with command powerd -v.  Any ideas what wants the odd frequencies?  Is PowerD asking for it or is it based on info PowerD gets from the BIOS?  I can't understand where these odd numbers come from.  Even figuring in a  turbo mode frequency offset (factor) it still doesn't add up.  Not to mention Turbo is disabled in BIOS. CPU freq 3900Mhz on turbo is 4100Mhz which should be the highest frequency PowerD should want.  7800 is the highest reported which is exactly double 3900, is this because it has 2 cores?  Who knows, maybe it's doing some odd math where one core is non-turbo and one is turbo and then adds together.  Puzzling.

This weekend I'll put command debug.hwpstate_verbose="1" into /boot/loader.conf.local and reboot to see what is really going on behind the curtain.

---

powerd -v
load  7%, current freq  225 MHz (16), wanted freq 1439 MHz
changing clock speed from 225 MHz to 1575 MHz

load  13%, current freq  225 MHz (16), wanted freq 1394 MHz
changing clock speed from 225 MHz to 1575 MHz

load  15%, current freq  225 MHz (16), wanted freq 1350 MHz
changing clock speed from 225 MHz to 1350 MHz

load 120%, current freq  450 MHz (15), wanted freq 5400 MHz
changing clock speed from 450 MHz to 3900 MHz

load  70%, current freq 3900 MHz ( 0), wanted freq 7800 MHz

load  7%, current freq  675 MHz (14), wanted freq 7556 MHz
changing clock speed from 675 MHz to 3900 MHz

load  10%, current freq 3900 MHz ( 0), wanted freq 7319 MHz

load  8%, current freq  450 MHz (15), wanted freq 7090 MHz
changing clock speed from 450 MHz to 3900 MHz

load  28%, current freq 3900 MHz ( 0), wanted freq 7090 MHz

load  6%, current freq  450 MHz (15), wanted freq 6868 MHz
changing clock speed from 450 MHz to 3900 MHz

load  13%, current freq 3900 MHz ( 0), wanted freq 6653 MHz

load  4%, current freq  450 MHz (15), wanted freq 6445 MHz
changing clock speed from 450 MHz to 3900 MHz

load  12%, current freq 3900 MHz ( 0), wanted freq 6243 MHz

load  4%, current freq  450 MHz (15), wanted freq 6047 MHz
changing clock speed from 450 MHz to 3900 MHz

load  21%, current freq 3900 MHz ( 0), wanted freq 5858 MHz

load  8%, current freq 3900 MHz ( 0), wanted freq 5674 MHz

load  34%, current freq  450 MHz (15), wanted freq 5674 MHz
changing clock speed from 450 MHz to 3900 MHz

load  6%, current freq 3900 MHz ( 0), wanted freq 5496 MHz

load  17%, current freq  450 MHz (15), wanted freq 5324 MHz
changing clock speed from 450 MHz to 3900 MHz

load  19%, current freq 3900 MHz ( 0), wanted freq 5157 MHz

load  19%, current freq  450 MHz (15), wanted freq 4995 MHz
changing clock speed from 450 MHz to 3900 MHz

load  16%, current freq 3900 MHz ( 0), wanted freq 4838 MHz

load  16%, current freq  450 MHz (15), wanted freq 4686 MHz
changing clock speed from 450 MHz to 3900 MHz

load  10%, current freq 3900 MHz ( 0), wanted freq 4539 MHz

load  0%, current freq  450 MHz (15), wanted freq 4397 MHz
changing clock speed from 450 MHz to 3900 MHz

load  16%, current freq 3900 MHz ( 0), wanted freq 4259 MHz

load  0%, current freq  450 MHz (15), wanted freq 4125 MHz
changing clock speed from 450 MHz to 3900 MHz

load  10%, current freq 3900 MHz ( 0), wanted freq 3996 MHz

load  20%, current freq  225 MHz (16), wanted freq 3871 MHz
changing clock speed from 225 MHz to 3900 MHz

load  12%, current freq 3900 MHz ( 0), wanted freq 3750 MHz

load  38%, current freq  225 MHz (16), wanted freq 3800 MHz changing clock speed from 225 MHz to 3900 MHz

---

sysctl dev.cpu.0.freq_levels

dev.cpu.0.freq_levels: 3900/21266 3600/17212 3150/15060 3100/12350 2712/10806 2600/9225 2275/8071 2200/6075 1925/5315 1800/3977 1575/3479 1350/2982 1125/2485 900/1988 675/1491 450/994 225/497

[markn62]

Another idea to try.  According to this blog, pwr management is suppose to be enabled in BIOS.  I have it disabled because I thought only the Windows OS used it.  Could explain the odd "wanted" frequencies powerd reports.  I'll have to try enabling it as was done here;

https://www.ateamsystems.com/blog/Increase-FreeBSD-Performance-With-powerd?goback=%2Egde_47628_member_188127582#%21

Quote: Using AMI's server BIOS as an example, the option is located under the Advanced tab, then go to CPU Configuration and then CPU Power Management Configuration and set Power Technology to "Energy Efficient" and then Energy/Performance Bias to "Performance".  Each BIOS is different obviously so some poking around might be needed for your servers.  The key is that both these BIOS changes need to be made and powerd needs to be enabled otherwise there is no gain (we tested it … a lot).

[stephenw10]

That looks like what you see if you still have ACPI throttling enabled. Did you re-enable it? Could also be p4tcc confusing things.
Interesting to see what the debug option reveals. With newer bioses, especially not using ACPI like yours, I guess anything could be true. Changing those bios settings can alter what the bios tells the OS about the CPU/board. You can certainly disble p-state changing entirely doing that.

Steve

[markn62]

Well I finally determined the right combo for this MSI FM2-A85XMA0-E35 mobo.  I had to enable Cool'n'Quiet (CnQ) in BIOS.  PowerD enabled with CnQ disabled was causing the log errors.  Once CnQ and PowerD was enabled, PowerD wouldn't work with ACPI throttling disabled so I removed the disable line from /boot/loader.conf.local.  But did add sysctl debug.cpufreq.lowest=1949  to keep throttling from dropping too far.

Not sure it will work in /boot/, but should since it works from the command line.  Really should go into sysctl.conf (without the debug) but it appears to be a temp file not to be edited.

So I'll know for sure next reboot if it's sticky.  I thought I read about a command that you could define specific frequencies, rather than a range, but can't find it.  I would prefer to set this as only 3900Mhz and 1900Mhz so it doesn't step down thru the others in between.

So anyways, happy days again.  Haven't got a chance to measure actual power use but will at my first opportunity.

[stephenw10]

Sysctls that can be added after boot can be added to the System Tunables table in System: Advanced:

Steve