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.jsp?topic=/com.arm.doc.ddi0344k/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!
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]
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.
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/105051985738280261832/posts/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/d...t-schemes-for-battery-powered-devices-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
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.
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...
mobile_pc said:
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...
Click to expand...
Click to collapse
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
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
polobunny said:
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
Click to expand...
Click to collapse
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
So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?
italia0101 said:
So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?
Click to expand...
Click to collapse
Yeah, does nothing to save battery. I don't know what juice defender is?
Sent from my SNES
polobunny said:
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
Click to expand...
Click to collapse
Okay, I went ahead and tested Gingerbread (carbon, ICS themed Oxygen 2.3.1, android 2.3.7) using franco's last kernel for GB. Starts at row 329.
Neither extreme undervolting nor overvolting had any impact on the battery drain.
Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync
italia0101 said:
Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync
Click to expand...
Click to collapse
Sounds sensible enough to me!
Sent from my SNES
Some reserves
bedalus said:
2 - If you use NStools to undervolt, don't bother. No gain to be had from undervolting either ARM or INT voltages. I tested this to the extreme. Check the spreadsheet, near the bottom. (Tested in both ICS and GB).
Click to expand...
Click to collapse
First, I want to thank you for all your efforts in the benchmarks especially for the battery drain. However, I kindly have some reserves on this. Maybe undervolting does not save so much power at idle but at higher loads, energy can be surely saved. Besides, maybe the energy saved is too minimal for your analog multimeter and it can't be noticed on it.
This is the theory :
The switching power dissipated by a chip using static CMOS gates is C·V2·f, where C is the capacitance being switched per clock cycle, V is voltage, and f is the switching frequency,[1] so this part of the power consumption decreases quadratically with voltage.
Click to expand...
Click to collapse
source : http://en.wikipedia.org/wiki/Dynamic_voltage_scaling
And this a more practical reference about a study made by tom's hardware on AMD Athlon clock, voltage and power consumption. I think it can be generalized (at a smaller scale) for our ARM processor in the nexus S:
It’s only when we change the voltage that we're able to significantly save more power--about 13 watts lower consumption, or a total of 20 watts compared to running without power management. That's a savings of 25%.
Click to expand...
Click to collapse
source (you may also read the entire article. It is very significant):
http://www.tomshardware.com/reviews/processor-power-management,2453-9.html
Other scientific papers and studies can be also found stating that undervolting saves power.
Kind regards.
I also appreciate all the hard work you have done for testing, on both kernels and everything, but im going to "gingerly" throw my hat in with tchaari here...
The only way to actually test battery drain would be to attach a multimeter and let it drain all the way on every test, using every kernel, and every setting - multiple times to omit false positives. Obviously this is beyond the acceptable timeframe it would actually take to accomplish. anyone would go insane sitting there waiting.
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice, your kernel/gov choice affects how the program runs too...also the status of your battery makes a difference. is it past it's half cycle life? etc..then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
so it's nice to see a massive sheet like you did, as it does give a good start point reference - but it should be used not as chipped into stone law either.
Thanks for taking the time to give a great, no excellent base line to work off of though and preform more intense testing if people would like to go that far.
t3xboar said:
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice... then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
Click to expand...
Click to collapse
What program? I'm playing a loop of silence in the music app to keep the processor awake.
The multimeter I'm using isn't fancy, but even if it's reading 10% down, it's doing it for all readings, so it's a fair comparison.
t3xboar said:
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
Click to expand...
Click to collapse
What makes you say we know this? I want to get to the bottom of this, so i need to see a concrete source.
Tchaari posted the capacitance times volts squared times frequency formula. I know this, and when I adjust the ARM voltage by more than half a volt, i expect to see this:
0.8x0.8=0.64
1.5x1.5=2.25
That should be 3.5 times as much power use.
Now, double the power in the dB scale is a difference of ~3dB. 3.5 times ~5dB. And I can notice a change of 1/5th of a dB on my multimeter's scale. There was no change. Here is how i tested.
Start music. Go into nstools, set ondemand with min and max at the same frequency. Go to volt, select the lowest possible voltage for that freq and exit. Screen off, measure amps. Screen on, nstools, volts, highest volts this time, exit, screen off, measure amps. Result: identical.
Seriously, if you have a background in electronics, have a go yourself (NO ONE SHOULD TRY THIS THEMSELVES) and get back to me.
In theory, it should save power, but it isn't. I'd love to be able to say why. At this point i don't think it's a problem with nstools, because i got a crash the second i put the volts to minimum when i was testing on Steve's kernel in ICS.
Sent from my SNES
As contradictory as some of these results may (or may not) be, bedalus is in the right with his methodology as far as i can see. Though at this point nothing should be set in stone. Not yet at least.
A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Sent from my SNES
bedalus said:
A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Click to expand...
Click to collapse
That is a good idea bedalus but it seems that undervolting gain is very minimal instantly. In a long period, it can make some difference in battery life...
I have also many doubts about how sensitive your amps-meter is? Since we are dealing with small values in our case, maybe a more sensitive device can measure some difference that yours can't...
Anyway, your work is very interesting and as Harbb said : At this point, nothing should be set in stone yet.
Related
You can overclock n1 only to 1.190ghz, while desire hd 1.9ghz and the htc desire Z (G2) 2.0ghz. Does N1 has to old cpu?
-------------------------------------
Sent via the XDA Tapatalk App with my Sexy Nexy
Yes. 1st Gen snapdragon
Sent from my Nexus One using XDA App
if you want to OC you N1 go and OC you Desktop is the best choice
Why would you wanna over clock your phone? I have my N1 clocked @ 691 and works really fast with the MIUI rom and battery performance is better than stock. I'm not a fan of custom rom & rooting but I been pretty pleased so far. overclocking the nexus one will drain your battery like crazy plus the 1st Gen of snapdragons weren't as good with graphics as the A4chips and humming birds.
i have mine underclocked too and it works fine. try going a step further and underclocking it to like 422 when it's sleeping/standby. it'll help your battery
josemedina1983 said:
Why would you wanna over clock your phone? I have my N1 clocked @ 691 and works really fast with the MIUI rom and battery performance is better than stock. I'm not a fan of custom rom & rooting but I been pretty pleased so far. overclocking the nexus one will drain your battery like crazy plus the 1st Gen of snapdragons weren't as good with graphics as the A4chips and humming birds.
Click to expand...
Click to collapse
The connection between clockspeed and power consumption is not as strong as you think. But without a doubt it has an influence. Much more important is the voltage. If you "undervolt" the Nexus One CPU you can even get better battery live with higher clockspeed.
And if you use a tool to change the clockspeed depending on the situation (display on/off, battery % left, workload) and undervolt the cpu you can safe A LOT of juice.
With Wildmonks kernel, MIUI and SetCPU I get a much better lifetime than ever before even though my Nexus runs at 1152MHz.
Actually, the frequency makes a BIG difference in power consumption. Think of it this way - each clock causes changes propagating in transistors, which are the actual power draw. More clocks = more changes = more power drawn. As easy as that.
So, having 10% higher frequency and 10% lower voltage compensates each other.
Nexus has examples that overclock to 1.5GHz when overvolted, like Desire Z and Desire HD (both of those have to be overvolted to go up stable from 1.2GHz). Most of Nexus Ones fail when overclocking and don't reach higher than 1.2GHz, but it might be not because of the CPU, but because of other devices on system board.
Generally, it is only when you change the voltage (which is required to stabilize the higher frequency) that you see noticeable differences in battery life.
Jack_R1 said:
Actually, the frequency makes a BIG difference in power consumption. Think of it this way - each clock causes changes propagating in transistors, which are the actual power draw. More clocks = more changes = more power drawn. As easy as that.
So, having 10% higher frequency and 10% lower voltage compensates each other.
Nexus has examples that overclock to 1.5GHz when overvolted, like Desire Z and Desire HD (both of those have to be overvolted to go up stable from 1.2GHz). Most of Nexus Ones fail when overclocking and don't reach higher than 1.2GHz, but it might be not because of the CPU, but because of other devices on system board.
Click to expand...
Click to collapse
willverduzco said:
Generally, it is only when you change the voltage (which is required to stabilize the higher frequency) that you see noticeable differences in battery life.
Click to expand...
Click to collapse
Ok, some additions required.
Leakage is also dependent on power, and the dependency graph isn't linear - and starts breaking upwards at some point, usually being a tad above the max designed voltage.
Going down in voltage makes leakage change approximately linear, and doesn't affect nearly as much as going up.
Overclocking will draw power just as I noted above - exactly with the same percentage difference - only when the clock is reaching the overclocked area, which happens only when you're playing games or doing CPU-intensive tasks.
Undervolting will affect leakage, which happens 100% of the time.
So yes, when running in dynamically scaled environment, undervolting has more effect than overclocking. On desktop PC, running the same clock frequency constantly, the effect is the same.
Very True. And I wasn't saying that overclocking, while at the same voltage, didn't draw ANY more power... I just am trying to say that (for example in this graph) overclocking only has a small effect on power draw until you actually change the voltage. In that same example, going from 3.4 to 3.8 GHz only adds about 6% current draw while at the same vCore, while going up a similar amount in clock speed.
I'd even wager to say that if you're slightly under-volted and as heavily overclocked as you can go at that given voltage, you'll save some trivial amount of power versus stock because of the fact that voltage affects power draw significantly more than clock speed. I would also wager that if you are at an overclocked speed and are at stock voltage, the amount of current and power draw will be almost indistinguishable to the end user, since things like display will almost always use much more power if the display is on for any appreciable amount of time.
Jack_R1 said:
Ok, some additions required.
Leakage is also dependent on power, and the dependency graph isn't linear - and starts breaking upwards at some point, usually being a tad above the max designed voltage.
Going down in voltage makes leakage change approximately linear, and doesn't affect nearly as much as going up.
Overclocking will draw power just as I noted above - exactly with the same percentage difference - only when the clock is reaching the overclocked area, which happens only when you're playing games or doing CPU-intensive tasks.
Undervolting will affect leakage, which happens 100% of the time.
So yes, when running in dynamically scaled environment, undervolting has more effect than overclocking. On desktop PC, running the same clock frequency constantly, the effect is the same.
Click to expand...
Click to collapse
Jack_R1 said:
Actually, the frequency makes a BIG difference in power consumption. Think of it this way - each clock causes changes propagating in transistors, which are the actual power draw. More clocks = more changes = more power drawn. As easy as that.
So, having 10% higher frequency and 10% lower voltage compensates each other
Click to expand...
Click to collapse
I wouldn't call 10% more peak power consumption big if you take in account that the cpu is only running at the max clock speed a very small amount of time. 90% of the time the device is sleeping anyway and even if it's not you barely need the max clock speed. But if you do you will recognize the difference.
On the other side the reduced voltaged can safe you power all the time.
willverduzco said:
I'd even wager to say that if you're slightly under-volted and as heavily overclocked as you can go at that given voltage, you'll save some trivial amount of power versus stock because of the fact that voltage affects power draw significantly more than clock speed. I would also wager that if you are at an overclocked speed and are at stock voltage, the amount of current and power draw will be almost indistinguishable to the end user, since things like display will almost always use much more power if the display is on for any appreciable amount of time.
Click to expand...
Click to collapse
That's exactly what I experienced.
Pommes_Schranke said:
I wouldn't call 10% more peak power consumption big if you take in account that the cpu is only running at the max clock speed a very small amount of time. 90% of the time the device is sleeping anyway and even if it's not you barely need the max clock speed. But if you do you will recognize the difference.
On the other side the reduced voltaged can safe you power all the time.
Click to expand...
Click to collapse
Yes, you're right, and that's why I corrected myself in my second post. I totally forgot about the frequency scaling.
Off topic, but this is why I love XDA. Rational debate over a subject by intelligent people, where there usually isn't flaming. Thanks added to the two of your posts.
Hi, I spend last few days optimizing voltage table on my Desire and it left me wondering.
I bumped into several situations where 2 or 3 frequencies would be stable on the same voltage level. My question is, theoretically, if 300MHz would use the same voltage as 800MHz, would the power consumption increase proportionally or would it remain fairly similar?
Seeing that 300MHz would need more burn time at the same voltage to complete a task that 800 MHz would do in fraction of that time and then idle, this leaves me puzzled. Is it better to always use highest frequency of the group with same voltage for better efficiency? Or does the slower frequency actually consume less power even though it has to work longer and uses the same voltage?
Please enlighten me or discuss
I would also like to be enlightened on this.
AFAIK your assumption is on the right track, get the job done as quick as possible & get back to idling...
Slightly off topic, but somewhat relevant
byrong did a great write up on the effects of cpu speed vs screen brightness power consumption here that may be be of interest...
Interesting but still doesn't answer one question:
If my 245, 368 and 768MHz would be stable at the same voltage, does it matter if I set 768MHz as my minimum/idle frequency instead of 245MHz? Would is consume more power in the long run say on conservative governor?
And what about the screen-off profile? Consider a scenario when I'm playing an MP3 while screen is off and the player will still take a lot of CPU power to pre-buffer the song, apply equalizer, post-processing etc. Now would that nearly constant burn theoretically consume more power on the 245MHz or 768MHz? It still has to do the same work and 245MHz should just have higher constant load, right?
And how about complete idle. Does it really matter if I idle on 245 or 768 MHz if the voltage and actual work done is identical?
This is I'm sure something everybody is asking but nobody knows the real answer. Unless I'm speaking utter rubbish it's perhaps time to run some tests.
Even if the voltages are the same for different frequencies, I'm sure higher frequencies draw higher amounts of current (as shown in byrong's research, although his voltage tables were not stated). If you change your min cpu freq from 245 to 768 MHz I'd almost guarantee more power consumption, even when idle. I could be wrong though. If you're so curious, why don't you try and post back?
I might be wrong but my $0.02
From what I can remember in class, Power = voltage x current
To do the same amount of work, supplying lesser voltage would mean more current is consumed. That said, if less work is being done at the same voltage, less current would be consumed.
So running the CPU at a slower clock cycle means less work is being done, so less current consumption, compared to running it at full 768MHz.
I think ... ;p
Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Even if your $0.02 are right, you're still talking about drawing less current over longer time or more current in a short burst. Of course there are apps like games that will probably take as much horsepower as they can get for redrawing the screen - in that case lower constant frequency is better, because higher frequency would actually have to do more work - drawing more FPS just because it can. For minimum frequency the situation is completely different as the apps only require bursts of workload.
nik3r said:
Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Click to expand...
Click to collapse
I thought you read waydownsouth's link?
In the methodology section byrong states he used CurrentWidget to log current over time. You can also use Battery Monitor Widget.
By the way, his methodology is pretty excellent as it minimizes as many variables as possible, and he wrote his own script to keep the cpu working at a controlled rate. I think at a minimum, you should put the phone in airplane mode while conducting the tests.
Hello everyone.
I used to be very disappointed on the battery performance of our stock roms. Our customs roms solved many problems but this battery problem stayed for some people like me.! So i started experimenting on various categories and now i finally have a sufficient battery backup of around 40 hours that keeps me and my android going!!
So here is how to save your damn precious battery!!
It has worked for some people i know and i hope it do work for you too!!
I am using fugumod ultra kernal and it gives me absolutely no lags at all + a super duper battery!!
-Battery Calibration [ROOT]
Whenever you flash any new custom rom, you should always calibrate your battery! Here is an app that does that!!
<Appbrain Link>
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
-Flash Fugumod ultra kernel (Strictly for Fugumod Ultra) )<link>
Flash this kernel and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance
CONFUSED Yes this thing sounds crazy!! But you can always try. I have written this after experiencing it myself!!
-For G3Mod Kernels & Other Versions Of fugumod [OverClocked]
Follow these steps:
Install Setcpu/ Any other cpu controll app
Set Max value to the highest frequency. Minimum between 300-400.
Now using the profiles option set POWERSAVE governor to those times when you wont be using your phone much (ex:while sleeping).
Then for other times use ONDEMAND governor.
While charging profile is set then make sure that governor is set as PERFORMANCE.
You may also try other governors. Haven't tried... (suggestions welcome)
-Install Auto Memory Manager app[ROOT]
Auto memory app automatically kills apps that runs in background based on the profile u set!! After installing the app, use the aggressive profile and the lower the Hidden Application slider to in between 30-40 mb, so that your important background apps are not killed unless the ram is very low..!!
<Appbrain Link>
----------------Alternative For Auto Memory Manager-------------------------
- Supercharger script
Supercharger script is also a great alternative.. You need to run the script from your rooted rom using terminal emulator. See this <link>
This script is included in most of the recent custom roms. See their respective version changelog for info.
Now your phone will be lag free..!! It has been tested and working!! My android phone runs the way it should!!
Lets jump to battery problems
-Battery Calibration has to be done.!!
-After that I recommend you to use your resources a bit cleverly!! Data connection takes a lot of battery for me.! Now fine you need internet when you are on the move. But you don't need it while sleeping do you??
android apps requiring data connection to retrieve data keep on retrieving it even while you sleep but you only see that data after waking up and getting out of our bed. So you should shut off internet while sleeping!!
-Now display.
display consumes battery!! best is to keep display to 10 when its dark!! And around 40 during the day!
I keep it to zero all the time and use keep toggling it to max only when i need it using dimmer!!
<appbrain link>
-3d Gallery. (thanks rai_tushar)
Consumes a lot of battery!! Use quickpic. Better and faster alternative
<appbrain link>
More tips by rudolf895
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
So i think that should be it.!!
One last trick.
If you use tasker or any other automation app try this.
(With respect to tasker)
Make a new context>state>plugged in
Then make a new task for the context>app>load app>Fast reboot <link>
So whenever you will plug in your phone the app be will run automatically and then your phone will be free from any lags.
Data Connection uses lots of battery and will result in battery drain. Most of the time many data is retrieved when you wont be viewing it/using it. But it will result in wastage of data. So u need to make sure you use your data connection wisely
i would highly recommend you all to use tasker app for automation of your android phone. Automatically toggle display, mobile data etc depending upon various contexts (application, time, location). Read THIS thread for more information on tasker.
Conclusion
If you want a rock solid battery and an android phone that should be proud of its speed, and you are not getting any solution, go ahead and try the above..!!
Battery setting may or may not suit you!! This was just a sharing of my experiences which i had en-route to getting a lag-free/rock-battery.
Happy Androiding!!
Thank you for it, but your "this" does not link to any thread. However, I'm assuming you mean for it to be the link that the "here" for the 'ultimate android app' links to. Might want to change that. Thanks for the tips, though.
Mohit12 said:
Thank you for it, but your "this" does not link to any thread. However, I'm assuming you mean for it to be the link that the "here" for the 'ultimate android app' links to. Might want to change that. Thanks for the tips, though.
Click to expand...
Click to collapse
Thanks a lot for that!! Fixed the link!!
Yes its the ultimate app!!
Idk why keep higher minimum CPU frequency your battery should have drained faster even when your phone would be idle..
For me this worked :
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
Hope this helps some one. ;-)
Tapatalked from my super smooth, ultra fast samsung galaxy s2.
neo1691 said:
-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance
Click to expand...
Click to collapse
this doesn't make sense, if you set governor to performance your phone will be running at 1366 mhz at all times regardless of minimum frequency and that will murder your battery. Make a profile for screen off and set it to 83 or166min and 222 or 333 max and ondemand governor, that will save you some battery. When you use the phone set the max frequency to 667 or 800 with conservative or ondemand. Use high freq only when needed - for playing heavy games
rudolf895 said:
Idk why keep higher minimum CPU frequency your battery should have drained faster even when your phone would be idle..
For me this worked :
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
Hope this helps some one. ;-)
Tapatalked from my super smooth, ultra fast samsung galaxy s2.
Click to expand...
Click to collapse
this doesn't make sense, if you set governor to performance your phone will be running at 1366 mhz at all times regardless of minimum frequency and that will murder your battery. Make a profile for screen off and set it to 83 or166min and 222 or 333 max and ondemand governor, that will save you some battery. When you use the phone set the max frequency to 667 or 800 with conservative or ondemand. Use high freq only when needed - for playing heavy games
Click to expand...
Click to collapse
I was excepting this post from someone.. Yes you might say why keep governor to performance with 1366 max.. well thats how we tackle lag!!!
@rudolf!
Surprisingly battery drain is very less for me (and some others too) with these tweaks.. otherwise why would i share them!!
1 more solution:-gallery 3d uses more battery
u can use quickpic as a replacement
rai_tushar said:
1 more solution:-gallery 3d uses more battery
u can use quickpic as a replacement
Click to expand...
Click to collapse
exactly.. Thank you. will update the op as soon as I find a laptop., I always use quick pic but never really considered it a battery saver..
Disabling SNS is also a good way to save battery.
Not applying the RAM optimization script provided in the Dev section will also save battery 'cus I have faced increased battery drain with it.
And does reducing the voltage save battery? If so.. can you please provide some info about it..??
Enviado desde mi Galaxy 3
thanks for the info as i was just about to install the ram optimization tool but considering that it sucks more battery, i wont do it
danveer said:
thanks for the info as i was just about to install the ram optimization tool but considering that it sucks more battery, i wont do it
Click to expand...
Click to collapse
Try the above . Of that still don't help you, then you are can try ram optimization
"-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance"
with this, the battery will last a full day maximum (with normal-low usage)!
kyrillos13 said:
"-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance"
with this, the battery will last a full day maximum (with normal-low usage)!
Click to expand...
Click to collapse
agreed.. theoretically it should last not more than one day!! but seriously i have tried that and my phone practically lasts for more than 35 hours..
And that's y i am sharing the info!!
EDIT: setcpu v 2.1.3
ron_gangte said:
Disabling SNS is also a good way to save battery.
Not applying the RAM optimization script provided in the Dev section will also save battery 'cus I have faced increased battery drain with it.
And does reducing the voltage save battery? If so.. can you please provide some info about it..??
Enviado desde mi Galaxy 3
Click to expand...
Click to collapse
Reducing the voltage to the CPU may cause problems and will not save any battery. You can think of it like a simple circuit, with the CPU effective being a "resistor". so you have just a battery, voltage regulator, and CPU, as you reduce voltage, amperage will increase (and battery drain will actually increase!!!) Amperage is what drains your battery, not voltage.
My recommendations (I have tertiary electrical engineer qualifications to back me up)
- Stick with the stock voltages for the different frequencies you use.
- To save battery, turn off wifi & bluetooth when you are not using them.
- Install APNDroid, to easily switch 3G/EDGE data off when not needed (still allows you to receive MMS messages when data is off, and has a widget)
- Set your screen to the minimum brightness that you can (but so that the display is still bright enough to use)
- Turn of "Power Saving" in display settings (actually uses more power than it saves 9 times out of 10)
- Use task manager, or a ram management tool to kill apps that don't need to be running in the background, and always use the back button to go out of apps, the home button will leave the app running in the background (sucking battery and slowing the phone down)
- If using a CPU management tool set minimum to 83MHz (or lowest your phone is happy with, or that you are happy with to kill lag), set maximum to whatever you like (that phone can handle) and use a governor like "on demand". Set up profiles to lower maximum frequency when screen is off, or temp is high (higher temperatures will result in faster discharge off battery)
I do all of this, and I can get up to 3 days use without charging (depending on usage)
Things that will drain your battery the most (highest power usage):
- Wifi
- Bluetooth
- 3G/EDGE
- Screen
- Phone calls
nrk_2k said:
Reducing the voltage to the CPU may cause problems and will not save any battery. You can think of it like a simple circuit, with the CPU effective being a "resistor". so you have just a battery, voltage regulator, and CPU, as you reduce voltage, amperage will increase (and battery drain will actually increase!!!) Amperage is what drains your battery, not voltage.
Click to expand...
Click to collapse
sry, but this is completely wrong.
if it was true what you said increasing the voltage would save power...
decreasing the voltage DOES save power, but unless the CPU isn't running at maximum load the whole time you won't see a big difference.
the frequency of the CPU raises the consumed wattage linearly while voltage goes into the calculation by square. so decreasing the voltage is the best option to lower the consumed power of the CPU as the speed isn't affected. problem is of course that the CPU won't run below a certain limit. the CPU in my G3 is running 800MHz @ 1.125V which is 75mV below stock (667MHz).
the amperage does not change while undervolting.
sharukins said:
sry, but this is completely wrong.
if it was true what you said increasing the voltage would save power...
decreasing the voltage DOES save power, but unless the CPU isn't running at maximum load the whole time you won't see a big difference.
the frequency of the CPU raises the consumed wattage linearly while voltage goes into the calculation by square. so decreasing the voltage is the best option to lower the consumed power of the CPU as the speed isn't affected. problem is of course that the CPU won't run below a certain limit. the CPU in my G3 is running 800MHz @ 1.125V which is 75mV below stock (667MHz).
the amperage does not change while undervolting.
Click to expand...
Click to collapse
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
nrk_2k said:
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
Click to expand...
Click to collapse
well i am having just perfect battery without undervoltage..!! :
but ya definitely learned many new things from the above discussions
nrk_2k said:
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
Click to expand...
Click to collapse
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
sharukins said:
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
Click to expand...
Click to collapse
now thats what i call some serious battery saver
sharukins said:
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
Click to expand...
Click to collapse
Would have to disagree about a true measure of battery capacity being the Wh, or mWh, as wattage depends on load, and since you never run a battery with 0 load, you cannot represent its capacity using Wh or mWh. I have studied batteries intimately at university level, and know exactly how & why they work. the mAh (Ah) is the industry wide accepted unit for battery capacity, as no matter what the load it is always constant. I am happy to agree that wattage is not always constant for a set frequency on a CPU (as it is possible to over-voltage for that frequency), but for processors such as those which are used in our phones, you very rarely find any substantial over-voltage as due to modern manufacturing techniques there is a much tighter range of voltage acceptance for the core. Hence why most people get only a minute (completely stable) undervoltage. And anyone who would actually gain from undervoltage, would be able to tell that their CPU is using excess energy as ALL this energy would be dispersed as heat. Any extra wattage drawn over what is actually required by the components inside the CPU will be converted to heat as it is not required by the components to run. So unless you see excess heat from your CPU, undervolting will only achieve degraded performance, or CPU stalls. And it is at this point that it will drain the battery more, as there is a minimum wattage that a set frequency requires, if you drop the voltage below what it should be, the amperage will increase to mantain the minimum wattage required (or the CPU will stall and the phone will freeze/switch off). The only real world point to undervolting a CPU is for cooling purposes, the energy savings from doing so are minuscule, to none, and can to a point end up consuming more battery. You would save far more battery by lowering your screen brightness by a few percent.
I haven't been able to find any info on undervolting the Xoom, so have started this thread in the hope that some may find it beneficial.
What is undervolting?
It basically involves reducing the amount of electrical voltage running through the CPU. It does not affect the speed of the CPU at all, just the amount of power that it uses. The stock configuration of CPUs usually has a fairly high voltage, to cater for the fact that CPUs are not exactly identical.
Why undervolt?
Reduce power consumption, and therefore increase battery life.
Why not undervolt?
Can affect stability, and there is a small risk of damage to your device.
Disclaimer: Undervolting, like overclocking, does have the potential to damage your device. It's very rare, but not unheard of. I've never had a problem, but you may. Good luck, and don't blame me.
My config:
Model: MZ601 Xoom
Kernel: Tiamat Xoom v2.1.0
Undervolting software: SetCPU 2.2.4
My voltages before UV:
MHz mV
216 770
312 770
456 825
608 900
760 975
816 1000
912 1050
1000 1100
1200 1150
1408 1250
1504 1325
1600 1400
1704 1400
So after doing a bit of testing, I've found that I can lower my voltages noticeably throughout the range, reducing the amount of power my Xoom uses, and prolonging my battery.
My UV voltages:
MHz mV
216 770
312 770
456 775
608 825
760 875
816 925
912 975
1000 1000
1200 1075
1408 1125
1504 1175
1600 1250
1704 1325
Notes:
It is not possible to UV any less than 770 mV (with the kernel I'm using anyway).
Given that the mV for the 456 CPU frequency is so similar to 216, I set my minimum clock frequency to 456, which makes the device more responsive.
So, you may want to try these voltages, and see how they work for you.
To test: (Instructions for SetCPU)
Set your min & max speeds to the same frequency, for example 456.
Set the voltage of the 456 frequency to an amount lower that the current amount, for example 775. (It's generally best to adjust your voltage down only 25mv at a time.)
Perform a "Stress Test", for at least about 5 seconds.
If the device locks up or reboots, the mV is too low - try a higher mV.
Once you've found the optimal voltage for that frequency, move onto the next one, for example 608, then 760, etc.
If your device locks up or freezes during testing, you can force a reboot by holding down the Volume Up button, and the Power button.
The voltages I've used above may work for you, or you may have to increase them a little on your device. You may also get better voltages than me - if so, please post your results.
Battery test results
Performed some battery performance testing by doing the following steps:
1. Set the screen to not turn off, and brightness to 10% (screen needs to be on to keep the stress test running, and brightness low to minimise the battery drain of the screen, as that's not what we're testing).
2. Disabled all network connections (WiFi, Bluetooth, Data, GPS) to minimise battery drain by other factors.
3. Closed all other apps, and did not use the Xoom at all during the tests.
4. Charged Xoom to 100%.
5. Set CPU speed to 1504mhz using SetCPU (both min & max frequencies the same for accurate testing).
6. Unplugged the Xoom.
7. Ran "Stress Test" for 2 hours (give or take 20 seconds).
I performed the above steps for both stock voltage, and undervolted voltage. Results as follows:
1. For stock voltage (1325mV on Tiamit Tachi kernel), battery life went down to 62%.
2. For undervolted voltage (1175mV, which is nice & stable for me), battery life went down to 72%.
Findings:
I was expecting battery savings, but not quite this much.
Standard voltage (at 1504mhz) at this CPU load, drains at about 19% per hour.
UV voltage at this CPU load, drains at about 14% per hour.
Standard voltage at this CPU load, the Xoom would drain battery entirely after about 5.26 hours.
UV voltage at this CPU load, the Xoom would drain battery entirely after about 7.14 hours.
In addition to the battery savings, the Xoom was only slightly warm after the UV tests, but very warm after the standard voltage tests. (Standard voltage test was performed first.)
Note: For general usage (email, browsing, basic apps & widgets), the CPU is not as heavily used. But in situations where the CPU is heavily used (such as intensive games), these results show there is significant potential for battery savings.
super nice tips. Tq very much
126-608 -175
Others -150
This is my settings... no prob at all.
Would I use setcpu app or just use the Moray(in settings) or does it matter
rayhodge02 said:
Would I use setcpu app or just use the Moray(in settings) or does it matter
Click to expand...
Click to collapse
Not sure what the "Moray" is, but any tool capable of undervolting should be ok. I like and use SetCPU, but I've tried other tools on other devices in the past, and they did similar things.
nobody wants to share their result after trying?
Very good job, I try
Sent from my Xoom using xda premium
pls share ur best result
I try your results and they're unstable in function off the useful task, exemple impossible to play simple games.
That's all right just for basic tasks like navigation, music ...
Sent from my Xoom using xda premium
Hmm, your stress testing seems inaccurate.
I used your values and did a stress test at each frequency for around 10 seconds. No problem. But my xoom restarted just 5 mins later while I was surfing the net.
So I increased each frequency by 25-50 and it stayed stable since then.
for me i just underclock my xoom to 912mhz. it is almost as fast as 1ghz. and i save battery alot.
Gregus59 said:
I try your results and they're unstable in function off the useful task, exemple impossible to play simple games.
That's all right just for basic tasks like navigation, music ...
Sent from my Xoom using xda premium
Click to expand...
Click to collapse
Try bumping up the voltages a little bit at a time, until you find a stable setting. The settings I listed are what are stable for my Xoom (even intensive 3D games), but CPUs vary. What I get, others may not, and others may get better than me.
musashiken said:
Hmm, your stress testing seems inaccurate.
I used your values and did a stress test at each frequency for around 10 seconds. No problem. But my xoom restarted just 5 mins later while I was surfing the net.
So I increased each frequency by 25-50 and it stayed stable since then.
Click to expand...
Click to collapse
They're not 100%. The longer you stress test, the more likely the CPU is stable, but 10 seconds gives a general idea. If unstable, just do as you did, and increase by 25mv or so.
omnia1994 said:
126-608 -175
Others -150
This is my settings... no prob at all.
Click to expand...
Click to collapse
Can you confirm your mV values? -175 sounds like a big saving. Surely your mV is not less than the minimum 770?
What kernel are you using?
do some proper tests to establish how much extra time you will get from a fully charged batt.
i would think its perhaps a tiny bit at most...
the screen would take a huge amount of the batt, the processor would use only a small percentage, so surely cutting a small fraction off a couple of steppings is fairly pointless?
baron von bubba said:
do some proper tests to establish how much extra time you will get from a fully charged batt.
i would think its perhaps a tiny bit at most...
the screen would take a huge amount of the batt, the processor would use only a small percentage, so surely cutting a small fraction off a couple of steppings is fairly pointless?
Click to expand...
Click to collapse
1. It depends what you're using the device for. Games, for example, can use a lot of CPU, so undervolting in this instance, will definitely use noticeably less battery.
2. If CPU voltage throughput didn't make any difference, we'd all just run our devices at 1700mhz all the time.
3. With undervolting, I can run my Xoom at the same voltage at 456mhz, as it run at 216mhz. This means I set my minimum frequency to 456 instead, and for the same minimum battery consumption, my device is noticeably smoother.
If you want to know how much extra time you will get from a fully charged battery, YOU do some tests.
lindsaytheflint said:
Can you confirm your mV values? -175 sounds like a big saving. Surely your mV is not less than the minimum 770?
What kernel are you using?
Click to expand...
Click to collapse
Yes i m sure. Has been using these settings till now.. no prob at all. Using tiamat stock gpu kernal with moray rom
i agree that during low intensity operation the power savings are probably nearly negligible, but during CPU-intense usage it could save a bit.
I myself am not willing to leave my Xoom on full bore for a series of tests lasting 7-10 hours each just to quantify how much power undervolting can save under super extraordinary circumstances.
But even if the energy savings is an arguable benefit, the reduction in CPU temperature is not. That alone makes this worth doing, IMO.
Agree.. after setting it my xoom now has lower temp when playing it
Hello, can someone please explain how my battery life improves when I set minimum cpu clock from 200 to 500?
I usually get 3 hours of screen time, with 500 as minimum I get nearly 4 hours. This difference is significant enough to make me wonder and ponder about how this happens.
It's counter logical, something with a higher minimum should drain faster.. right?
Does both cpu states are working at the same voltage? If yes (or the difference is very small) then the battery saving are from the increased execution speed .
In my own opinion, i dont think it affect much, while more than 70%+ battery drain by screen, unless u use cpu 100% all the time, otherwise i wouldnt too much concern abt that
Sent from my GT-N7000 using XDA Premium HD app
Chip efficiency changes with frequency. We tested this on my other phone (an Atrix- nice phone even now!)
Sometimes the CPU is just more power efficient doing tasks at higher frequencies. In a sense, the processor works faster, but for less time- so although it is running faster and requires more battery power, it completes the task much earlier and uses less power in total for that process.
My note, when running at 1.4ghz uses battery so much faster than at 1ghz, but the battery saving when dropping down from 1ghz is minimal, if existent at all.
Welcome to the not-always-intuitive world of modern CPU power usage.
The old mantra "higher frequencies use more power" becomes muddy in situations where the CPU can clock-gate parts of the chip when idle (cpuidle) and where the CPU voltage can change.
It was proven nearly a decade ago that if you don't change voltage at all with clock AND you have a good cpuidle implementation - it is actually best to always clock the CPU at maximum frequency. When voltage changes are in effect - it's harder to tell.
On most devices, the voltage for 500 and 200 are nearly identical. 500 does, I believe, have a somewhat higher bus frequency. So for a given workload, 500 MHz at, say, 20% load will use not much more power than 200 MHz at 50% load. In some cases, a device running at 500 MHz will finish a task more quickly and enter deep sleep faster.
Pretty much - 200 vs. 500 is really questionable in terms of which is best for power consumption. This is why I always set my screen-on minimum to 500.
Any frequency below 200 MHz is pointless as you can't undervolt those frequencies enough compared to 200 to make them have any benefit - in fact in many cases, adding a 100 MHz step is WORSE for battery.
Edit: One thing to note - In Gingerbread, the cpuidle driver was FAR less effective than it is in ICS. Only LPA and IDLE states were enabled by default, and the target residency for both was 40 ms.
In ICS, LPA, AFTR, and IDLE states are enabled and the target residency is 10ms. So it can hit deeper idle states far more often. For example, AFTR isn't as good as LPA - but it's better than dropping all the way to IDLE if you can't enter LPA. This is, in general, why the power consumption when wakelocked is much lower in ICS.
The bad news is that the suspend/resume cycle of the device is longer in ICS, AND cpuidle is totally blocked during suspend/resume - so the suspend/resume cycle eats even more juice than it did before, and it was historically one of the biggest users of power. Eventually I want to try and reduce this consumption.
Thanks for the good explanation mate, it has made things clear for me
Will be keeping my note on minimum of 500MHz aswell as it is a good improvement with no or next to no extra battery drain