Hi,I think what you did is the most valid test. Testing with any configuration other than the one you actually use may give some specious appearance of saving, but unless you actually use the system in the reduced configuration I don't see how you would save anything by going to the lower clock.
I did some measurements in order to compare power drain with HZ250 and
To measure the actual drain, I used the "smart" battery's internal measurement.
(Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.)
No clue how accurate this is.
Here some battery details, in case someone knows:
charge reporting error: 25%
SB specification: v1.1 (with PEC)
manufacturer name: Panasonic
manufacture date: 2004-11-27
device name: 02ZL
device chemistry: Lion
Kernel: 2.6.13-rc3-mm1 + acpi-sbs
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.60GHz
stepping : 6
The "ondemand" governor was running, using acpi_cpufreq. (Idle at 600MHz).
Systems was running X11/KDE to get a more or less realistic scenario. No
cron jobs, network traffic or additional applications. WLAN and built-in
display were disabled completely, all fans and LEDs were off, internal hard
disc was running. Additional peripherals: external keyboard, mouse, display
and externally-powered hard disk (USB).
The results are quite simple:
In both configurations the current settles between 727-729 mA
(Voltage ~16.5 V).
- C-states look strange:
active state: C2
bus master activity: 00887fff
C1: type[C1] promotion[C2] demotion[--] latency usage
*C2: type[C2] promotion[C3] demotion[C1] latency usage
C3: type[C3] promotion[--] demotion[C2] latency usage
- I don't know, how much polling of the battery affects results. Reads always
block for ~10 seconds, and I used this behaviour for rate-limiting.
- Is this approach valid at all?
- I could repeat the test in single user mode with internal hard disc turned off.