Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,785,193 Members 37,613 Now Online
XDA Developers Android and Mobile Development Forum
View Poll Results: What has been your experience? (Select two options)
Deep Idle has saved power 179 45.78%
Don't know 123 31.46%
Deep Idle has used more power 28 7.16%
Undervolting has saved power 99 25.32%
Don't Know 141 36.06%
Undervolting has used more power 17 4.35%
Multiple Choice Poll. Voters: 391. You may not vote on this poll

[REF] Battery Drain Benchmarks

Tip us?
bedalus Old
(Last edited by bedalus; 16th March 2012 at 02:49 PM.)
#1  
Guest
Thanks Meter 0
Posts: n/a
Default [REF] Battery Drain Benchmarks

Spreadsheet of the Battery Drain Data
BATTERY DRAIN BENCHMARKS

VIDEO of how it's done! (Do NOT try it yourself!)

NEW: Lab study done by nathanson666 see here and featured on the XDA's portal and twitter here.

Summary of Results

#1 - With screen on, if the processor is Idle, 100MHz saves the most power.

#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)

For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.

#3 - The most power saving governor is Ondemand. If you need a high performance governor, use smartassV2, which offers some battery savings.

#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.

#5 - The matr1x kernel by mathkid95 mainly saves power through UV of the INT voltages. You may need to raise these if you have freezes/reboots with your phone (in addition to raising the ARM voltages). I found that a maximum of 1 mA can be saved through INT UV, regardless of whether the CPU becomes idle (or with screen off in deep idle), so this is a constant saving. However, it is a very small saving, and doesn't apply if the phone is asleep. Remember, reboots cost more juice than UV can ever save.

#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!

#7 - If you are determined to UV, I found that my phone would become unstable with UV settings that were fine when the battery was fully charged. So check what UV your phone can handle when your battery is nearly empty. Again I say: Because of the high likelyhood and massive battery drain that comes with a reboot, I highly recommend you DO NOT USE EXCESSIVE UV. Also remember, even with extreme UV, you will not increase battery life more than 2%

#8 - I found that with bluetooth or GPS preventing the TOP=OFF state, there was no additional power saving from Deep Idle, i.e. the TOP=ON state does not save power.

#9 - Kernels with the 65 fps hack will cause the screen to drain about 10% more power compared to the usual 56 fps.

#10 - Conservative does not save power! For further details and exceptions, refer to my new thread: here.

#11 - This is just general advice: if you are having very poor battery life, have you tried turning auto brightness off? And if you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.

#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.

ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.../Babhjhag.html

In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors. From my spreadsheet:

At 100Mhz
mV 1500 4.92mA
mV 950 2.83mA (default mV)
mV 800 2.58mA (UV saves some power)
mV 750 2.96mA (Extreme UV uses MORE power)

Same test but with Deep Idle enabled:
mV 1500 1.91mA
mV 950 1.49mA
mV 800 1.29mA
mV 750 1.49mA (Same result again but with DI enabled)
Referenced from my spreadsheet starting row 41.

Recommended reading: http://everything2.com/title/wafer+yield

Stock voltages for reference:
ARM
1000MHz @1250mV
800 MHz @1200
400 MHz @1050
200 MHz @950
100 MHz @950

INT
1000MHz @1100
800 MHz @1100
400 MHz @1100
200 MHz @1100
100 MHz @1000

Summary of Power States by tchaari (thanks!)

After research, and some explanation from Steve Garon, it is clear that Deep Idle & CPU Idle are two completely different things:
1) Three main CPU states are implemented in the standard android kernel: NORMAL, IDLE and SLEEP
2) Ezekeel added an intermediate 4th state: Deep IDLE. This saves more power but only when the processor has a background task to run while screen is off. Bedalus proved here that it really saves a considerable amount of power in particular cases (e.g. music playing when screen is off). A minority of users are reporting some slight instabilities with it, but they may in fact be caused by things other than deep idle.
3) The CPU IDLE backport is a replacement of the standard android kernel drivers used to put the CPU in idle/sleep states by the new ARM methods integrated in the linux 3.2 kernel. This backport is theoretically supposed to improve battery life (with just the basic 3 CPU states). It is 100% stable but no power saving has been shown either in bedalus' amp meter measurements, or Harbb's overnight drain tests.

Where did the other benchmarks go?

All ICS ROM Benchmarks: this thread

Kernel Features and Benchmarks: this thread

CPU Governors and I/O Schedulers: this thread

Power Saving Governors: this thread

Thanks to all the developers, and a big shout out to: Harbb for his dedicated testing; tchaari for his motivation, great ideas and inspiration; jcolinzheng for the idea to test Deep Idle at fixed frequencies (genius); aLNG for links to interesting and useful articles; Steve Garon for demystifying esoteric kernel technicalities and his excellent kernel itself; everybody else who helped; and of course Ezekeel for making Deep Idle work, and for a stimulating debate!
The Following 133 Users Say Thank You to For This Useful Post: [ Click to Expand ]
bedalus Old
(Last edited by bedalus; 20th February 2012 at 04:16 AM.)
#2  
Guest
Thanks Meter 0
Posts: n/a
Harbb joined in doing specific battery tests, using the phone's battery graph. This is based on the phone's own readings (State of Charge or SoC for short). It's not very accurate for an instant reading, but over time, it does become more and more accurate. Therefore, Harbb conducted some very long (10 hour) tests. To improve accuracy further, he waited for the level of charge to drop to around 80% before each test. This eliminates the another source of inaccuracy, that the first 10% of the battery tends to deplete rather quickly (due to normal wear and tear over its lifetime). In fact, I use Ezekeel's Battery Life eXtender (BLX) to stop the phone charging early (at a user defined level: I prefer 90%) to help slow the deterioration of the battery's maximum capacity by preventing heat damage caused as the battery tries to absorb the final dose of charge above 90%.

Harbb's Data
Harbb's spreadsheet

Here's a summary of Harbb's 10 hour test findings, in order of best battery drain:

- 15% - SmartassV2 with DI
- 16% - Conservative with DI
- 21% - Lazy with DI and SOMF
- 23% - Lazy with DI
- 36% - Conservative
- 39% - Lazy
- 39% - Lazy with CPU IDLE
- 44% - Lazy with Eugene's DIDLE
- 48% - Lazy with Eugene's DIDLE and SOMF

[where DI means Ezekeel's Deep Idle, and SOMF indicates that Screen Off Max Freq was enabled]

Power Misconceptions
1st Misconception:
There is a misconception about about 200MHz using the same power as 100MHz because the voltage is the same. There is an approximate formula for CPU power consumption:

CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)

Capacitance is a constant, so we can ignore it. Let's fill in the values for the lowest and highest frequencies:

100 MHz V=0.95 so V^2=0.9025

1000 MHz V=1.25 so V^2=1.5625

So this shows we have roughly an extra 70% power drain due to the voltage increase. However, the maximum frequency is 10 times the minimum, i.e. a 900% increase. So the dominant factor in CPU power drain is in fact the frequency. Roughly speaking, the frequency has 13 times more influence over the power drain than the voltage.

Therefore, the governor that keeps the frequency as low as possible for as long as possible will save the most power. This appears to be consistent with Harbb's finding that conservative saves the most power.

2nd Misconception:
Some people say that if they UV they can play a game on their phone for an extra hour. The most you can get from UV is 2% extra battery life (and it is not worth the reboot risk).

See post #4 for calculations based on the actual measurements taken from the phone.

Here is a more academic proof using the same formula from the 1st misconception:

CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)

Capacitance is a constant, so we can ignore it. Let's fill in the values for just the highest frequency with the stock voltages and then an extreme undervolt:

1000 MHz V=1.25 so V^2=1.5625 (stock volts)

1000 MHz V=1.2 so V^2=1.44 (the most UV my phone can handle with a fully charged battery)

This is an 8% saving. Happily, this exactly matches what I measured in the real test (see cell F62 in the spreadsheet).

Remember, only the CPU is saving 8%, the screen being on uses about 4 times as much power as the CPU even at its highest frequency. This reduces the power saving to at most 2%.

I am of course assuming the screen is on. For most users, this is correct, as their processor will not be under a heavy load unless the device is in use, and this almost always means the screen is on. If anyone can think of any circumstances where the CPU is under a heavy load, but the screen is off, and show that this happens to all users a high enough proportion of the time to be relevant to this calculation, please let me know. [/far fetched caveat]
The Following 35 Users Say Thank You to For This Useful Post: [ Click to Expand ]
bedalus Old
(Last edited by bedalus; 6th February 2012 at 02:02 PM.)
#3  
Guest
Thanks Meter 0
Posts: n/a
Testing Methodology

Two videos are available, and note, a circuit diagram of test now linked within the battery benchmark spreadsheet. I've decided to share it publicly as I've now set up and run this test three separate times, with no major problems. So I've reclassified it from utterly reckless, to merely dangerously stupid. Do not under any circumstances try this with your own phone! You have been warned!

You cannot trust battery monitor widget. (More on that in the 4th post)

Here's a way to test Deep Idle without rewiring your phone:
Note - SOMF means Screen Off Max Frequency

Setup must be identical (apart from SOMF). Install battery monitor widget, set history update rate to 10 minutes (not particularly to monitor the battery, but just to act as a timer). Set to run without widget. Turn off all radios, turn off sync, turn off location services, put in airplane mode. Turn off any of Ezekeel's mods excepting (Deep Idle of course). Set up your music app to play the same song on a loop. Make sure all volumes are down. Phone must be in mute. Turn of auto-brightness just in case. Morfic told me that to avoid the problem of the battery not reporting itself properly you can begin both tests with the same charging procedure: charge while off overnight. In the morning bump charge for exactly one hour. Disconnect, boot, start music immediately. Power button to screen off. Leave phone for 48 hours (should be enough time to auto power off).

After the first test, check the history from battery monitor widget to see how long the phone was on for.

Repeat again but with SOMF set to on.


***

Here's more on metering the amps:
REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
If you're thinking this is something you'd like to try, you'll need:
1) An analogue multimeter or pure ammeter because a digital one will be difficult to read with constantly changing amps.
2) Two battery caddies with space for 3 AA batteries each.
3) Six rechargeable batteries. Use rechargable ones because the volts are a bit less, 3*1.35=4.05 - close enough to the spec 3.7
4) Lots of cables with crocodile clip ends
5) Some fine copper wire

If you're thinking of soldering something onto your battery, DON'T - you may accidentally make a short circuit that will be difficult to undo, and cause the battery to explode. Plus the heat of the soldering iron certainly won't do it any good. And don't solder anything onto your phone contacts, just carefully twist a few strands of copper wire around them, so they can be easily removed. REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.

[Q] Why do I need 6 AA batteries when 3 would provide enough volts?
[A] My multimeter inserts a 600 ohm resistor into the circuit (yours may be less, and if so you will need different calculations to convert to amps). This resistor allows the multimeter to evaluate the amps by measuring the voltage drop across it. But the resistance will cause your phone to starve of power. Running a parallel battery to the phone will prevent it crashing when the voltage supply isn't sufficient for things like screen on+cpu max frequency+sdcard IO... This parallel supply should run directly to the phone, not through the multimeter. It can be disconnected when the screen is off, and will not harm the phone. Remember to reattach it before powering on your screen, or it is likely your phone will crash. I would advise to start with fully recharged batteries, and not connect the USB charger.
[Q] Won't the amps read half of what is actually being drawn?
[A] Yes, but you'll get the correct reading if you unhook the parallel battery.
[Q] Might I also be able to do that when the screen is on?
[A] Yes, but I recommend that you do that with everything possible powered off, wifi, 3G... etc... screen brightness minimum. Set your screen timeout to never, so that you have control over it with the power button. Always reconnect your parallel battery before changing from screen on to screen off, and visa versa. (Due to large power spike)
[Q] I want to try this. Should I?
[A] No, no-one should try this.
The Following 14 Users Say Thank You to For This Useful Post: [ Click to Expand ]
bedalus Old
(Last edited by bedalus; 17th February 2012 at 03:46 PM.)
#4  
Guest
Thanks Meter 0
Posts: n/a
Miscellaneous

[Q] You claim you cannot increase battery life using UV beyond 2%. Justify yourself!
[A] When the processor is in use (i.e. not asleep or idle) UV does save a tiny amount of power. I tested with the most extreme UV my phone could handle. With a high performance governor, e.g. smartassv2, extreme UV would reduce CPU drain by 13%, or about 7 mA. With a governor that keeps the CPU frequency low, CPU drain would be reduced by about 18%, or 4.6 mA (weighted - see the spreadsheet starting cell H88).

Remember, these savings are limited to the processor, and only when it is active. For most users, this will mean the screen is on. For comparison, the screen on minimum brightness displaying black uses 9mA. On max brightness, displaying white, it uses 690mA. Let us assume some median value, ~350 mA.

A saving of 4.6 mA out of at least 350 mA (screen) plus 20 mA (CPU)
= 1.2%

A saving of 7 mA out of at least 350 mA (screen) plus 50 mA (CPU)
= 1.8%

So, regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%.

Articles and Documents
Diane Hackborn's article on the formula that produces the dodgy Android OS usage statistic in the battery menu:

https://plus.google.com/105051985738...ts/FV3LVtdVxPT
(note, this bug is fixed as of Android 4.0.4)

Data sheet for the fuel gauge chip:
http://www.maxim-ic.com/datasheet/index.mvp/id/6621

Link to great article on SOC (State of Charge) http://www.mpoweruk.com/soc.htm >>> explains all the reasons why I don't trust battery monitor widget and the phone's own battery stats.

Great article on the difficulties of accurate metering (thanks aLNG):
http://low-powerwireless.com/blog/de...evices-part-1/

In the article DUT stands for Device Under Test

The implication is that DMM [Digital Multi Meter] voltage drop readings (to measure amps) take hundreds of milliseconds, a will miss instantaneous battery savings above this time window. However, I am using an analogue meter, the the needle responds to all current. Due to the mass of the needle, there is inertia to overcome, which provides a form of averaging.

Quote from the article:
"a GSM cell phone can have current pulses of 2 amperes that last approximately 500μs while the power amplifier is on and transmitting, and then drop back down to the milliampere level for the remainder of the 4.5 ms GSM cycle."

500μs is 0.5ms, so is 1 tenth of the 5ms GSM cycle. 2 amps at 1/10th of 5ms = average of 200 mA

When I ran the test with my equipment, GSM broadcasting uses at least 170 mA - see row 36. I think this is a nice proof that the analogue multimeter beats the digital multimeter hands down for dynamic amps (i.e. changes happening below the millisecond level.) I'm also very satisfied that my result is close to the result stipulated by the article. It improves faith that my readings are accurate.

[Q] What could add inaccuracy to the readings?
[A] The dBm scale assumes a resistance of 600 ohms, but the resistor has 3% accuracy which means it could be as high as 618 ohms, or as low as 584 ohms.
[A] Also, the scale is very small, so I've read the needle to the nearest fifth of a dB

Other articles (thanks aLNG)
A study of the mA drain of various components of a smartphone
http://www.usenix.org/event/atc10/te...rs/Carroll.pdf
An ARM presentation on unifying power management procedures in the kernel
http://elinux.org/images/0/09/Elce11_pieralisi.pdf
The Following 23 Users Say Thank You to For This Useful Post: [ Click to Expand ]
bedalus Old
(Last edited by bedalus; 3rd February 2012 at 04:17 PM.)
#5  
Guest
Thanks Meter 0
Posts: n/a
UPDATE: Undervolting the CPU tested (using nstools ARM+INT)
UPDATE: impact of different screen colours tested (amoled)
UPDATE: Running apps tested.

Please note, the running apps draw power for lots of different reasons, access RAM, CPU, I/O, Graphics, all use power, what's being displayed also uses power, eg a brighter 3D scene vs a darker 3D scene. But it does give an overall idea of what Amps might be pulled when you are using the phone normally.
The Following 9 Users Say Thank You to For This Useful Post: [ Click to Expand ]
 
mobile_pc
Old
#6  
mobile_pc's Avatar
Senior Member
Thanks Meter 53
Posts: 223
Join Date: Jan 2012
Thanks for your hard works I'm impressed with the systematic research.

Many things just the theoretical possibility? just something we created in our minds...
The Following User Says Thank You to mobile_pc For This Useful Post: [ Click to Expand ]
bedalus Old
#7  
Guest
Thanks Meter 0
Posts: n/a
Quote:
Originally Posted by mobile_pc View Post
Thanks for your hard works I'm impressed with the systematic research.

Many things just the theoretical possibility? just something we created in our minds...
Indeed, i agree. Now, with no benefit to under volting, perhaps we can all suffer less reboots.

For kernel benchmarks and more, see here: http://goo.gl/mpeHI
The Following 4 Users Say Thank You to For This Useful Post: [ Click to Expand ]
 
polobunny
Old
#8  
polobunny's Avatar
Senior Member
Thanks Meter 2,408
Posts: 5,978
Join Date: Oct 2011
Location: Montreal
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.

Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?

The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.

Cheers
Please press THANKS if someone helps you!

My current configuration:
 

Device: Samsung Galaxy S3 SGH-i747M
ROM: cm-11-20140827-NIGHTLY-d2lte
Kernel: Harkness
Baseband: I747MVLDMF1
Bootloader: I747MVLDMF1
Governor: Interactive


Older device: Nexus S i9020A
bedalus Old
#9  
Guest
Thanks Meter 0
Posts: n/a
Quote:
Originally Posted by polobunny View Post
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.

Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?

The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.

Cheers
The frequency information is there in the first column, eg 400/400 means the min and max settings were both 400. If you're not changing frequencies you can get it down very low.

Yes, perhaps nstools is defective. However, i did get an instant reboot with the lowest setting. Want me to do a repeat in GB?

For kernel benchmarks and more, see here: http://goo.gl/mpeHI
The Following User Says Thank You to For This Useful Post: [ Click to Expand ]
 
italia0101
Old
(Last edited by italia0101; 3rd February 2012 at 07:41 PM.)
#10  
italia0101's Avatar
Senior Member
Thanks Meter 864
Posts: 2,818
Join Date: Nov 2008
So undervolting does nothing? That seems strange ...

Also what about using juice defender? Worth it ?

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes