Spreadsheet of Governor Power Use
BENCHMARK DATA
Summary
Out of the five most popular governors (ondemand, conservative, smartassV2, lazy, and lulzactiveV2) which one can save the most battery?
Total power use is calculated from the mA drain at the frequency x the %age of time spent at that frequency. mA drain figures available here.
Best Power Saving Governors
Best for Screen ON: Ondemand
Best Screen ON + performance: SmartassV2
- Good choice if you need a performance governor with some power saving
- SmartassV2 is also the winner of the governor benchmark: here.
What about when my Screen is OFF?
Best Governor for Screen OFF
Without Deep Idle: Same as Screen ON > Ondemand
With Deep Idle: Any governor...
...now it get's technical...
...Why 'any'? If you look at the spreadsheet, on average, with music ON and the screen OFF, the difference between the best (smartassV2) and worst drain (lazy) is 0.05mA (a tiny amount). Harrb already did a 10 hour test to establish how much each governor drains the battery while using deep idle:
Harbb's spreadsheet
Here's two of Harbb's results (phone's own stats for battery drain with matr1x):
- 23% - Lazy with DI
- 15% - SmartassV2 with DI (35% more efficient)
And my results (mA drain using matr1x):
- 0.30mA - Lazy with DI
- 0.24mA - SmartassV2 with DI (20% more efficient)
Harbb's result is the most reliable, as my original battery drain mA readings were all somewhat approximated due to the difficulties of reading accurately off a small scale on the analogue amp meter, especially when the scale is logarithmic and the mA drain is in the lower register. This means, if I assume my Smartass mA reading is correct, then my Lazy reading should be 0.405mA
While playing music, with the screen off, with DI enabled,
over a period of 1 hour:
a constant drain of 0.240mA = 864mA
a constant drain of 0.405mA = 1458mA
So choosing SmartassV2 over Lazy would prevent about 600mA being wasted in one hour. To put this in context, that is enough to power your screen for 3 seconds (assuming a drain of 200mA).
Since it will take about 3 seconds to change your governor, in practice, it would be a waste of effort to bother. Pick your preferred governor for screen ON, and don't worry about what happens while the screen is off (again, only if you have deep idle. If you don't, but want some power savings with the screen off, choose ondemand).
F.A.Q.
[Q] But Harbb's data clearly shows that the battery drain is much better under smartassV2. How can you say governor choice doesn't make a difference?
[A] Harbb's result is an 8% benefit over ten hours, so in one hour it's a 0.8% benefit. It's not a very practical amount.
For more battery saving tips, see my battery drain thread: here.
Where did the other benchmarks go?
Battery Drain Benchmarks: this thread
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
These tests were based on an the procedure first used by XDA user glennkaonang. Credit and thanks to Glenn. Thanks to r_data, mathkid95, steve.garon, and eugene373 for their kernels.
Conservative is not the Best
When the screen is ON, i.e. the phone is in active use. Generally Conservative does not save power. This is because most developers have included a tweaked version of conservative that keeps the frequency at its highest state for longer to improve the responsiveness.
There is one exception where conservative saves more power than other governors, and that is when the screen is off, music is on, deep idle is on, and this only applies specifically to Air Kernel. However, we are talking about a tiny amount of power (for more detail, see the first post.)
PLEASE NOTE: Steve Garon does not include deep idle, but is working on it, neither does Eugene, but I've asked him to consider it. For these two kernels, if you are listening to music with the screen off, currently, the best power saving governor is Ondemand.
Governor Parameters per Kernel
SG-NS-ICS (11th FEB TEST VERSION)
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 3 @400
Up sample time: 20000
Down sample time: 40000
MAT1X v17.0
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 768000
Sleep ideal freq: 245000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
ICUP SPEEDY-7
-Conservative
Sampling Rate: 39062
Up Threshold: 70
Down Threshold: 30
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 30000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2 (not settable in NSTools, checked /sys/devices/system/cpu/cpufreq/lulzactive/)
Inc CPU load: 90
Pump up step: 4
Pump down step: 1
Screen off min step: 6 @400
Up sample time: 10000
Down sample time: 40000
AIR KERNEL 3.0 (TEST VERSION)
-Conservative
Sampling Rate: 20000
Up Threshold: 60
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 10
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
The I/O Scheduler Selections
I selected the likely/proven best I/O scheduler for each kernel and governor combination, based on my previous work here: http://goo.gl/iJXWI
-SG-NS-ICS and Matr1x
Conservative: cfq
Ondemand: noop
SmartassV2: noop
LulzactiveV2: deadline
Lazy: deadline
For these two it's a little different in places:
-ICUP Speedy-7
Conservative: cfq
Ondemand: deadline*
SmartassV2: deadline*
LulzactiveV2: cfq*
Lazy: deadline
-Air Kernel
Conservative: deadline*
Ondemand: noop
SmartassV2: sio*
LulzactiveV2: noop*
Lazy: deadline
I've emboldened and marked with an * where the differences are.
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
bedalus said:
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
Click to expand...
Click to collapse
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Waiting for your feedback on this bedalus.
Bedalus is loving benchmarking too much that sometimes, he tries to benchmark his benchmarks
tchaari said:
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Click to expand...
Click to collapse
0.05mA difference: good point. I should probably mention that in the OP.
Yeah, conservative sucked pretty badly on all four of the kernels. Weird.
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
EDIT: Just noticed your benchmark benchmark idea. Only if I am not sleeping.
bedalus said:
0.05mA difference: good point. I should probably mention that in the OP.
Click to expand...
Click to collapse
If you found that the last two points are useful, can you also integrate them in the OP too?
bedalus said:
Yeah, conservative sucked pretty badly on all four of the kernels. Weird
Click to expand...
Click to collapse
Yes it was a surprise to me too but when joining your benchmark results and the theoretical basics of conservative, it all makes sense. Conservative is taking too much time to compute a task (scaling up slowly). It also scales down too slowly when finishing. This is noticeable especially in discontinued use like browsing.
bedalus said:
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
Click to expand...
Click to collapse
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
kernels ; battery ; ROM ; gov/sched
bedalus said:
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
Click to expand...
Click to collapse
I hope you will sleep smoothly now that this benchmark is finished
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
nice work.. AGAIN
so this explains why im happiest with ondemand.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
You could visit bedalus' other benchmark thread http://forum.xda-developers.com/showthread.php?t=1478418&page=1 and see which fits your taste best.
Anyway, great job on this new benchmark thread, bedalus.
I can't believe that you would actually go further on this.
Looking at your results, the best for me would be ondemand.
I rarely used my phone, only for messaging and XDA-ing , so most of the time the screen is off.
And as tchaari said, I couldn't see any difference between ondemand and smartassV2 in terms of performance.
Once again, thanks bedalus
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
AeroEchelon said:
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
Click to expand...
Click to collapse
There is ALWAYS more to tweak on our phones
Good work bedalus, your lack of sleep truly amazes me. I think we can enhance this a bit more by messing around a little with modified conservatives though. It shouldn't be very difficult at all to scale it down far quicker. I'm doing a couple of usage tests with various conservative settings and will let you know if i get any setups that may fit the bill.
As we know, conservative can easily give better performance than ondemand if told to, but i reckon we can get the best of both worlds. Does anyone know where i'd be looking to find the defaults of each governor in the kernel source? Saves me kernel crackflashing.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
simms22 said:
nice work.. AGAIN
so this explains why im happiest with ondemand.
Click to expand...
Click to collapse
Does morfic tweak on demand, I can't remember, I think I read it somewhere... ?
For completeness, and to save Harbb from becoming an emaciated crackflasher like us, I might just go through all the governers for each kernel I tested and note their settings down in the third post.
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
I think he was asking which scheduler you used with this benchmark. I'd bet it's deadline.
edit: bedalus, at least give me a couple of kernels to do and i'll note them down. You've had enough fun
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
Ah, I don't mean to ask what scheduler is recommended for each governor (because I've already got that info from your gov/sched thread ). Like Harbb said, I'm just asking that the specific scheduler used in this battery-saving benchmark is mentioned, whether you use the recommended for each or use the same scheduler for all of them (also I'm a she, not he ). Every phone is different and usage habits vary too, so I like to replicate the setup of benchmark winners to see if what you find best is best for me too.
My apologies deetailed. At least i got something right
As i said before, it is most likely deadline that was used since it has very uniform capabilities with each governor. Clarification would definitely be nice though, lack of sleep can do weird things.
tchaari said:
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Click to expand...
Click to collapse
After repeatedly flashing all the kernels, ROMs, and trying all the governor / scheduler combinations that are possible, I've become attuned to the device. For some people they may 'feel' the difference intuitively, others might imagine a difference. But for me, I've had over ten years of practice in timing tiny fractions of a second, all thanks to sound engineering. For example, I used to add Haas delays to close mic'ed instruments to simulate 'early reflections', giving the psychoacoustic impression of greater depth and imagining to these instruments in the mix. These delays are anywhere from 5ms to 40ms.
For me, smartassV2 will always go from input on the touchscreen to an animated transition virtually instantaneously, but with ondemand, if you are coming from an idle state, there is always a little delay. It's tiny, maybe 100ms, but for a sound engineer, 100ms is a huge gulf.
Related
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.
I wanted to know what the different governors do, rather than filling dev's threads up with questions I thought i would have a look around and do this for others who like me wanted to know what they do:
1: Interactive
The CPUfreq governor "interactive" is designed for low latency, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However there is no polling, or 'sample_rate' required to scale the CPU up. Sampling CPU load every X ms can lead to under powering the CPU for X ms, leading to dropped framerate, stuttering UI etc..Scaling the CPU up is done when coming out of idle, and like "ondemand" scaling up will always go to MAX, then step down based off of cpu load.
There is only one tuneable value for this governor: min_sample_time: The ammount of time the CPU must spend (in uS) at the current frequency before scaling DOWN. This is done to
more accurately determine the cpu workload and the best speed for that workload. The default is 50ms.
2:Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
3:Smartass
(Quoted from another author http://www.ziggy471.com/2010/11/07/s...-governor-info ) - "is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
4:Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
I assume performance, conservative, powersave and ondemand are self explanatory,
Userspace - finding conflicting info, so if a dev wants to help me out ??
All this info was found on the web in various places, where possible I have quoted where from. If people would like me to link back to them please let me know I will add.
This is purely to help people understand the governors a little without filling dev threads
Can people also leave user feedback on the governors they have been using to give us a reference point to help us all
if it helped hit thanks
Dooms Kernel : http://forum.xda-developers.com/showthread.php?t=1226826
Schedulers post 3
Nice one Chiefy, good to know we have a thread for quick reference when needing it.
Schedulers
NOOP scheduler
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent
HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a
switched Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.
Anticipatory
Anticipatory scheduling is an algorithm for scheduling hard disk input/output. It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
"Deceptive idleness" is a situation where a process appears to be finished reading from the disk when it is actually processing data in preparation of the next read operation. This will cause a normal work-conserving I/O scheduler to switch to servicing I/O from an unrelated process. This situation is detrimental to the throughput of synchronous reads, as it degenerates into a seeking workload.[1] Anticipatory scheduling overcomes deceptive idleness by pausing for a short time (a few milliseconds) after a read operation in anticipation of another close-by read requests.[2]
Anticipatory scheduling yields significant improvements in disk utilization for some workloads.[3] In some situations the Apache web server may achieve up to 71% more throughput from using anticipatory scheduling.[4]
The Linux anticipatory scheduler may reduce performance on disks using TCQ, high performance disks, and hardware RAID arrays.[5] An anticipatory scheduler (AS) was the default Linux kernel scheduler between 2.6.0 and 2.6.18, by which time it was replaced by the CFQ scheduler.
BFQ
The Brain **** Scheduler (or BFS) is a task scheduler designed for the Linux kernel in August of 2009 as an alternative to the Completely Fair Scheduler and the O(1) scheduler.[2] BFS was created by veteran kernel programmer Con Kolivas[3].
The objective of BFS, compared to other schedulers, was to provide a scheduler with a simpler algorithm, that did not require adjustment of heuristics or tuning parameters to tailor performance to a specific type of computation workload. The BFS author asserted that these tunable parameters were difficult for the average user to understand, especially in terms of interactions of multiple parameters with each other, and claimed that the use of such tuning parameters could often result in improved performance in a specific targeted type of computation, at the cost of worse performance in the general case.[4] BFS has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.
CFQ
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority. While CFQ does not do explicit anticipatory IO scheduling, it achieves the same effect of having good aggregate throughput for the system as a whole, by allowing a process queue to idle at the end of synchronous IO thereby "anticipating" further close IO from that process. It can be considered a natural extension of granting IO time slices to a process.
I am testing scary at the mo on stock gb so will edit my post tomorrow bro.
over the next week I will use scary, smartass, ondemand, conservative and interactive and report my findings back here
please all get involved and report back your findings
Can people also post their voltage findings with Dooms new kernel
Scary Report
Phone been on 9h 39m, medium usage, clocking set 128-1113, voltages changed as above post,phone very responsive and no lags, battery remaining 39%, AnTuTu benchmark 2755 linpack 39.
Interactive Report
128-1132 up time 6h 25mins, phone responsive no lag, medium usage 36% left, AnTuTu benchmark 2502 linpack 36 this governor doesnt seem to help battery level very much
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Neo said:
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Click to expand...
Click to collapse
so far the best governors that i have used have been Smartass and Scary but i will continue testing the governors and reporting back. Smartass was working great with no o/c for me, i will add this to this test. tomorrow i will test Scary with no o/c
Ok, my conclusions of using the scary gov on my modded stock gb is probally the best my phone has been, nearly all frequencies are being used, had to use min 192 and max 1190 as had a few screen off reboots but once using those settings my no more reboots. Battery life is the best i have had on custom kernel with flat line overnight, 3% loss, with wifi off and hourly updates of email, deep sleep working perfect as it should.
Overall, this is my personal favorite so far, just to add also this is using...
http://doomlord.sylvester20007.com/x10/x10_gb/dk/v02/dk-v02-X-modfxp_xrec.zip
I have not started using v03 of Dooms new kernel because of the good results with v02x.
Samrtass Report
Running Smartass governor uptime 5hours 1minute 128-1132cpu, medium usage, twitter, facebook two calls, brightness and 50%, AnTuTu Benchmark 1569 linpack 31 ( second linpac got WLOD ) battery 69%
Edit 10hours up time 42% battery left
As you can see smartass is a battery friend but performance suffers, although for my usage i find that this is the best governor for me at the minute
further governor tests continue
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
keep going!!
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
om23 said:
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
Click to expand...
Click to collapse
From what I have encountered it depends on the age of your phone, it is safe and won't blow you phone up but some models can handle far greater stress. the newer phones tend to be able to overclock higher, all that will happen if you phone cant handle the overclock is you will get the dreaded WLOD and your phone will reboot, then if you have set the speed from boot you may get stuck at boot image, but if that is the case then you use flash tool and reflash
chiefy009 said:
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
Click to expand...
Click to collapse
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
MinMax Governor (Battery Saver)
This governor will try to minimize the frequency jumps/changes which cause voltage spikes/changes and supposedly drain more battery life
Click to expand...
Click to collapse
Just my 2 cents!
My_Immortal said:
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
Just my 2 cents!
Click to expand...
Click to collapse
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
chiefy009 said:
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
Click to expand...
Click to collapse
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Scary Governor
Description coming from the author:
A new governor I wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
Click to expand...
Click to collapse
Performance suffers, in my opinion.
It scales the CPU conservatively, so it is very annoying when playing games
or even syncing to get your Gmails.
Also, and this applies to all governors, speed is decreased when the sampling rate is high. Which means that if the CPU constantly checks for load in order to increase/decrease frequency, that will take its toll both to performance and battery life.
Smartass - Interactive - Ondemand
I am putting those 3 governors in the same category, because at least for me, they functioned very similarly.
What I noticed is that indeed the phone used almost all available frequencies before going to MAX, but the phone was laggy. Especially when scrolling in big lists, interactive and smartass gave me unacceptable performance. Ondemand was a tad better, but still, the phone seemed to "resist" scrolling for a few seconds and then go ahead and finally do it!
Battery life was pretty much the same as stock
(since ondemand is the default governor for stock kernel).
MinMax
As I stated in my previous post, minmax gave me the smoothest and fastest results.
This governor doesn't take intermittent load samples, when it first detects CPU load, aka you start using your phone, it jumps to the max frequency and stays there until you stop using it.
At this point, I want to express my opinion on the subject of "High Freq When Screen On", because many users complain about it, but I beg to differ.
In theory, CPU running at max frequency all the time, is heat generating and/thus battery consuming. Alas, be careful: in theory...
Because practically, when you use your phone, you usually do CPU demanding tasks.
When the phone is in my pocket/bag/drawer/whenever doing nothing, I want to be in Deep Sleep.
When I turn it on to look at the time of if there's any new notification, that lasts 30 secs - 1 minute. What frequency will be used then, is not that important.
When I turn it on to actually do something, I want it to be FAST.
If I can scroll a list faster, if I can open an app faster, then I will be using the phone for less time.
If the CPU is sampling and scaling up conservatively, the phone will be laggy
and I will need more time to accomplish my tasks.
All in all, I am not intimitaded by high frequencies while using the phone.
I would start worrying if I got no Deep Sleep -which isn't the case fortunately.
And my battery life is amazing, I get about 1 day and a few hours more,
with pretty heavy use.
Just my 2 cents on the matter.
Powersave
If you are ever really mad at your X10 and you want to see it struggle and suffer, then this is the governor for you! Enough said!
Performance
Pretty snappy, good for gaming and benchmarking, as it uses only MAX frequency. Not for prolonged use though, because it will ONLY use the max frequency (and Deep Sleep of course).
I'll make sure to make more tests in the future and post more thorough reviews!
Again, thanks for this thread chiefy009!!
My_Immortal said:
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Click to expand...
Click to collapse
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
chiefy009 said:
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
Click to expand...
Click to collapse
I have undervolted my phone using these values:
128000 Hz - 875 V
192000 Hz - 900 V
245760 Hz - 925 V
384000 Hz - 950 V
460800 Hz - 975 V
576000 Hz - 1000 V
652800 Hz - 1050 V
768000 Hz - 1100 V
844800 Hz - 1150 V
921600 Hz - 1200 V
998400 Hz - 1250 V
The phone runs pretty stable, didn't have a single reboot or WLOD so far (3 days).
Xperia X10i via Tapatalk
I will try those settings for undervolting
Smartass Update
This governor is working wonders for me at the minute, phone been online for 6hours, medium/light usage 128-1132mhz few calls, connected to bluetooth speaker in car, little web usage and twitter and the battery is still on 88%
That is impressive
Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/show...65&postcount=2
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24:Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Goveronor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: Hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817
This is really interesting , so is smartass better than v2 for battery as we know from tests that with deep idle 400mhz is best...
Sent from my Nexus S using Tapatalk 2
italia0101 said:
This is really interesting , so is smartass better than v2 for battery as we know from tests that with deep idle 400mhz is best...
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
for my part in the various tests I've done for me, smartass v2 works better
Did you keep defaults of v2?
Sent from my Nexus S using Tapatalk 2
italia0101 said:
Did you keep defaults of v2?
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
is also factory defaults no problem
as governor frequently used and why?
so we try to give references to new users
stempox said:
as governor frequently used and why?
so we try to give references to new users
Click to expand...
Click to collapse
changes coming
added badass
Enlightening, I wasn't even aware there were so many governors.
next governor added pegasus
stempox said:
next governor added pegasus
Click to expand...
Click to collapse
Thanks for new user like me very useful
blonde90 said:
Thanks for new user like me very useful
Click to expand...
Click to collapse
thanks, always available
new governors coming
Wheatley added
I am astonished how many governors are available.
Very clear and easy to understand.
This has enabled me to choose which governor to use based on habits.
Thanks for this. Added to subscribe for future reference!
Sent from my Nexus S using Tapatalk 2
thread updated
Great thread. It explained some of what I didn't know about the various governors and even showed me some new ones.
Sent from my ADR6400L using Tapatalk 2
This really helped me out! Great thread! Thank you.
Sent from my Nexus S using xda app-developers app
{
"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"
}
Ultimate battery guide
Battery, one of the most important thing on todays phones. Even if we have awesome battery life we always want more and it is never enough.
This is the small guide to tips, trick and tweaks to improve battery life.
This topic is to share tips and tricks and basically just small talk about battery and sharing screenshots.
Use Gsam or Android battery history to show your battery life.
Our goal is to make most of the screen on time with average use of 24 hours. So lets start.
Post 1: Tips
Post 2: ROMS, kernels, undervolting, underclocking
Tips to improve battery life
Location services
One of the first thing that your device will ask when you are setting up your phone. Most of the users let them ON and just forgot about them. Location services are battery hungry and the will drain your battery like you drinking juice.
Thing is that you do not need them always, just sometimes. Turn it OFF then. I have them turned off always and when I need it I just simple turn it ON.
Wi-Fi
Wi-Fi scanning is thing that will drain your battery always. When you are out and you are not expecting to use wi-fi any time soon turn it off. You do not need to run scanning all the time.
You could also edit build.prop to reduce.
Edit wifi.supplicant_scan_interval. Default value is 180. You can set it higher to reduce the scanning intervals.
Signal strength / Network mode
Signal strength is always trouble for battery. Weak signal will drain more battery. Also, constant changing between 4G/3G and 2G will drain battery faster.
Tweak to this is to set your phone to only use 2G, 3G or 4G.
Example: when I am not using my phone, or it is connected to wifi my network is on 2G. I dont need 3G or 4G then and changing network state is disabled then because it will stay always on 2G. I found it has positive effect on battery.
When I need, I just simple toggle 3G or 4G.
Screen brightness
Screen is the thing that drains most of our battery. There is not much philosophy here. Higher brightness will drain more battery.
My personal setup is that I do not use auto brightness. I always change brightness manually. Right now during winter my brightness does not go more then 25% outside, and inside it is lower. At night it is under 10%.
I found that not using auto brightness has also slight positive effect on battery.
Syncing / Airplane mode / Vibration / Animations / Task Killers
Lets start in order.
Syncing: more syncing your device does it drains more battery. On your phone probably you do not to sync all accounts and apps you have every few minutes or hours. Set those apps you do not need on manual sync.
Airplane mode: I am using airplane mode during night because I do not want to be disturbed during sleep. With airplane mode battery consumption during night is 0%. Yes, zero percent.
Vibration: more your device vibrates, more battery it drains. You can reduce vibrations on keyboard settings and similar. I found that is not much effect on battery but it has slight.
Animations: animations drains your battery also and who really needs them. Personally, I am annoyed with them and I always switch them to 0 or .5. You can do that in Settings-Developers options
Task Killers: task killers, clean maters and similar software is a big NO. You dont need it. It does more damage then good.
Bloatware
Yes, bloatware. There is huge amount of bloatware on our phones and we really do not need it. So, what to do? Freeze that bloatware.
You can find list of apps HERE. There is also available tool for auto disable, ImproveG3
ROMS and kernels
Custom ROMs and kernels will give you in most cases better battery life then stock firmware. Plus there is huge amount of options to play with. You can read more in posts bellow.
Summary:
If you change some of those thing you will see the effect.
You can always use apps like Greenify or Tasker and play with their options.
How to follow your battery life
GSam Battery Monitor
This one of the most useful apps to track your battery. On Lollipop (even on Kitkat) it will not give you much useful info without root.
If you are using it without root everytime you reboot the phone statistic would be reset also. If you have root it will give you access to wakelocks and some other stuff, plus stats would not get reseted.
Play store link
Wakelock detector
Wakelocks, one of the painful things on phone. If you see your battery is draining faster in idle then you got problem with wakelocks. This is useful app because it shows wakelocks on very simple setup and you can discover which app is causing which wakelock.
Play Store link
Disable service
If you are using Wakelock detector you need this app also. With this app you can freeze every single process that app can launch. It will provide detail look on all processes from apps. With this app I have reduced wakelocks to 1%.
Play Store link
ROMS
Discussion about ROMs never looked nice. It always gets to what you personally like. Some ROMs will be easier on battery, some will be rough. You will never know before you try them.
Kernels
Kernels are similar to ROMS but you can play with them. Currently there is not much kernels available but you can play even with stock one.
I recommend to use Trickster MOD Kernel Settings app to play with kernel settings.
Undervoting
Undervolting is the thing when you control how much power each CPU frequency can have. Trickster MOD app gives really nice view on them. You can undervolt every frequency by itself or all in one.
My personal recommendation is to undervolt them at once. I always use -50 value. Found it stable.
Of course, you can always play with different values but remember: when you play with this do not click on option "Set on Boot" or you will end in bootloop if you click it. Click that option when you find out that values are safe for using and stable.
Underclocking
Underclocking is changing your CPU frequency. Rough truth is that we dont need our CPU to run on 2,7 GHz in normal use. Only gamers will need that probably but since this is not thread were we are aiming gamers we dont need that high frequency.
Me personally, I use always 1,7 GHz or 1,9 GHz. To my daily usage (most common like everyone else but without games) this is more then enough. Everything is still smooth and runs fast.
Governors
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
You can find explanation hidden here.
Many users have wrote about governors and they are practically the same on most of the phones so I will copy list from droidphile.
On his topic you have more details about governors.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
20) Wheatley
21) Smartmax
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after 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 very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
20) Wheatley
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
21) Smartmax
Its no benchmark or ultimate perfromance governor, its a proper balanced ondemand.
The basic idea - which comes from smartass - is the concept of an "ideal" frequency.
The following strategy is used:
1) If load is above upper-threshold and current frequency is below ideal freq
-> jump to ideal in one step
2) If load is above upper-threshold and current frequency is at or above ideal freq
->do "ramp up" steps which will include all frequencies for a specific
amount of time - so compared to ondemand no "jumping" to max frequency
3) if load is below lower-threshold and current frequency is below ideal freq
->do "ramp down" steps
4) if load is below lower-threshold and current frequency is above ideal freq
-> jump down to ideal in one step
All those thresholds ramp steps and frequency stepping times are
fully configurable using sysfs. By default I tried to create a good balance.
The ideal frequency for "us" is 475000 which is the maximal frequency
of the LP mode of the tegra chip. This will allow using LP mode as much as possible
Additional to make it "snappy" smartmax has "touch poke"
So input events from the touchscreen will boost the cpu for a specific
time to a specific frequency.
Schedulers
Everything has been said about them so I will use droidphile explanations.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
reserved
Lets talk and share tips
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Ok so the best setting for governors and I/O control battery life and perfomance
veekay said:
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Click to expand...
Click to collapse
I am using SmartassV2 and noop.
TIP
For those who most of the day stay indoors and don't need a very bright screen like me, may install this xposed module, Minimum Brightness.
With this you can lower the minimum brightness of the screen beyond the usual value. It aids in saving quite some juice. :good:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Saratoga79 said:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Click to expand...
Click to collapse
Nice setup.
On first look it looks like stable setup.
DelBoy said:
Nice setup.
On first look it looks like stable setup.
Click to expand...
Click to collapse
Thanks buddy!
Yes it is pretty stable with no reboots or feezes. Also perfomance seems to be good enought and I haven't notice any lag.
This is my todays battery.
22% left. Used 75% with 19 hours on battery and SOT 5 hours for now.
During this 19 hours airplane mode was ON for like 6 hours during the night.
Results can get better. This is on V20A. I believe V20D will get me better results.
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
Early to judge, but it is the same I believe. Not much difference.
Updated post with few more governors
Very nice one
Would you mind adding a link to ImproveG3 to the "Bloatware" section?
Oh and I didn't change much cpu wise, just Amplify'ed Wakelocks RILK, NlpWakeLock and NlpCollectorWakeLock, device remains at 100% during night (~7-8 hours) without using airplane or turning off data/wifi/syncing
Don't have extremely many apps installed though, and set syncing intervals that make sense, depending on app/account.
Thank you very much.
Regards,
sub
@subworx - added
How can I use those governors I have Stweaks but can't find it there
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
For me 4.4.2 has a lot better battery life
AAA118 said:
How can I use those governors I have Stweaks but can't find it there
Click to expand...
Click to collapse
You need to have custom kernel that has that governors (Rin kernel, or ChupaChups).
After that use TricksterMod or CPUcontrol to change governors.
Now that we have root access and are able to make modifications to the interactive governor, I have worked through the same principles of the nexus 6p governor tweaks as they would be applied to the Pixel C X1.
Original Guide:
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
and extra help from @xSilas43 to further refine the settings
So the main differents between the qualcomm and nvidia are core count and cpu freq steps are different, so some options aren't available (touchboost etc) but the theory is still the same. The only thing missing now is a method to determine voltage of each cpu freq step so we can get better effective values.
So I went through and did all the maths based on the proper target loads and i think its optimised properly now with lower cpu values then before.
Important: set the min cpu speed to 102Mhz as seems that its set to 204 by default but perfectly fine to sit that low.
So based on my testing with stock given the recently discovered bug on stock
I don't recommended using these tweaks at present so please only use if you are on dirty unicorn or other asop build
V3.1 PixelBits testrev
target_loads - 8 102000:40 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
Previous Versions
V3.0 PixelBits
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.2 more refinements edition with help from @xSilas43
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:8 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 408000:20000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.0 Optimised for X1 (based on nomial loads with min and max thresholds based on target loads)
target_loads - 45 102000:45 204000:50 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:11 1020000:10 1122000:9 1224000:83 1326000:8 1428000:84 1530000:7 1632000:85 1734000:6 1836000:86
timer_slack - 80000
hispeed_freq - 306Mhz
timer_rate - 40000
above_hispeed_delay - 30000 612000:20000 714000:20000
go_hispeed_load - 99
min_sample_time - 30000
V1.0 Lazy Values
target_loads - 75 408000:69 612000:80 714000:79 816000:80 918000:81 1020000:69 1326000:84 1632000:82 1836000:86
timer_slack - -1
hispeed_freq - 306Mhz
timer_rate - 20000
above_hispeed_delay - 30000 612000:20000 714000:10000
go_hispeed_load - 75
min_sample_time - 60000
Attached the latest profile for use with EX Kernel Manager for those that have it.
Place in Elemental X/gov_profiles and should appear in the app under gov options.
Please try out and let me know any feedback or issues with these settings, but everything should be stable as i have been running this for about 3 weeks now with no issues.
What other governors are available with the pixel kernel?
bill3508 said:
What other governors are available with the pixel kernel?
Click to expand...
Click to collapse
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
beardymcgee said:
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
Click to expand...
Click to collapse
Does the conservative governor have the touch boost option?
bill3508 said:
Does the conservative governor have the touch boost option?
Click to expand...
Click to collapse
nope nothing does
So no one interested in trying it?.....
beardymcgee said:
So no one interested in trying it?.....
Click to expand...
Click to collapse
Trying it now. Feels real snappy so far.
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
beardymcgee said:
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
Click to expand...
Click to collapse
I definitely think so. Ive never really been a big fan of interactive but until the 5x and 6p threads no one has really modified the values like that. I still haven't messed with any of the scripts folks are running on those devices but I may play around with the numbers some. Seems to be working great on the C. Thanks again.
So based on my usage I got 3 days of use with 9.5 hours SOT and 10% to go, would love to hear from more people if this did anything.
I just charged up so I'll let you know at the end.
Cheers for helping out, its sad that people would rather complain about software issues that will be fixed soon, than do the normal xda custom thing.
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
beardymcgee said:
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
Click to expand...
Click to collapse
I'll try the new values next charge up.
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
Root method has been fixed just don't flash su in twrp and follow the method in the twrp thread.
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
beardymcgee said:
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
Click to expand...
Click to collapse
But I doubt we would have the throttling problems that the 810 does so I could only see it as beneficial. Also the smaller cored would likely only improve already stellar battery life using setups like we're seeing on the 6p.
so I been reading the original thread and came up with 2 paths.
one using the original basic tuned method to have a nominal target speed for different functions like web browsing and video playback etc and increase the focus on these speed steps only while minimising the time on others.
or based on what the current recommendation in the "easy way" say to just use max efficient loads on each step
but as I have been tinkering too much i cant tell any more which is better so I have created a poll so please try these 3 version and vote on which is better