5,599,539 Members 40,233 Now Online
XDA Developers Android and Mobile Development Forum
View Poll Results: What has been your experience? (Select two options)
Deep Idle has saved power 174 45.55%
Don't know 122 31.94%
Deep Idle has used more power 27 7.07%
Undervolting has saved power 97 25.39%
Don't Know 137 35.86%
Undervolting has used more power 17 4.45%
Multiple Choice Poll. Voters: 382. You may not vote on this poll

[REF] Battery Drain Benchmarks

Tip us?
 
veagles
Old
#481  
Senior Member
Thanks Meter 393
Posts: 167
Join Date: Nov 2010
Quote:
Originally Posted by steve.garon View Post
The problem is that 1000Mhz is too slow. There are some ICS features that don't work at that speed. Video effects, for example, are choppy at 1000Mhz but work fine at 1100Mhz.
Ok, I have been running at 1000 Hz max for a day, didn't notice any significant lag in routine usage.

Sent from my Nexus S using Tapatalk
 
steve.garon
Old
#482  
steve.garon's Avatar
Senior Member
Thanks Meter 641
Posts: 1,018
Join Date: Apr 2010
Location: Ottawa, On

 
DONATE TO ME
Quote:
Originally Posted by veagles View Post
Ok, I have been running at 1000 Hz max for a day, didn't notice any significant lag in routine usage.

Sent from my Nexus S using Tapatalk
Routine tasks, you'll see no difference. Gpu/cpu intensive task, it might just not work.

Sent from my Nexus S using Tapatalk
Steve Garon on GitHUB

Nexus 4: Unlocked with Stock JB 4.2
Nexus 7: Unlocked with Stock JB 4.2
 
Viper LABs
Old
#483  
Viper LABs's Avatar
Senior Member
Thanks Meter 44
Posts: 134
Join Date: Mar 2011
Steve, is 1100 MHz enough for any GPU/CPU task? Because 100 MHz difference is only 10 %. Is it exactly what Nexus S needs to be a lag free?
 
bedalus
Old
#484  
bedalus's Avatar
Recognized Contributor - OP
Thanks Meter 7757
Posts: 5,956
Join Date: Jun 2011
Location: Chester
There's always going to be compromise somewhere. If you overclock, your system will be able to spit out a few more frames per second, but it will use more battery.

kernels ; battery ; ROM ; gov/sched
Now with summaries in the first posts. Convenient for XDA app users!
For various benchmarks, see my threads: >here<
 
Viper LABs
Old
#485  
Viper LABs's Avatar
Senior Member
Thanks Meter 44
Posts: 134
Join Date: Mar 2011
One more thought about battery drain. If Force GPU rendering option brings any performance benefits (is it??) how much battery juice does it cost?
 
bedalus
Old
#486  
bedalus's Avatar
Recognized Contributor - OP
Thanks Meter 7757
Posts: 5,956
Join Date: Jun 2011
Location: Chester
Quote:
Originally Posted by Viper LABs View Post
One more thought about battery drain. If Force GPU rendering option brings any performance benefits (is it??) how much battery juice does it cost?
No battery cost for doing this. But does it improve gfx?

kernels ; battery ; ROM ; gov/sched
Now with summaries in the first posts. Convenient for XDA app users!
For various benchmarks, see my threads: >here<
 
Viper LABs
Old
#487  
Viper LABs's Avatar
Senior Member
Thanks Meter 44
Posts: 134
Join Date: Mar 2011
Quote:
Originally Posted by bedalus View Post
But does it improve gfx?
Tried both, on and off. Seems like with option switched on scrolling becomes smoother in particular apps like FX File Explorer for ex., but also seems it was more RAM eating too (often launcher reloads). Don't know, hard to tell, currently switched off
 
steve.garon
Old
#488  
steve.garon's Avatar
Senior Member
Thanks Meter 641
Posts: 1,018
Join Date: Apr 2010
Location: Ottawa, On

 
DONATE TO ME
Quote:
Originally Posted by Viper LABs View Post
Steve, is 1100 MHz enough for any GPU/CPU task? Because 100 MHz difference is only 10 %. Is it exactly what Nexus S needs to be a lag free?
Yes. Its not the 10% cpu usage that helps but more the bus at 220Mhz. That is what makes the whole difference...
Steve Garon on GitHUB

Nexus 4: Unlocked with Stock JB 4.2
Nexus 7: Unlocked with Stock JB 4.2
 
bedalus
Old
#489  
bedalus's Avatar
Recognized Contributor - OP
Thanks Meter 7757
Posts: 5,956
Join Date: Jun 2011
Location: Chester
Quote:
Originally Posted by steve.garon View Post
Yes. Its not the 10% cpu usage that helps but more the bus at 220Mhz. That is what makes the whole difference...
Thanks Steve!

I'm on holiday for a week now, so no new results for a few days!
For various benchmarks, see my threads: >here<
 
nathanson666
Old
#490  
Member
Thanks Meter 49
Posts: 80
Join Date: Sep 2011
Default Deep Idle tests

Hello Everyone,

I would like to present some tests that I conducted to see if the deep-idle and screen off max frequency features really do save power when used and exactly how much power is saved.

I measured the power used by the phone during the playback of a song under four conditions: DIDLE off SOMF off, DIDLE off SOMF on, DIDLE on SOMF off, and DIDLE on SOMF on.

The results are shown below. With deep-idle enabled and SOMF enabled the phone used the least amount of power.


The technical details
I have access to equipment that allows recording voltage measurements from multiple channels at 1kHz. So I set up a test circuit that allowed me to measure the power consumed by the phone while it is in use.

To do this I placed the phone in series with a resistor and plugged the whole circuit into a DC power supply set at 4.3V. Also, to see when the songs started playing I took a pair of headphones, cut off one of the speakers, and exposed the wire. I connected these to the headphone jack of the phone. The test circuit is shown here:

I used Air Kernel v3.3 and KANGY 11. I had airplane mode enabled during the tests and WIFI and Bluetooth were off. I used Lazy governor with 100MHz min and 1000MHz max and default voltages. I used the default music player app and played the same song on repeat. The song is called Mr. Sunshine by Laszlo (not that it makes a difference.)

The procedure I followed was:

1. I set up the parameters for the experiment ie. DIDLE and SOMF
2. Shut down the phone
3. Started recording voltage
4. Turned on the phone
5. Waited for the phone to boot and for the screen to timeout automatically.
6. Woke the phone up, set the song to play in a loop, then let the screen timeout automatically.
7. waited for approximately 20 mins.
8. stopped the music
9. set up the parameters for the next experiment.
10. shut the phone down and stopped recording.

After recording the data for the 4 sets of parameters I extracted the data and analysed it. First, I plotted the speaker voltage across time. This allowed me to see when the song started and stopped. I manually marked the points by hand using a set of rules. I did this for every song in each experiment and for every experiment. An example of the data is in the link below. The data looks so dense in the plot because that is for a very long time and there are 1000 data points for every second.

I ignored the first song because it started playing while the screen was still on and I only wanted data from when deep idle could be active. I ignored the last song because it was always cut off and I only wanted to compare complete songs. To find the song start and stop markers I looked at the data much more closely. It's easier to see the actual end and beginning of two songs if we zoom into the data a lot, like in the figure below (in reality I zoomed in even more.)


Then I plotted the power used by the phone. I took the voltage at the power supply and subtracted the voltage at the phone to get the voltage across the resistor. Earlier I measured the resistance of the resistor to be almost exactly 1. I found the current going through the resistor (and consequently the phone because they are in series) using the equation V=I*R. I multiplied the current going through the phone by the voltage across the phone because P=V*I to get the power. An example of the power data is in the link below. Again it's pretty dense but it's just a figure.

An interesting thing to compare is the power plot above to the power plot below. Both plots are for deep idle on but the plot above is for SOMF off and the plot below is for SOMF on. The SOMF on plot has much higher variability in the power usage during the song playback because the phone always jumps from idle to maximum cpu frequency. The SOMF off plot has less variability because the cpu governor ramps up the frequency more slowly. Nevertheless, SOMF on saves more power likely because of the race to idle.


So then I extracted segments from the power data that corresponded to times when a song was playing. I took the average value of those entire segments. (So for each song in every experiment I have one average power value.) Then to compare, I took the average over all songs for each experiment. (So for each experiment I have a single average power value.) The exact results are below:

DIDLE: no SOMF: no 194.5413mW average power
DIDLE: no SOMF: yes 314.7844mW average power
DIDLE: yes SOMF: no 133.747mW average power
DIDLE: yes SOMF: yes 126.4452mW average power

For those who are super keen I zipped up all the data, figures, and scripts used to analyze everything and make the figures here:
http://db.tt/mBSJkT2m
It's all matlab code so if you have matlab you should just be able to run it. It should also work on free matlab clones like gnu octave (but it will be much slower).

I hope this clears things up about deep idle and SOMF. It really seems like both are good things. Ask away if you have any questions!

The Following 44 Users Say Thank You to nathanson666 For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes