Linked by snydeq on Wed 2nd Nov 2011 22:50 UTC
Google InfoWorld's Serdar Yegulalp provides a look at the best apps for boosting the battery life of your Android device. "The best place to start if you just want to survey your power usage habits is Battery Indicator. To follow that up with actual power management, Green Power and JuiceDefender are your best bets. 2x Battery is not a bad program, but it's limited to managing cell data and not Wi-Fi connections. If that feature were added in a future revision, 2x Battery would be a real contender."
Thread beginning with comment 495472
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Conditional underclocking
by Alfman on Thu 3rd Nov 2011 05:11 UTC in reply to "Conditional underclocking"
Member since:


"I've found SetCPU to be the best battery saver beyond any of those recommended apps. It will allow your CPU to be progressively underclocked when it reaches certain battery levels if your phone is rooted."

I don't have an ARM processor to test this on, but I hear that these processors are extremely aggressive in conserving power when they're not in use. This way, when they're idle, they should have a similar energy footprint regardless of clock speed. And when they're busy, the clock speeds are inversely proportional to the length of time spent being busy. So slowing down the clock isn't necessarily more efficient.

Here is data from a test I just completed on my Intel Xeon 3.00GHZ E3110.

A simple work load: ( 21.5B loops )
xor ax, ax
xor bx, bx
xor cx, cx
add ax, 1
adc bx, 0
adc cx, 0
cmp cx, 5
jb again
int 20h

3GHZ Throttling enabled:
Idle = 5.2watt
Workload = 16.5watt for 23s = .105 watt-hours

3GHZ Full throttle:
Idle = 6.6watt
Workload = 17.6watt for 22s = .108 watt-hours

2GHZ Throttling enabled:
Idle = 5.1watt
Workload = 9.1watt for 98s = .248 watt-hours

2GHZ Full throttle:
Idle = 6.6watt
Workload = 17.6watt for 33s = 0.161 watt-hours

I can't explain what went on with cpu throttling at 2GHZ, a guess is that maybe it wasn't designed to work with an underclocked CPU? Never the less, take note that in all instances (with and without dynamic throttling), the CPU clocked at 3GHZ was more energy efficient under load than when it was clocked at 2GHZ. Interestingly the 2GHZ throttled test used the lowest wattage but required the greatest total energy because it was so slow. At idle, the cpu frequency made no difference, as I anticipated.

So, if the CPU's idle energy footprint is the same regardless of clock speed, then it may make the most sense to empty the work queues as quickly as possible to return to idle.

Comparing this to ARM processors is obviously apples to oranges, but it should provide a good warning against taking improved energy/frequency ratios for granted.

Can anyone shed light on empirical data for ARM processors specifically, like those used in Android phones?

Edit: I should add that my test didn't play with voltages levels, which were left at auto. The cpu throttling utility for my mainboard is supposed to do that, though I'm not sure exactly what it does since it's been end-user dumbified.

Edited 2011-11-03 05:30 UTC

Reply Parent Score: 4

JAlexoid Member since:

You can't compare a workstation CPU with highly optimised low power usage CPU. Too different architectures and other stuff.

Did you factor in the OS into your tests of Xeon? Because that makes a lot of difference. Specially in the more is less case.

Reply Parent Score: 2

Alfman Member since:

"You can't compare a workstation CPU with highly optimised low power usage CPU. Too different architectures and other stuff."

I thought I said that, but yeah.

"Did you factor in the OS into your tests of Xeon?"

No I didn't. Just now I tried the test at 3GHZ and there was no difference in execution speed between linux and windows. I could not measure the cpu wattage under linux, but I have no reason to believe it'd be different in the same state.

"Because that makes a lot of difference. Specially in the more is less case."

Can you clarify what you mean? Obviously anything that places a load on the scheduler, such as interrupts, will be very os dependent. However if interrupts are consuming less than 1% of CPU in either OS, then the test loop given above should (and does) run equally fast under either OS. If I had stressed memory or IO then things might start to diverge.

Reply Parent Score: 2