Reducing power usage with 8.3.0-RELEASE-p1

[chupaty77]

Hi there

This is partly a post for posterity, but also a query for help.

After a bit of fiddling around, I've stumbled across some reasonable power saving measures for freenas 8.3 on my i3 (Intel DH57JG motherboard):

Tunables
hint.acpi_throttle.0.disabled=1 (Not using CPU throttling due to powerd issue)
hint.apic.0.clock=0 (Disable as many interrupts as possible)
hint.atrtc.0.clock=0 (Again, disable these timer interrupts)
kern.hz=100 (It's a NAS, we don't need millisecond jiffies)

Sysctls
hw.acpi.cpu.cx_lowest=C3 (This is where we get our power savings, rather than by powerd and throttling)

Other Settings
powerd=OFF (System -> Settings -> Advanced -> Enable Powerd)


I discovered 3 things on the way (that I haven't resolved).

First, I had an issue with powerd consistently wanting to set the frequency greater than the rating of my CPU. I suspect this may be to do with my customized kern.hz? This was one of the reasons that I decided to use C states instead of throttling to achieve what I wanted. By the way, my quick attempts to get C states happening at 1000Hz failed.

Second, my sysctl (hw.acpi.cpu.cx_lowest)... doesn't work when set in the GUI. Works fine when I open a terminal and set it manually afterwards. Until I do this, all 4 processors are stuck in C1 100% of the time. (I reboot to test this). Not sure if this is a real problem of just PEBKAC.

Third, I think there might still be something odd going on with interrupts. I was hoping (judging by http://wiki.freebsd.org/TuningPowerConsumption ) that my C3 state would jump to close to or at 100% when the box is idle. Instead, when top reports 100% idle, my states look like this:

Code:

/> sysctl dev.cpu | grep cx
dev.cpu.0.cx_supported: C1/3 C2/205 C3/245
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 25.74% 6.35% 67.90% last 295us
dev.cpu.1.cx_supported: C1/3 C2/205 C3/245
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 13.81% 6.40% 79.78% last 2059us
dev.cpu.2.cx_supported: C1/3 C2/205 C3/245
dev.cpu.2.cx_lowest: C3
dev.cpu.2.cx_usage: 11.62% 7.85% 80.52% last 54us
dev.cpu.3.cx_supported: C1/3 C2/205 C3/245
dev.cpu.3.cx_lowest: C3
dev.cpu.3.cx_usage: 9.55% 7.42% 83.02% last 11us

It's not horrible, but I was hoping for better...

I'll save my battles with APM and drive spin down for another posting...

In short, the results of doing the above (including the sysctl) are that my CPU temp went from about 65C - 70C when idle to:

Code:

/> sysctl dev.cpu | grep temperature
dev.cpu.0.temperature: 48.0C
dev.cpu.1.temperature: 48.0C
dev.cpu.2.temperature: 46.0C
dev.cpu.3.temperature: 47.0C

Can anyone suggest some help for my 3 problems?

Thanks
Simon

 

[JaimieV]

Can't help, but wanted to ask what the CPU model is? There may be restrictions on supported states.

 

[chupaty77]

Hi Jaimie

Can't help, but wanted to ask what the CPU model is? There may be restrictions on supported states.

It's an intel i3 550:

Code:

 /> sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: Intel(R) Core(TM) i3 CPU         550  @ 3.20GHz
hw.ncpu: 4
hw.machine_arch: amd64

Cheers
Simon

 

[cyberjock]

I will say that unless you are doing a scrub there is something terribly wrong with your temps. I've overclocked i3 before and I couldn't get above 45C idle if I tried. Loaded without an overclock you shouldn't be seeing above 50C.

So before you start doing all this weird APM modifications I'd HIGHLY recommend you examine your CPU cooler and verify its properly installed. Check your BIOS settings, do any updates and perhaps reset to defaults.

All this stuff you are doing for APM should NOT be necessary and I really don't buy that powerd is trying to set your CPU speed higher than it is designed unless your CPU BIOS settings are set higher. powerd does NOT have the ability to overclock your CPU. Yes, powerd may appear to be 'causing' it.. but I think that's only an observation and not actually the case.

 

[chupaty77]

I will say that unless you are doing a scrub there is something terribly wrong with your temps. I've overclocked i3 before and I couldn't get above 45C idle if I tried. Loaded without an overclock you shouldn't be seeing above 50C.

So before you start doing all this weird APM modifications I'd HIGHLY recommend you examine your CPU cooler and verify its properly installed. Check your BIOS settings, do any updates and perhaps reset to defaults.

All this stuff you are doing for APM should NOT be necessary and I really don't buy that powerd is trying to set your CPU speed higher than it is designed unless your CPU BIOS settings are set higher. powerd does NOT have the ability to overclock your CPU. Yes, powerd may appear to be 'causing' it.. but I think that's only an observation and not actually the case.

Hi there

I was surprised myself. The system had been running ubuntu 12.04 with CPU temps below 45 no problems before I switched to freenas (it was using the full gamut of C states though, so it may not be a fair comparison). Just to be clear, this is all ACPI stuff - I left APM off (inasmuch as the GUI allows me). The BIOS is fairly simple, and is configured the same as the linux system.

WRT the overclocking, I've probably misstated what I've seen... Running

Code:

powerd -v

produced results like this:

Code:

load 112%, current freq 3199 MHz ( 0), wanted freq 6398 MHz                     
load 100%, current freq 3199 MHz ( 0), wanted freq 6398 MHz                     
load 108%, current freq 3199 MHz ( 0), wanted freq 6398 MHz  

I'm not suggesting the system was trying to overclock the CPU, but that powerd was somehow confused about the load of the system and was maxing the CPU frequency out. This happens while the idle % according to top is 99.9% and the load according to uptime is under 0.5 (I didn't test it then, but a quick test now says 0.28 while I'm doing other things with it). I assumed (probably hastily) a kern.hz issue as I would be expecting this number (100 or 1000, determined at runtime? compile time?) to be in the divisor in whatever calculations powerd might be performing, but admit that I was too lazy to look at the source or attempt to narrow it down further through experimentation.

I'll check BIOS versions and physical mountings soon.

Thanks
Simon