FroYo Battery Usage Testing
- Thread starter Bouncer5
- Start date
Disabled auto-brightness since i had the phone, never liked it..
I installed juicedefender again and its a little better, now idle is around 5 mA and screen on 120/130
Idle at 5mA vs 7mA could make sense, because juice defender turns the wifi/3G data off when phone is idle. This however can save you (supposedly) 2mAh if the phone is mostly on idle, which translate for a full day of idle (unrealistically) to 48mAh, which in turn is 48/1400 = 3.4% battery. Even if you would want this gain, I think that while testing I noticed that switching WiFi/3G data on and off includes an overhead for just switching that compensates for that small gain. Maybe if you keep your phone on idle most of the time and don't want to be bothered in turning data on/off manually, you could see some gain. Otherwise you would probably be better to get to the source of the frequent data connection that causes you trouble.
About the value on screen on, I would think juicedefender hasn't got much to do with it...
I can write some brisk details now if you're sincerely curious but a) contrary to the masses and geeks, I dislike much talk/writ nor am I good at it b) I'm heavily time/attention constrained right now being on the move adjacently. I'll list some basic information:
1. The HTC Desire has more than 5 separate hardware components within it consuming power. Here's a typical dissection of a smartphone; note how many power consuming chips there are additional to the screen: http://www.chipworks.com/nexusone.aspx
The above isn't detailed enough for you to really see how many various ICs are working to make a smartphone. They did a full analysis with an iPhone 4 though so you can see better at the sheer number and size of chips running a smartphone: http://www.chipworks.com/iPhone-4-teardown.aspx
2. Back to the Desire which is very similar to the above in make-up and complexity. Of all of these hardware components, the Samsung OLED screen has the highest, screen-on, average power draw on the Desire (~70-95% of the total device).
3. The Qualcomm Snapdragon QSD8250 chipset (SoC) built on 65nm fabrication, ~60mm^2 die, is also one of these hardware components on this device. Just one.
4. This chipset also has many components to it: http://encoreppc.files.wordpress.com/2009/03/snapdragon.jpg
The Scorpion ARMv7 [edited mistake] based custom Core (application processor i.e. CPU) is only one of them at ~8.9mm^2, shown at the top center left in the above image. The Core itself is tiny, a block diagram of which is as follows: http://i.cmpnet.com/dspdesignline/2007/12/bdtifigure1.gif
Less than 1/6 of the chipset logic. Without cache that is even smaller, below 4mm^2. So the Core region is only one small part of the complete chipset and even smaller part of the whole device in terms of size and power.
5. The frequency change you make using any application only affects this Core portion of the whole chipset and device, and nothing else. Straight away you might conspicuously notice that the maximum gain by tweaking just the Core will be very little compared to what the full device uses of power.
i. DVFS - dynamic voltage frequency scaling - is used to control and maximize power efficiency of this Scorpion Core by default. For each frequency band, there will be an undisclosed voltage set that initiates at the same time. The two work together. DVFS sets frequency/voltage states according to Core load. Voltage (Vdd) is the biggest power enemy and determinant of the Core. It is currently unknown but extremely unlikely that manually forcing a medium-high Core load state to a lower frequency will influence the voltage associated with that Core load. The voltage most likely will stay high as programmed by default, and so the power saved by just dropping the frequency 200-500MHz will be negligible if any. Immeasurable. Capacitance, temperature and voltage^2 are the biggest parameters determining SLP chip power, neither of which you are controlling. Specifically supply voltage is the key, which sub-threshold, reverse bias junction, gate and gate induced drain leakage are very sensitive to. You can find more details on these here:
http://www.synopsys.com/Community/UniversityProgram/CapsuleModule/SoCPowerManagement.pdf
http://venus.ece.ndsu.nodak.edu/~cris/ece470/papers/u_ARM.pdf
ii. I've logged the CPU section power draw and load according to various usages cross-checked between apps like Show CPU usage, Power Tutor, OS Monitor and System intensively. I encourage you to do so too. In PT, you can read the full breakdown in its logging feature as well as frequency at each second and what exactly is using the CPU. In my tests on various ROMs it portrays very clearly that the Core is at 245MHz when you expect it to be in idle, and even under low loads upto around 20-25%. Hence I am not sure what you can even theoretically achieve by setting the same frequency manually ?
iii. If your CPU is indeed idle as it should be when you expect it to be, forcing to the low clocks won't help power draw as by default, the Scorpion Core would already be at the lowest frequency/voltage (hence power) band on its own, as explained above. If you want me to explain DVFS workings, just ask.
iv. If however your CPU is not idle as it should be when you expect it to be, and the clocks are fluctuating heavily... then you have another problem elsewhere. Forcing to low clocks will help cut power draw very minimally but it won't resolve the problem causing the fluctuations in the first place and the associated large power increase by voltage/current ramping. In system idle, this is not the normal intended functioning nor behavior (>360MHz).
v. If your CPU is under a consistent medium to heavy load and you wish to save energy, then setting to low clocks will reduce power draw but by a very negligible (sub-0.00xW) when you cannot adjust the various voltages. On the other hand, it will always drastically lower performance.
vi. If your screen is off, and lockscreen enabled, setting any frequency will not have any advantage as the CPU clocks are already shut-off in that state - SRPG mode i.e. clock gated. The CPU clock generation and PLL circuitry in this state has 0 power use already. You can see more details on these workings here:
http://cache.freescale.com/files/dsp/doc/app_note/AN4051.pdf
vii. Hence forcing to lower clocks will not help battery life except in very few, specific, circumstances, and even then, at very small amounts, and, it also implicitly lowers overall performance.
6. No matter what you can do to the Core section in terms of frequency;
i. You won't gain anything more than negligible battery life in best case, high load scenarios (screen on consumes +70%). See for instance thse two research studies:
http://www.usenix.org/events/atc10/tech/full_papers/Carroll.pdf
http://www.cs.ucsb.edu/~xun/papers/reuse-igcc10.pdf
ii. The Snapdragon chipset is very low power to begin with (approx 0.350W loaded, 0.0014W standby) and the frequency you are changing is only of a small component within it - of the Scorpion Core. Other components on this chipset have higher power requirements. Even if you lower the Core frequency, you will not change the vast amount of Core power as there are more than 10 voltage rails on this CPU being powered. The vast majority of static and dynamic Core power is consumed by Core Vcc, Vddgp, Vdda, IO and PLLs on independent voltage planes. There is at minimum a STOP mode for the Core in standby, the LFM (low frequency mode) at ~0.85-0.95v and a HFM (high frequency mode) at ~1.10-1.25v. In standby, the isolated Core power is approx 0.0003W.
7. The maximum mWs you might gain if you keep the CPU in a medium to heavy loaded state forced to the lowest frequency over a full discharge can easily be outdone by 10-20 minutes of screen-off.
8. Any hardware polling and tweaking application (like SetCPU) will itself increase CPU-sys and CPU-usr load, hence increase system power draw.
-----------------------------------
- Sent via my HTC Desire -
Last edited:
Who said snake oil? http://androidforums.com/690345-post9360.html
-----------------------------------
- Sent via my HTC Desire -
http://androidforums.com/690345-post9360.html-----------------------------------
- Sent via my HTC Desire -
Beside being my hero for writing all that stuff from your phone and proving concepts so thoroughly...
The big question is: what keyboard are you using? Hehe
Seriously, thanks a million for the huge explanation
Sent from videotext, using the remote
The big question is: what keyboard are you using? Hehe
Seriously, thanks a million for the huge explanation
Sent from videotext, using the remote
Thanks th3 for providing all that.
Not sure about the screen, it's always seemed to me that 3G is the biggest power drain on a smartphone. I always found a lot of variation between WM6 roms on my Blackstone in this respect - some would be able to shift data more economically. Of course this is hard to test rigourously, you have to be in the same location, ideally at the same time to do a proper test, and their is a lot of cognitive bias involved. But still I got the impression that some roms used less power for data than others. I haven't flashed enough on the Desire to have an opinion about this yet. The fact will always be though that the battery on this device is a bit underspecified and the only real fix will be to carry a spare or get a bigger one. You can optimize the software to avoid unnecessary drain, but even properly configured, it can only handle a few hours of heavy use.
Not sure about the screen, it's always seemed to me that 3G is the biggest power drain on a smartphone. I always found a lot of variation between WM6 roms on my Blackstone in this respect - some would be able to shift data more economically. Of course this is hard to test rigourously, you have to be in the same location, ideally at the same time to do a proper test, and their is a lot of cognitive bias involved. But still I got the impression that some roms used less power for data than others. I haven't flashed enough on the Desire to have an opinion about this yet. The fact will always be though that the battery on this device is a bit underspecified and the only real fix will be to carry a spare or get a bigger one. You can optimize the software to avoid unnecessary drain, but even properly configured, it can only handle a few hours of heavy use.
I find the battery to be adequate, still I do have a spare and I did have a spare with my touch HD. But if I tried to do on the Blackstone what I am doing on the desire, the battery would have probably lasted half the current duration.
Regarding roms, I used to think that on the Blackstone too, until one day I took batlog and tried to prove it. Since then I only used the rom I liked most visually...
Sent from videotext, using the remote
Regarding roms, I used to think that on the Blackstone too, until one day I took batlog and tried to prove it. Since then I only used the rom I liked most visually...
Sent from videotext, using the remote
Alright remember those doubts about my spotty wifi influencing the tests ?
I have an Atlantis wifi modem router that I always used as standard. It was cheap but I assumed the three antennas would make the connection a bit more reliable, if not stronger.
Today I linked my old linksys to it and disabled wifi on the Atlantis, routing everything wireless through the linksys. Besides the fact that I seem to have consistent stronger signals (5-10 dBm difference) these are the results of streaming music alternating data connection (in mA, reported by current widget every minute):
wifi 236 - 239 - 234
3G 296 - 298 - 303
wifi 222 - 216 - 202
3G 302 - 301 - 299
wifi 231 - stopped here, as it's obvious
So, yes, as it is usually supposed, wifi drains less than 3G data connections, but that can be easily flipped if you have a spotty/bad wifi connection as I had...
I have an Atlantis wifi modem router that I always used as standard. It was cheap but I assumed the three antennas would make the connection a bit more reliable, if not stronger.
Today I linked my old linksys to it and disabled wifi on the Atlantis, routing everything wireless through the linksys. Besides the fact that I seem to have consistent stronger signals (5-10 dBm difference) these are the results of streaming music alternating data connection (in mA, reported by current widget every minute):
wifi 236 - 239 - 234
3G 296 - 298 - 303
wifi 222 - 216 - 202
3G 302 - 301 - 299
wifi 231 - stopped here, as it's obvious
So, yes, as it is usually supposed, wifi drains less than 3G data connections, but that can be easily flipped if you have a spotty/bad wifi connection as I had...
[PEDANT MODE]
I hate to be picky on what is otherwise a most excellent post, but the Scorpion is *not* based on the ARM Cortex. It implements the same instruction set as the Cortex, and shares many of the same features, but it is a completely custom design.
See here for more details.
The point is that unlike Samsung, with their Hummingbird processor, Qualcomm didn't take a Cortex-A8 core and drop it into their SoC, they designed the entire processing core themselves.
[/PEDANT MODE]
I'll get me coat!
Regards,
Dave
[PEDANT MODE]
I hate to be picky on what is otherwise a most excellent post, but the Scorpion is *not* based on the ARM Cortex. It implements the same instruction set as the Cortex, and shares many of the same features, but it is a completely custom design.
See here for more details.
The point is that unlike Samsung, with their Hummingbird processor, Qualcomm didn't take a Cortex-A8 core and drop it into their SoC, they designed the entire processing core themselves.
[/PEDANT MODE]
I'll get me coat!
Regards,
Dave
(loads trebuchet with tomatoes)
The end of the story, for both posts, is that the Scorpion base of the Snapdragon is a hell of chip design-wise and that even as optimization for battery goes, we can be very happy with it. Right ? Just trying to summarize for those that didn't read the whole story.
I have a small doubt regarding EVO/snapdragon vs GS/hummingbird:
(I get my coat now, since I probably remember all this stuff very dimly)
the hummingbird dedicated GPU moves data at only 8kbits (much like very old cpu's ???) and that means between the cpu and gpu right ?
I am assuming memory has to pass through the cpu like in the old days of pc's ? or the gpu has its data pipe to the ram ? Or -very probably- I don't understand what's going on and I actually can't even remember how a computer works ? Is the mobile design very different from old pc's in order to save power and space ?
andycted: The app WiFi Keyboard
Only kidding. I use a well tweaked HTC_IME basically. The calibration or whatever that gets it working so well with my hands just works and usually I type some, save it in Springpad, and then might continue every time I get a chance in the day over 2-3 days, as was the case here. Productivity is awesome when you have apps like SendtoComputer, ChrometoPhone, FoxtoPhone and Springpad at your disposal.
As to these super-low-power RISC Cores; they work similar to x86 super-high-performance PC Cores internally after you reach the macro-op decode and micro-op execution stage but there are gross lengthy differences within the rest of the functional details. I haven't seen a pipeline daigram of any ARMv7 implementation to see what they're currently doing.
patp: You know during the course of this thread, and taking two research studies as well as another Google funded and supported study, we established when the Desire is sub-30% CPU load [edited to correct] to idle, plus 75% of the device power draw is solely attributed to the OLED display. This is corroborated by independent empirical measurements. That percentage increases as you increase brightness and change the displayed image on-screen. Now, making calls and data networks also have a relatively high power usage, but, they are momentary and on-demand only. WiFi/3G data only consumes much power when data is being transferred. 2G-3G cell only consumes much power when network search/registration/wait/fix is initiatied. The screens high power is always there no matter what you do as long as you have the screen on.
foxmeister: Perfectly right, and well corrected. It was a reckless mistake when scrolling up/down editing last minute. I'm well aware the Scorpion Core was based off the ARM licensed architecture and developed top to bottom in-house, even the power and pipeline characteristsics are different, but that just totally slipped my mind while editing the lines in, even though I had the same article you linked open while typing and it was on my mind when initially typing "custom" in there. Two other fast-typing errors I didn't correct I see now. They will be corrected.
OT, but I don't think Inside DSPs internal Scorpion details are all correct. Scorpion was supposed to have a lengthier pipeline for higher clocks than Cortex-A8 yet the details they gave are mostly for the Cortex-A8. See: http://www.iee-cambridge.org.uk/arc/seminar05/slides/RichardGrisenthwaite.pdf
Only kidding. I use a well tweaked HTC_IME basically. The calibration or whatever that gets it working so well with my hands just works and usually I type some, save it in Springpad, and then might continue every time I get a chance in the day over 2-3 days, as was the case here. Productivity is awesome when you have apps like SendtoComputer, ChrometoPhone, FoxtoPhone and Springpad at your disposal.
As to these super-low-power RISC Cores; they work similar to x86 super-high-performance PC Cores internally after you reach the macro-op decode and micro-op execution stage but there are gross lengthy differences within the rest of the functional details. I haven't seen a pipeline daigram of any ARMv7 implementation to see what they're currently doing.
patp: You know during the course of this thread, and taking two research studies as well as another Google funded and supported study, we established when the Desire is sub-30% CPU load [edited to correct] to idle, plus 75% of the device power draw is solely attributed to the OLED display. This is corroborated by independent empirical measurements. That percentage increases as you increase brightness and change the displayed image on-screen. Now, making calls and data networks also have a relatively high power usage, but, they are momentary and on-demand only. WiFi/3G data only consumes much power when data is being transferred. 2G-3G cell only consumes much power when network search/registration/wait/fix is initiatied. The screens high power is always there no matter what you do as long as you have the screen on.
foxmeister: Perfectly right, and well corrected. It was a reckless mistake when scrolling up/down editing last minute. I'm well aware the Scorpion Core was based off the ARM licensed architecture and developed top to bottom in-house, even the power and pipeline characteristsics are different, but that just totally slipped my mind while editing the lines in, even though I had the same article you linked open while typing and it was on my mind when initially typing "custom" in there. Two other fast-typing errors I didn't correct I see now. They will be corrected.
OT, but I don't think Inside DSPs internal Scorpion details are all correct. Scorpion was supposed to have a lengthier pipeline for higher clocks than Cortex-A8 yet the details they gave are mostly for the Cortex-A8. See: http://www.iee-cambridge.org.uk/arc/seminar05/slides/RichardGrisenthwaite.pdf
Last edited:
I was using htc_mod until I could put my hands on swype again. But I think I've found a better promising keyboard in ultrakeyboard.
Anyway, thanks for the explanation. When you say "the Desire is sub 30% load to idle", you mean is in the lower 30% of devices for idle power consumption ?
Anyway, thanks for the explanation. When you say "the Desire is sub 30% load to idle", you mean is in the lower 30% of devices for idle power consumption ?
patp: If you use this latest driver patch which lets you change voltages along with SetCPU clocks... that stands a very good chance of improving battery life: http://xdaforums.com/showthread.php?t=775997
TBVH, from all of my reading of threads and testing those same feedbacks, there seems to be large variance in certain apps/settings/features and functionality with each ROM. At least this is certainly my experience. To date, I haven't moved to one ROM except HTC 2.1->2.2 where the UI, keyboards, touchscreen, memory management, email, toggle widgets, flash, browser, stability, application/feature usability, [etc] were the same. It's for this reason that on OpenDesire, when writing at any length, I use BetterKeyboard or Swype simply because of their workings with it. On any HTC ROM though, I use my tweaked HTC_IME for the same reasons as well as it being my preferred choice. The touch responsiveness on HTC ROMs with this keyboard, along with the key size and spacing adjustements works excellent for me.
Good catch, thanks. It should've read "sub-30% CPU load" instead. Corrected.
Hey guys, I just sort of confirmed th3's theory for myself... the theory that SetCPU sucks down battery life - uninstalled before going to bed yesterday, and this morning I had lost only 3% of my battery life, as opposed to the usual ~10%.
I figured I wasn't affected because I only ever use SetCPU when I actually need a performance boost (hasn't really happened yet, so I just kept it installed and never actually used it). It wasn't set to run on boot, and hasn't been opened for weeks (with bunches of reboots and ROM flashes in between, etc.).
And still it apparently sucked down a bunch of power - apparently it polls in the background even if it's not set to actually run or do anything at all...
I figured I wasn't affected because I only ever use SetCPU when I actually need a performance boost (hasn't really happened yet, so I just kept it installed and never actually used it). It wasn't set to run on boot, and hasn't been opened for weeks (with bunches of reboots and ROM flashes in between, etc.).
And still it apparently sucked down a bunch of power - apparently it polls in the background even if it's not set to actually run or do anything at all...
The first time I'm able to see current discharge on the stock HTC 2.2 ROM and: http://bit.ly/afa78z
It has lower idle discharge by some margin, (-90mA min, -99mA max) with button LEDs on as usual. Same setup on a few versions of OD for instance never falls below -118mA, and -124 to 130mA with OSMonitor running as above.
-----------------------------------
- Sent via my HTC Desire -
It has lower idle discharge by some margin, (-90mA min, -99mA max) with button LEDs on as usual. Same setup on a few versions of OD for instance never falls below -118mA, and -124 to 130mA with OSMonitor running as above.
-----------------------------------
- Sent via my HTC Desire -
Similar threads
