Database Users

[TUT] SetCPU and Advanced Settings

I've been using setcpu for a while now, but have never bothered to mess with the advanced settings. Searching around I have only found out what most of this stuff means, but I'm missing some still. I thought I would share my findings. I have included SetCPU's descriptions (in italics) supplemented with my findings.
Governor choices (I'm using king's bfs kernel #1 on fresh 3.1.0.2) -
Ondemand - Uses the highest frequency when tasks are started, decreases step by step
Conservative - Increases frequency step by step, decreases instantly
Interactive - I couldn't figure this one out... any help?
Powersave - Uses the lowest possible clock speed to complete its tasks
Userspace - Manual controll of the frequency
Performance - Always uses the highest clock speed
Advanced Settings -
Sampling Rate - An interval (in microseconds) at which the governor will poll for updates. When this happens, the governor will decide whether to scale the CPU up or down. It uses such little power that it is better at lower values when using profiles such as screen off.
Up Threshold (1%-100%) - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU up. When using low min values (245), this happens instantly, using higher values (768) it overclocks less often. With Conservative lower values are better because it slowly increases your clock speed to what you need, with Ondemand, higher is better, as it overclocks less often.
Down Threshold (1%-100%) (conservative only) - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU down. Higher values will offer more aggressive battery saving, lowering the clock speed quicker.
Ignore Nice Load (0/1) - If this value is "1," the system will ignore "Nice" processes when deciding to scale up or down. I need a little more info for this one, what exactly is a nice process? DO NOT GOOGLE 'NICE LOAD' ESPECIALLY AT WORK OR AROUND CHILDREN/WIFE
Freq Step (0%-100%) (conservative only) - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold. Increased the value slightly to be able to overclock quicker, but not to high to avoid unnecessary overclocking.
Powersave Bias (0-1000) (ondemand only) - Setting this value higher will "bias" the governor toward lower frequencies. This is a percentage, where 1000 is 100%, 100 is 10%, and 0 is 0%. The ondemand governor will scale the CPU to a frequency lower than its "target" speed according to this value. Gives ondemand some more battery saving potential. High values give worse performance than conservative with equal or worse battery saving. If you want the performance of ondemand with some more battery use values under 200.
I hope this info was helpful to someone, and here are my setcpu settings. I have attempted to target 150-175ms for short and 350-400ms for long benchmarks to match my performance governor and save battery at the same time.
With ondemand I get about 170ms short and 380ms long. I use 90 for up and 50 for powersave. The performance is slightly better than the default settings, and the battery is about equal. I might play with this more, as it should hit the same values as performance with better battery life.
In conservative long benchmarks in setcpu are actually faster than short ones because it takes setcpu time to adjust the speed. Run a short one immediately after a long one to see its actual value. Up changed 75 and down to 25, not much of a change, but drastic performance increase with no battery change. I also increased freq step to 10% to obtain higher speeds faster. Getting the same 170ms short and 370ms long.
My Settings
Conservative 245-1190
Temp > 50C - 768 conservative
Screen Off - 499 ondemand (allows for the screen to be unlocked faster, especially useful with incoming calls)
Charging/Full - 1190 performance
Battery < 15% - 652 conservative
Sampling - 200000
Up Thresh - 75
Down Thresh -25
Ignore Nice - 0
Freq - 10
More DFS Info
SetCPU Info

davebu said:
DO NOT GOOGLE 'NICE LOAD' ESPECIALLY AT WORK OR AROUND CHILDREN/WIFE
Click to expand...
Click to collapse
LMAO 10chars

HondaCop said:
LMAO 10chars
Click to expand...
Click to collapse
Yeah. I almost spit out my Vanilla Coke on that one. LOL

Anytime have any info about nice load or anything to add?
Sent from my HTC EVO 4G.

HondaCop said:
LMAO 10chars
Click to expand...
Click to collapse
I missed this yesterday... Post of the day in my opinion

Thanks dave...good write up

This is what I found about the interactive governor in github:
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Also, in the original application thread as explained by the dev, "nice" processes are:
2. Nice processes are used by the IO scheduler to designate a low-priority process. Ignore nice load basically tells ondemand to disregard processes with higher nice values.

Good topic. You covered the bases pretty well. Glad someone finally put this together as it is useful to know. Now prepare for 1000 threads in the next month asking for the information you just posted.

hey question. i went and purchased SetCPU and attempted to follow your instruction. problem is, whenever SetCPU tries to gain super user permission, it says "no root access granted. Are applications allowed root access?" i dunno what to do. can someone advise me?

Umm, is your phone rooted?
Sent from the void...

Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk

SilverStone641 said:
Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk
Click to expand...
Click to collapse
Try uninstalling and reinstalling it.
Then double check all of your superuser settings.

SilverStone641 said:
Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk
Click to expand...
Click to collapse
Sorry, using the xda app which doesn't display the sig.
Sent from the void...

So, as far as speed/responsiveness of governors goes:
Fastest ------------------------------------------------------> Slowest
Performance ------> ondemand ------> Interactive? ------> Conservative
Poor battery consumption --------------------> Best battery consumption

This thread is exactly what i was looking for, thanks for the detailed explanation of the what and why.
Will try it out this week with Fresh 3.1 and KK#8.

this thread helped a lot, i was just in setCPU messing around with things, now i can use this thread to help get what i want. i bookmark'd the hell out of this thread

Thanks...OP...hopefully people will read it first...try things..then ask questions...
I am still working to see how to get the best battery life from cm6 and snap..

Thanks for the helpful post!

I experienced a "nice load" when I unboxed my EVO. Anyway the only setting I use is:
Screen off: 245/128 on demand.
Works for me. And thanks for this helpful post to help us understand all that technical mumbo jumbo.

So I got a rooted Vanilla install of the latest Sprint OTA Froyo build on my EVO. (the 3.29.651.5 build).
I purchased the latest version of SetCPU (2.03) last night and used the autodetect method for the CPU governor.
I notice on my EVO that I only have these 3 options:
Scaling:
ondemand, userspace and performance....
Is this normal to not have the conservative setting since I have the defacto kernel with a vanilla rom?
Thanks
Sheldon
Okay, so I figured it out, my default kernel does not have these other options, oh well......
Nice app though, so far its working really well.

Does cpu frequency affects battery life?

The question is simple, the higer the freq. the more battery consumption? i am asking because i cannot see any difference from 1.4GHZ to 1.0GHZ, the battery consumption is the same under oxygen and francos kernels. i would be grateful if the experts would give us some advise or their opionion. I know it is subjective but i would like a second opinion.
Thanks alot guys

If you look with any cpu spy app, you cab see on what clock the processor is used. I mainly have it the lowest and sometimes higher. When you change the max, it should still automatically choose what clock is used, so battery should last as much as before, if not used in high clock.
Sent from my Huawei u8800 using XDA App

Invicta said:
The question is simple, the higer the freq. the more battery consumption? i am asking because i cannot see any difference from 1.4GHZ to 1.0GHZ, the battery consumption is the same under oxygen and francos kernels. i would be grateful if the experts would give us some advise or their opionion. I know it is subjective but i would like a second opinion.
Thanks alot guys
Click to expand...
Click to collapse
Probably not much difference, when you overclock, think the cpu voltage remains the same as it is on 800mhz... And the highest cpu freq is rarely even at use...

Invicta said:
The question is simple, the higer the freq. the more battery consumption? i am asking because i cannot see any difference from 1.4GHZ to 1.0GHZ, the battery consumption is the same under oxygen and francos kernels. i would be grateful if the experts would give us some advise or their opionion. I know it is subjective but i would like a second opinion.
Thanks alot guys
Click to expand...
Click to collapse
Well, thanks to most devoted users of U8800, we have somewhat better speed+battery life than stock also. To answer your question, yes depending on your activity the frequency have some impact, but overall shouldn't be huge in change, for example from .800 to 1.0GHz will not affect so much in daily use. However from .800 to 1.5GHz would make a somewhat huge gap difference. This doesn't mean it will drain faster if you do same activity as with .800 to 1.0GHz, for example check the watch, answer sms or few "entertainment" breaks. Only when using the phone over a longer period of time that's when you will notice the change of battery life with different frequency. Hope it clears up most hums and huhs for you. I am pretty sure some expert within this field will give a better explanation than me.
Bye~

higher freqs uses more energy, but lower uses less energy but do things slower (so energy consumption is longer). ALSO imo - if you set cpu to 1Ghz the lowest value so it always is 1ghz - it will not consume the same amount of energy if it's in idle mode - it's like your laptop - if cpu is working only in 4-7% of it's power - then the power consumption is lower no matter what freq - how do we know that? - because of heat - the more heat you get - the more energy was used. and when cpu is idle - it will not be hot.
So the answer is - if it saves then in VERY minimal amounts. But even so - i use min freq - 360mhz. it's good for me i do not get any lag so i use it.

I use the "Root System Tool Free", option CPU and I see the graphics of all clocks.
For ex. now at 245 mhz ->46%, at 368 ->10%, at 768 mhz ->18% .... and at 1612 mhz -> 1,8%, at 1804 mhz ->4,9%. Not very mutch use at 1804.
Oxygen-test-140911 + Franco.Kernel1709#1. Clock at 1804 Mhz by Menu-settings-cpu ... and smartassV2 (no profils).
The battery, I charge it all 24 hours. But I like my work... and testing things. When then will dead...I see...

ValenteL said:
I use the "Root System Tool Free", option CPU and I see the graphics of all clocks.
For ex. now at 245 mhz ->46%, at 368 ->10%, at 768 mhz ->18% .... and at 1612 mhz -> 1,8%, at 1804 mhz ->4,9%. Not very mutch use at 1804.
Oxygen-test-140911 + Franco.Kernel1709#1. Clock at 1804 Mhz by Menu-settings-cpu ... and smartassV2 (no profils).
The battery, I charge it all 24 hours. But I like my work... and testing things. When then will dead...I see...
Click to expand...
Click to collapse
cpu spy is more pretty, anyway all those apps just reads text file of cpu stat and that's it

Tommixoft said:
cpu spy is more pretty, anyway all those apps just reads text file of cpu stat and that's it
Click to expand...
Click to collapse
Thanks
But I like more the Root System Tool, because has also a Linux Console. I use it when I want make some cmd's Linux in #. I don't like the Terminal Emulator.

Well, there is a "catch" somewhere in there. The frequency does indeed affects the power consumption of the CPU and greatly at that too! But the thing is, your CPU is not the worst enemy of your battery life. Even though CPU consumes more power in higher frequencies, it still can not compete with what your screen LEDs or your GSM module or your GPS chip consumes leisurely. So, if you're looking at the overall picture -meaning if you're wondering if it will affect how long you'll be able to use your battery in your phone- the answer is, "yes but not so much". Especially if you're switching the CPU frequency based on the demand (like using smartass or on-demand governors)
Here are the thing that sucks your batteries life juice like a vampire :
Your Screen (especially background LEDs)
GSM module (talking, using GPRS/Edge/3G network communication)
GPS chip
Wireless module (this also includes Bluetooth, even though it does not consume as much as Wireless network access but everything is relative -think about playing music through A2DP headphones compared to having your wireless network active but not using it much-)
(oh yes, I love to use lots of parenthesis -and even this hyphenation thingy- )
Correct me if I'm wrong about anything by the way ..
Regards ..

I did some experiments with a msm8250 a while back and there's a graph here:
http://forum.xda-developers.com/showpost.php?p=14324649&postcount=3786
msm7x30 should be fairly similar though the graph is probably shallower since it's a smaller process size.
The CPU uses no power when it's not in use, even with the display on, the CPU is powered down completely when idle (power collapse).

Undervolting a Xoom - battery results included

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

[REF] Best Governor And I/O Scheduler Studies + Battery Saving Tips

Ok it's been so long and for the love of God! I still see a lot of users posting about how horrible their battery lives are. So, here are a couple of guides that I found. I'm copy pasting them here because (1) I find them very informative and (2) I can agree with the information provided from my experience. And hopefully you find it helpful too.
Please follow the original thread and thank bedalus for all his time and effort!
Governor And I/O Scheduler Studies
Direct Copy Paste---I TAKE NO CREDIT---Original Thread Here:http://forum.xda-developers.com/showthread.php?t=1470247
bedalus said:
Spreadsheets for CPU Governors and I/O Schedulers
GOVERNOR RESULTS
I/O SCHEDULERS
Summary of the Results
This is a summary of the six most commonly used governors, listed in order of performance.
Best Performing
#1 - Performance
--- : Use Noop or Deadline
--- : Uses a lot more battery
#2 - SmartassV2
--- : Use Noop or SIO
--- : Uses a little more battery
#3 - LulzactiveV2
--- : Use Deadline or Noop
--- : Uses a lot more battery
#4 - Lazy
--- : Use Deadline or CFQ
--- : Helps save battery as long as SOMF is not enabled
#5 - Ondemand
--- : Use Noop or Deadline
--- : Helps save battery
#6 - Conservative
--- : Use CFQ or Noop
--- : Helps save battery
Check my summary in this thread for more info about how to save battery.
Thanks to all the developers.
Caveats
The most important thing to remember is that the testing hardware is a nexus s. Although I believe they are essentially the same device, there may be differences in how the galaxy s hardware affects performance. Do some experimenting yourself, and if it feels right, go with it!
Click to expand...
Click to collapse
--------------------------------------
Battery Saving Tips
Direct Copy Paste --- I TAKE NO CREDIT --- Original Thread Here: http://forum.xda-developers.com/showthread.php?p=22126792#post22126792
bedalus said:
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!
Click to expand...
Click to collapse

here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle

xtone said:
here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle
Click to expand...
Click to collapse
OMG
Can you please share What kernel are you using and what are your settings buddy ??

amritpal2489 said:
OMG
Can you please share What kernel are you using and what are your settings buddy ??
Click to expand...
Click to collapse
I think you're getting your hopes up. Something tells me the radio isn't in use the whole time, extended battery might come into play, or a total of an hour's worth of screen on time. The vibrant has battery drain problems with normal use with aosp ROMs, nothing is gonna change that.
Sent from my Nexus S using xda app-developers app

xtone said:
here's a screen shot of my battery life in standby.
set up:
Governor and Scheduler: Ondemand/Noop
CPU Frequency: 200-1000
No OC/UV
No Didle
Click to expand...
Click to collapse
Dude! My phone on for 1d18h says 13% battery and i don't even use wireless or bluetooth.

amritpal2489 said:
OMG
Can you please share What kernel are you using and what are your settings buddy ??
Click to expand...
Click to collapse
He has not been using his phone see his screen drained only 5% battery. all phones will gives similar results if you just keep phone on table.

[Q] CPU Explanation

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