FreeBSD 50% higher power consumption than Debian

W

weberjn

Got myself a used AMD GX-217GA amd64 system (FUTRO S720) as Raspberry Pi 4 alternative for a small home server.

Tried Debian 12 and FreeBSD 13.2-p2 and checked idle power consumption with a good power meter:

Debian: 4,3W
FreeBSD: 6,4W

powerd_enable="YES"

Highest process on cpu: 0.03% powerd


With FreeBSD (6.4 - 4.3)W is 18.4 kWh a year or 9,20€ in Germany (or half of what I paid for the machine ;-)

Does the kernel need some optimization for power management? Or does Debian switch off the on cpu graphics and FreeBSD doesn't?
 
Code: 
 sysctl dev.cpu | grep cx
dev.cpu.1.cx_method: C1/hlt C2/io
dev.cpu.1.cx_usage_counters: 177890 0
dev.cpu.1.cx_usage: 100.00% 0.00% last 15281us
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_supported: C1/1/0 C2/2/400
dev.cpu.0.cx_method: C1/hlt C2/io
dev.cpu.0.cx_usage_counters: 245990 0
dev.cpu.0.cx_usage: 100.00% 0.00% last 27520us
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/0 C2/2/400


Why was this moved to embedded? this is a Fujitsu Thin Client Futro S720.
 
It at least supports C2 - not great, but at least something...
Try setting performance_cx_lowest="Cmax" and economy_cx_lowest="Cmax" in /etc/rc.conf.

On some systems powerd might cause the CPU to resume to lower C-states more often and thus actually *increase* power draw. Usually there's no benefit in reducing the clock rate if C-states can completely shut down a core, so you might want to evaluate power consumption with powerd/powerdxx enabled and disabled after enabling C-states (also check BIOS settings!). At least for systems with C3 and higher available, I haven't seen any improvement when using powerd(xx), so I usually don't use it any more.
 
Maybe it got moved because of the Raspberry Pi reference.
 
What does dev.cpu.[0|1].cx_usage report? does the CPU actually enter a higher (lower) state?

Also: where did you measure the power draw? At the switchport (if powered via PoE) or some device plugged between the socket and the wall-wart? Those usually have a minimum current level under which their measurement has a substantial error. I used such a meter to check my complete rack and that thing fluctuated heavily with loads <20W.
 
sko said:
What does dev.cpu.[0|1].cx_usage report? does the CPU actually enter a higher (lower) state?
Click to expand...

Code: 
 # sysctl dev.cpu.{0,1}.cx_usage
dev.cpu.0.cx_usage: 4.75% 95.24% last 8427us
dev.cpu.1.cx_usage: 5.35% 94.64% last 22143us

I measured with Brennenstuhl PM 231 E plugged between the socket and wall, no PoE, no USB devices beside keyboard. Same hardware setup as with Debian.
 
There is the GPU which can draw a lot. No idea if the power management there is active, that is a quest I skipped. Also, tuning kern.hz may give some results, but with the CPU idle for that long I doubt it. Maybe you can get something from systat -vmstat, Interrupt counters would be interesting. Or check how to put the drive to sleep...
 
I've repeated the exercise with a Thinkpad E130, battery removed.
Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz

34% higher power consumption.

Debian: 11,7 W idle
FreeBSD: 15,7 W idle

sysctl dev.cpu.{0,1}.cx_usage
dev.cpu.0.cx_usage: 1.03% 98.96% last 3712us
dev.cpu.1.cx_usage: 2.99% 97.00% last 65674us
 
You can power off usb devices (with usbconfig) and pci devices ( hw.pci.do_power_nodriver)

There is a good article on this:
vermaden.wordpress.com

The Power to Serve – FreeBSD Power Management

This is the motto of the FreeBSD operating system – The Power to Serve – which also greatly fits for the topic of this article. Decade ago (yes time flies) I even made a wallpaper with …
vermaden.wordpress.com vermaden.wordpress.com
 
The hardware I have at hands for such experiments are old.

It would be great if someone could compare energy consumption on current server hardware and current laptops:

a clean install of Debian 12 bookworm and FreeBSD 13.2 with all updates and fixes, but no special settings or tuning, as I did no tuning of Debian at all.
 
getopt said:
which needs some agreement on a standardized procedure. What is needed is measuring over a defined period of time resulting in Watts/per hour and running this with defined and comparable settings.
Click to expand...

And a defined load. I chose the easy way and idle systems.

For high loads one needs a defined application load. An easy to set up load is the DaCapo Benchmark Suite with a set of standard Java applications. But so the measure includes the Java VM implementation.

As for settings, I suggest no tuning at all, standard OS installation.

Code: 
$ java -jar dacapo-9.12-MR1-bach.jar -l
avrora batik eclipse fop h2 jython luindex lusearch lusearch-fix pmd sunflow tomcat tradebeans tradesoap xalan

$ java -jar dacapo-9.12-MR1-bach.jar -C lusearch
...
===== DaCapo 9.12-MR1 lusearch PASSED in 2555 msec =====
 
Could you try without the DRM module? I remember the runtime of my laptop tanking in Linux when I switched on nifty desktop compositing which ran the GPU. Translucent windows for example. Go simple xorg+twm.

A power consumption data base would be nice indeed.
 
Crivens said:
A power consumption data base would be nice indeed.
Click to expand...
Yeah! But what does it take to realize a "nice" and pleasant thought?

How to cope with different sizes of intalled RAM and different types of hard drives, etc. to make datasets comparable?
 
getopt said:
Yeah! But what does it take to realize a "nice" and pleasant thought?

How to cope with different sizes of intalled RAM and different types of hard drives, etc. to make datasets comparable?
Click to expand...

This diverges a little. The question is why FreeBSD needs so much more power on exactly the same hardware.
 
Crivens said:
Could you try without the DRM module? I remember the runtime of my laptop tanking in Linux when I switched on nifty desktop compositing which ran the GPU. Translucent windows for example. Go simple xorg+twm.

A power consumption data base would be nice indeed.
Click to expand...

The Debian and FreeBSD installations are without GUI.
 
Try setting kern.hz=100 in /etc/loader.conf, see if it changes something.
 
sko said:
It at least supports C2 - not great, but at least something...
Try setting performance_cx_lowest="Cmax" and economy_cx_lowest="Cmax" in /etc/rc.conf.
Click to expand...

That can't work on weberjn's FUTRO S720 as it has no battery, so devd cannot run /etc/rc.d/power_profile on notifies from ACPI ACAD, so sysctl hw.acpi.cpu.cx_lowest never changes, so nor sysctl dev.cpu.{0,1}.cx_lowest - however these may be set in /etc/sysctl.conf.

sko said:
On some systems powerd might cause the CPU to resume to lower C-states more often and thus actually *increase* power draw.
Click to expand...

Which systems? I can't see how that could be possible, when changing CPU speed doesn't affect C-states?

sko said:
Usually there's no benefit in reducing the clock rate if C-states can completely shut down a core,
Click to expand...

Even C-state C8 doesn't 'shut down a core', and reducing clock speed according to load (esp. no load) makes a large difference in power use on any processor I've seen.

sko said:
At least for systems with C3 and higher available, I haven't seen any improvement when using powerd(xx), so I usually don't use it any more.
Click to expand...

Well I've only used older Intel CPUs in recent decades, which ones do you refer to?
 
You must log in or register to reply here.
Back
Top