1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Smartass
8) SmartassV2
9) Intellidemand
10) Lazy
11) Lagfree
12) Lionheart
13) LionheartX
14) Brazilianwax
15) SavagedZen
16) Userspacce
17) Powersave
18) Performance
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) 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.
8) 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.
9) 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.
10) 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.
11) 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.
12) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic (MY FAVORITE DEV) 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.
13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
17) 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).
18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
Regards
Avetis
Correction:Brazilianwax also falls in weird category.
Nice info in one place!
And what about wheatley, abyssplug and hotplug governors?
ThANK you for this! I've always wanted to know this information
From the giant: Galaxy Note
Cool...that makes Android even more sophisticated
Can I get & use governors?
I know I am going to sound like a noob, but I keep hearing about these, and I am interested in what they can do for me. What I cannot figure out is what they are (I see what they do) and where to get them.
My phone is rooted, but stock ROM. Can I get & use governors?
jeromepearce said:
I know I am going to sound like a noob, but I keep hearing about these, and I am interested in what they can do for me. What I cannot figure out is what they are (I see what they do) and where to get them.
My phone is rooted, but stock ROM. Can I get & use governors?
Click to expand...
Click to collapse
download "No-frills CPU control" from the market
This may explain a bit more detail => http://forum.xda-developers.com/showthread.php?t=1369817
jeromepearce said:
I know I am going to sound like a noob, but I keep hearing about these, and I am interested in what they can do for me. What I cannot figure out is what they are (I see what they do) and where to get them.
My phone is rooted, but stock ROM. Can I get & use governors?
Click to expand...
Click to collapse
A lot of people recommend using SmartAssV2 and SavagedZen, between both I've never really seen the performance differences or benefits based on my own usage. I did actually see a performance drop in the UI if I change my CPU mode from dualcore to hot plug if I use any of the custom governors.
With the performance level on the Galaxy Note, I dont think its necessary to change anything even the battery savings on this might be miniscule at best.
nbass668 said:
download "No-frills CPU control" from the market
Click to expand...
Click to collapse
Thanks for that. I can't see any better governors than SetCPU, however, although they may be applied better (SetCPU seems to stop my phone sleeping, kind of a Red-Bull effect?)
---------- Post added at 12:20 PM ---------- Previous post was at 12:17 PM ----------
aatjitra said:
This may explain a bit more detail => http://forum.xda-developers.com/showthread.php?t=1369817
Click to expand...
Click to collapse
OK, so it appears I need to flash a custom kernel then? One day I'll feel confident enough to understand the difference between a kernel and a ROM, and feel confident enough to apply either. I guess I have more to read....
Yup, flash a custom kernel. Use CWM or Mobile Odin.
Sent from my GT-N7000 using xda premium
jeromepearce said:
Thanks for that. I can't see any better governors than SetCPU, however, although they may be applied better (SetCPU seems to stop my phone sleeping, kind of a Red-Bull effect?)
---------- Post added at 12:20 PM ---------- Previous post was at 12:17 PM ----------
OK, so it appears I need to flash a custom kernel then? One day I'll feel confident enough to understand the difference between a kernel and a ROM, and feel confident enough to apply either. I guess I have more to read....
Click to expand...
Click to collapse
It depends on what rom/kernel/governor you are using.
Sent from my GT-N7000 using xda premium
What about Abyssplug and Weathley governers ?
Sent from my SGH-T989 using XDA
Avetny,
Could you please also elaborate on the I/O Schedular: Noop, deadline, cfq/bfq, vr and sio. If you have time off course
Thanks in advance
Isn't this the same content as this thread?
http://forum.xda-developers.com/showthread.php?t=1369817
Sent from my GT-N7000 using xda premium
This should be stickied
Sent from my GT-N7000 using Tapatalk
GOVERNORS info
:good: Thanks a lot. This is exactly what I am looking for.
Spreadsheets for CPU Governors and I/O Schedulers
GOVERNOR RESULTS
I/O SCHEDULERS
Summary of the Results
This is a summary of the six most commonly used governors, listed in order of performance.
Best Performing
#1 - Performance
--- : Use Noop or Deadline
--- : Uses a lot more battery
#2 - SmartassV2
--- : Use Noop or SIO
--- : Good choice if you use a lot of CPU intensive apps
#3 - LulzactiveV2
--- : Use Deadline or Noop
--- : Good choice if you use a lot of CPU intensive apps
--- : Uses a little more battery than SmartassV2
#4 - Lazy
--- : Use Deadline or CFQ
--- : Do not enable SOMF (Screen Off Max Frequency uses more battery)
--- : Good choice if you do not use CPU intensive apps
#5 - Ondemand
--- : Use Noop or Deadline
--- : Good choice if you do not use CPU intensive apps
--- : Saves slightly more battery than Lazy
#6 - Conservative
--- : Use CFQ or Noop
--- : Generally one of the worst governors for saving battery, see next post for why.
Check my summary in the Battery Drain thread for more info about how to save battery.
Where did the other benchmarks go?
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
Battery drain: this thread
Power Saving Governors: this thread
Thanks to all the developers.
Conservative Not Saving Power?
chickelnoodensoup said:
Is the summary in the first post correct with regard to conservative? Is it really "Generally one of the worst governors for saving battery"? Interesting.
Click to expand...
Click to collapse
I know it seems a little odd. It's because a lot of developers seem to have tweaked conservative to make it feel snappier, but it has resulted in more CPU time at the top frequency.
If you take a look at my new spreadsheet: http://goo.gl/ThVzX
...you can see conservative always uses more power when the screen is on (at least for the four kernels I tested).
There is just 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. 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.
For people who don't use their phone while off, and don't use many intensive apps, Ondemand is the best power saving choice.
For people who use a lot of CPU intensive apps, SmartassV2 will be the better choice. It will scale more agressively, help prevent lags, and save energy being wasted through these delays.
If you listen to music with the screen off, and your kernel supplies deep idle, the best power saving governor is SmartassV2 (except for the case of Air Kernel, see above). This is because it keeps the CPU close to the most efficient frequency: 400MHz.
I hope that covers anything. If I've made any glaring errors in my reasoning, please let me know.
Choosing a Governor
Variety is the spice of life, so try them all! While Mathkid95 swears by Ondemand, developers Eugene373, morfic, and steve.garon all vetted this work and agreed that the highest performing CPU governor is likely to offer battery savings through the race-to-idle principal. Eugene added that finding the right I/O scheduler to combine with your governor will make a big difference too. Extra thanks to Steve for providing the kernel on which I based this test, and all his valuable input! The I/O scheduler for the test was cfq, and note: governors have settable parameters which may vary between developers.
Choosing a Scheduler
I/O schedulers perform differently depending on the governor you are using. I've investigated this using the six most popular CPU governors (vote here) vs the six available I/O schedulers in Eugene's kernel, and the four available in r_data's kernel. All governors are based on either ondemand, interactive, or conservative. Recommended reading is available here: schedulers also for governors
Schedulers tested against these popular governors:
SmartassV2 - interactive variant, and winner of the governor test.
LulzactiveV2 - interactive variant
Lazy - Ezekeel's governor, ondemand variant
Performance - included as a reference for high scores
Ondemand
Conservative
Testing Methodology
To test the kernels I want a fair environment, so any differences in the results are down to the kernel, and nothing else. To achieve this I first make sure I have a clean system:
1) Format /system and /cache and wipe dalvic
2) Install the ROM, install the kernel
3) Boot up, use nstools to select deadline for I/O scheduler
4) Then select a CPU governor and I/O scheduler depending on the test at hand
5) Titanium Backup to restore all my benchmark programs (app only). Set everything to off, no gps, no sync, no BT, airplane mode. Force GPU rendering is selected. Wifi is on for connecting to the benchmark servers. A power adaptor is in use so the battery is always full.
Then I begin testing.
For the CPU Governor Comparison study:
6) Power off and power back up. When lock screen arrives, wait one minute to settle the system, i.e. until screen auto-off. Count to three. Unlock, and begin testing, recording all scores. Start over with all the tests. Record those scores. (I now have two sets of scores for all the benchmarks to create a mean for improved accuracy). Then select next governor, power off and on, and start the cycle again.
For the I/O Scheduler Comparison study:
6) Power off and power back up. For each new scheduler I completed one test which I did not record, just to ensure that the program was properly cached in the system. I then recorded the subsequent ten results. After ten results, I would select the next scheduler, until I had finished all six, then I would also select the next governor and go back to the first scheduler. I repeated this cycle until I had collected data for performance, and the three other main governor types.
Statistics in the scheduler study are a little different to the other tests. They combine overall performance scores with overall variance scores (where lower is better). The formula is
a= Database IO score - 3 standard deviations
b= Write speed - 3 standard deviations
c= Read speed - 3 standard deviations
score=(a*b*c) to the power of 1/3
If you multiply three values together, and take the cube root (same as raising to 1/3) then you arrive at the geometric mean. This type of mean allows the comparison of two different schedulers based not just on their performance, but also how consistent in that performance they are. That score is then compensated by adjusting by half of the percentage discrepancy between the mean and median. For most scores that is an adjustment of less than 1%.
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Nice work on this!
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Click to expand...
Click to collapse
Im also prefer smartassv2+noop. Really good combination
Very usefull, Thanks
Surnom said:
Very usefull, Thanks
Click to expand...
Click to collapse
No problem. If anyone is wondering why so few posts, it's because I recently separated this work away from my kernel benchmarking thread. Feel free to feedback.
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
This is the combination I personally prefer. However, this is merely my opinion, based on my tests. Mathkid95 prefers ondemand. At the time of writing, Steve Garon and Franco prefer their own tweaked versions of conservative. (My tests indicate CFQ is the best match for conservative.)
Click to expand...
Click to collapse
Never kneww that SmartassV2 works best with noop! I used to have it with deadline. Now experiencing the best experience ever!
using Franco BFS Nov 1st
Thanks man! Thanks Franco!
SmartassV2/Noop +1
UPDATE: Steve had a rethink of his Conservative governor parameters, and I've updated the table to include this. Check column L.
Lower scores are natural with conservative. This time, with the new parameters, the scores are even lower. This indicates that the new conservative is throttling the frequencies more aggressively, but it should also be noted that this governor feels much more responsive than the previous incarnation.
Note - the IO score shows a great improvement, but this is due only to a boost in database IO through the recent FSYNC patch. Make sure you use stable voltages to avoid reboots and potential data loss. (No benefit to UV anyway - check the results of my battery study, see link above.)
thx mate! You do a great job!
Sent from my Nexus S using Tapatalk
Some serious work been put into this.. Anyway of listing governors in respect of there performance then a list of governors for best battery life and the recommended I/O schedulers to accompany them. I know the graph is there but it'll be easier for people like me (not so good with cpu settings) to just simply apply from a high to low list which indicates best performance or more battery life. I'm getting great battery life and decent performance using ondemand with noop but it eats battery a lot more when phone is in use compared to other combinations I've tried.
Sent from my HTC Desire S using XDA App
bedalus said:
Summary of the Results
SmartassV2 won the governor benchmarks, and also performed well in the battery drain benchmarks.
The best I/O scheduler to combine with this is noop.
Click to expand...
Click to collapse
Is it just me or does the spreadsheet say deadline is best with SmartassV2 with noop second?
dabado said:
Some serious work been put into this.. Anyway of listing governors in respect of there performance then a list of governors for best battery life and the recommended I/O schedulers to accompany them. I know the graph is there but it'll be easier for people like me (not so good with cpu settings) to just simply apply from a high to low list which indicates best performance or more battery life. I'm getting great battery life and decent performance using ondemand with noop but it eats battery a lot more when phone is in use compared to other combinations I've tried.
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
Good idea. I will try to do it today.
kernels ; battery ; ROM ; gov/sched
Thaks to your recommend, I use noop + SmartassV2.
I used cfq+tweaked conservative before that set, but I can't feel differece and battery life (I don't know this phrase mean but I'm saying it is very good!)
UPDATE: First post edited. Now summarises all findings. Also, makes it easier to read if you are using the XDA app
Thank you !
Bedalus, I did a little amateur test today.
I played some music with not-too-loud volume.
I keep my data ON, everything else is off.
The screen is always ON with lowest brightness because I'm looking at the CPU frequency used.
CPU min 200, max 1000.
I went to Processor settings and look at the CPU frequency used at the moment.
When I selected Conservative and let it stay for 10 seconds, the CPU freq is showing 1000 constant.
Then I selected Lazy and let it stay for another 10 seconds, the CPU freq is 400 constant.
With SmartassV2, let it stay for 10 seconds, the CPU freq is randomly jumping from 200, 400 and sometimes 1000.
Well my question is, shouldn't Conservative be constantly using the lowest frequency among the other governors?
From what I saw it is Lazy which constantly used the lowest.
What do you think?
I know this test is not reliable at all, so sorry if it's just a waste of time.
glennkaonang said:
Bedalus, I did a little amateur test today.
I played some music with not-too-loud volume.
I keep my data ON, everything else is off.
The screen is always ON with lowest brightness because I'm looking at the CPU frequency used.
CPU min 200, max 1000.
I went to Processor settings and look at the CPU frequency used at the moment.
When I selected Conservative and let it stay for 10 seconds, the CPU freq is showing 1000 constant.
Then I selected Lazy and let it stay for another 10 seconds, the CPU freq is 400 constant.
With SmartassV2, let it stay for 10 seconds, the CPU freq is randomly jumping from 200, 400 and sometimes 1000.
Well my question is, shouldn't Conservative be constantly using the lowest frequency among the other governors?
From what I saw it is Lazy which constantly used the lowest.
What do you think?
I know this test is not reliable at all, so sorry if it's just a waste of time.
Click to expand...
Click to collapse
It sounds like quite an interesting test. I'm surprised at the conservative result. Which kernel are you on?
GENERAL GUIDE TO KERNEL SETTINGSsome focus on Dorimanx and Boeffla KernelsPOWER CONSUMPTION VS PERFORMANCEGOVERNORS AND HOTPLUGSI/O SCHEDULERS, NET CONGESTION, BENCHMARKSUPGRADE/DOWNGRADE BOOTLOADERS, RECOVERY
The purpose of this thread is to put in one place some answers to a LOT of questions on what governors and hotplugs actually do and how to search for your best kernel settings that match your style of phone use.
I also suggest trying the multi-core with low frequency approach for very good performance AND battery savings (yes, you can have both). Frequencies of 1.5/1.7 GHz with an aggressive governor and hotplug should give the same performance as 2.5/2.8 GHz frequencies but with massive battery savings.
I am still in the early stages but would hope others will try this.
This is NOT an ULTIMATE guide, please provide all feedback and comments you see fit, it is all welcome, there are a lot of people with experience and knowledge in this forum.
Post 1: Table of contents
Post 2: Basics of performance and power consumption: how to save power without sacrificing performance
Post 3: Governors, Hotplugs and Recommendations
Post 4: More Detailed Reviews and Recommendations with an emphasis on Dorimanx/Boeffla kernels
Post 5: Visual Comparisons of Governors, Hotplugs
Post 6: Comparisons 2 cores high freq vs 4 cores low freq
Post 7: Battery saving tips and smoothness/lag-free tips
Post 8: TCP NET CONGESTION
Post 9: I/O Schedulers
Post 10: upgrade/downgrade recovery/bootloader/kernels to JB/KK bootloaders, bumped/loki: implications for flashing ROMs.
Post 11: BENCHMARKS
Post 12: Cool Tool Settings
CREDITS to a LOT of people! @dorimanx, @boeffla for their kernels, @ZaneZam for his great governors, @gsstudios for his phenomenal governors guide, xda forums for teaching me, and so many others!
**************************************************************************************************************************************************************
**************************************************************************************************************************************************************
Changelog:
24.02.2015: minor
- added text on power consumption post 2, minor update. Added 2 links to qualcomm blogs for more info.
- added boeffla's settings for his kernel to post 4.
23.02.2015: minor
- added intelligent HP to Dorimanx text
- recommend intelligent HP as alternative to MSM for less battery drain
20.02.2015: MAJOR
- NEW POST #6: VISUAL COMPARISONS OF 2 CORES HIGH FREQ TO 4 CORES LOW FREQ
- post 5: added Dorimanx governors pictures
- moved post #7 to #10 (THANKS d00ltz!)
- moved post #6 to #7
19.02.2015: MAJOR
- NEW post 5 completely re-written with new stuff
- post 5 "battery savings tips, etc" moved to post 6
- post 6 "cool tool" moved ot post 12
- merging of dorimanx/boeffla specifics in one post (#4)
- complete re-write of dorimanx/boeffla specifics
- complete re-write of post 3 for general governors/hotplugs
18.02.2015: minor
Post 4: added dedicated kernel settings thread link, added extreme battery profile
PERFORMANCE AND POWER CONSUMPTION BASICSAnd how to achieve same performance with less battery drain
performance = how quickly things get done
power consumption = how much battery is used
Let's take a car as analogy. The performance (speed) would be represented by time to 100 kmph and time to travel 1 km, for example. Consumption would be total fuel consumed.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
CPUs, GOVERNORS AND HOTPLUGS:
For cpus four things matter:
1. clock freq. We will assume that at double the frequency the task takes half the time.
2. how many cores are in use. This is from the hotplug.
3. scaling frequency. how does the governor ramp up the cpu freq and how long it takes to get to max freq.
4. thermal engine.
CPU power consumption = voltage^2 x frequency x capacitance
P = v^2 x f x c
P= power
v = voltage (can be modified by kernel, but not recommended if you don't know what you're doing)
f = frequency (can be modified by kernel)
c = capacitance (depends on actual physical build of the system)
See attached picture for a graph representation of CPU power consumption versus frequency and note the non-linear aspect. This is due to the voltage being a non-linear parameter in power consumption.
The picture is a bit misleading, at higher frequencies above 1400 MHz the voltage rises more quickly and power consumption increases more rapidly.
{
"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"
}
NOTE: undervolting can greatly help reduce power consumption, but it can be very bad for your cpus, it can fail to trigger cpu cycles and all sorts of other things, it is NOT GOOD unless you know what you are doing.
other assumption: your cores can have voltage distributed individually and at different voltages from each other.
Clock frequency:
Let's assume that double the clock freq means the task takes half the time. This might not be true of badly designed cpus, etc. But who cares.
The consumption is LINEAR with frequency, if you have double the clock speed you will use double the power. BUT THAT'S NOT TRUE FOR VOLTAGE!!!!
A cpu uses more voltage at higher frequencies, so the power consumption rises VERY QUICKLY with higher clock speeds.
So the question is: is it better to have multiple cores at lower frequencies or one core at high frequency?
Hotplug and multitasking:
If you are doing ONE task, and the application/system is good enough to use all the cores, then doubling the cores will lead to the task taking half the time.
But, if you are multitasking, some cores are doing something else and can't be used. So in practice having double the cores doesn't mean having double the available frequency.
The hotplug can be aggressive or not:
- as soon as more cores are needed it will wake all of them up and get things done. More performance, more consumption.
- it will wake up cores more slowly and keep them on for less time. Less performance, less consumption.
Scaling frequency:
Coming back to the car, if you want pure performance you floor the pedal and achieve the best results in terms of time to 100 kmph and time for traveling 1 km but you burnt all your fuel.
A governor that scales frequencies can do it in two ways:
- max power for a long time: same as flooring the pedal, jump straight to max freq and stay there until the end of the task. Some governors will stay there longer, expecting that you will do a task requiring max freq pretty soon after you've done it.
- scale freq over several steps with plateaus for a certain time. This is like setting speed limits on the race track: the car will accelerate more slowly, take longer to get to the destination but burn a LOT less fuel.
Thermal engine:
cpus get hotter at higher freq, to the point where you can PERMANENTLY DESTROY or DAMAGE them.
Hence, the kernel will have a thermal engine to regulate clock frequency depending on cpu temperature.
What this means is that for heavy tasks that take a long time, the maximum practical cpu frequency will be MUCH LOWER than the theoretical max frequency. For example, if you have max freq at 2547, your thermal engine might simply set the freq at 1190 during the task! That's a GOOD THING!
**************************************************************************************************************************************************
**************************************************************************************************************************************************
THE BIG QUESTIONS:
Should I use more cores at lower freq or not?
What is the difference between one core at high freq vs one core at lower frequency?
In a simple system, one task to do, let's have a look. I am using voltage/freq from OnePlus One phone, but I expect things are similar for everyone.
If the task is long and heavy, all the cores will work at reduced freq due to thermal engine, so it doesn't matter what you do. These results are only for quick tasks.
PS: don't ask about the units, this is relative comparison for ratios, so units don't matter.
The real drop in performance is not as much as the simple frequency reduction, it depends a lot on the cpu hardware. Some numbers I found (for different cpus):
- 31% frequency reduction = 26% performance reduction; 66% reduction in power consumption
- 20% frequency reduction = 13% performance reduction; 49% reduction in power consumption
But the numbers shown below are approximately correct.
Example 1: same task, 1 core vs 2 cores
1 core at 2547 Hz. Performance = 2572. Consumption = 3.084
2 cores at 1267 Hz. Performance = 1267x2 = 2534. Consumption = 0.88
=> Same time to complete task, the 2 cores at lower frequency consume one third of the power!
Example 2: same task, only 1 core.
1 core at 2547 Hz. Performance = 2572. Consumption = 3.084
1 core at 1958 Hz. Performance = 1958. Consumption = 1.75
For the same task, the core at 1958 needs to be ON for 2572/1958 = 1.3 times longer than core at 2547. So it will consume 1.75x1.3 = 2.3
=> the single core at 1958 will take 25-30% longer time but consume 25-30% less battery.
In practice the time taken will be shorter and the battery saving larger than these numbers.
Example 3: same task, only 1 core, different gov
Max freq = 2572
Start freq = 268
Freq scaling steps: 1 ms
1 core straight to 2572: Exxon governor
1 core at 1190 then 1574 then 2265 then 2572: greenpeace governor
=> answers: I have no idea, not calculating this.
- for very quick small tasks, the greenpeace gov might never reach the highest freq, and will consume insanely less power than the Exxon gov.
- for long heavy tasks, they will consume about the same and take about the same time since they will be throttled by the thermal engine.
- for medium tasks, the greenpeace gov will take longer to complete, maybe 20-30%, but consume about 40-50% less battery. This really depends on the governor, most good governors are pretty balanced and will fall somewhere in-between.
Example 4: hotplugs
I won't even get into this, but if you throw-in hotplugs in there the difference between an (aggressive hotplug + Exxon governor) and a (less aggressive hotplug + greenpeace governor) increases significantly to the point where you will actually notice applications taking longer to load, screens not rotating quickly at all, general annoyance at your phone behaving like a nokia vintage 1998.
You also understand why no-one in their right mind will calculate governors and hotplugs configurations for you and tell you which is best.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
MY BIG QUESTION: ACHIEVING THE SAME PERFORMANCE WITH LESS BATTERY DRAIN
For the same expected performance, is it better to have a battery-saving governor + aggressive hotplug or an aggressive governor + battery-saving hotplug?
That's the big question.
We've already established that you should underclock your frequencies, if you didn't get that from everything I said then it's your life anyway, doesn't affect me.
From example 1, we can clearly see that theoretically more cores at lower frequency makes sense, especially since thermal engines will reduce clock speeds for super heavy tasks.
However, when multitasking comes into play as well as ****ty apps/systems not making full use of the fact that there are several cores to choose from, then the answer is not so clear cut.
I have found that for power consumption the hotplug seems to matter much more than the governor, but it could depend heavily on what you use your phone for.
Play around with your kernel, and test with user experience, not benchmarks. For example:
1. a very battery friendly governor with a very battery friendly hotplug, leaving theoretical max freq at 2572 or whatever.
dorimanx: alucard HP + max freq 2.3 + alucard govs
boeffla: zzmove native default HP + max freq 2.5 + zzmove battery extreme yank
2. very aggressive governors & HP:
dorimanx: MSM HP + max freq 2.8 + intelliactive/darkness
boeffla: zzmove native 2 cores min + max freq 2.8 + zzmove insane/intelliactive/ondemand
3. try this: aggressive HP + UC + semi-aggressive governor
dorimanx: MSM HP + max freq 1.7 (for all cores) + darkness/ondemand/impuls
boeffla: zzmove native 2 cores min (or Default HP) + max freq 1.7 + zzmove - performance
Try this even at 1.3 MHz, you might be surprised.
You will start noticing that you can't make the difference between crazy performance settings and more balanced ones, and if you can't tell the difference then for goodness' sake stick to the battery friendly option.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
GPU:
The GPU is a major function of power use and performance, the more screen changes happening (scrolling, gaming, etc), the more it is used.
Controlling the GPU max freq can significantly help reduce battery consumption but will lead to issues with gaming especially (loss of Frames per Second, unresponsive game).
I would recommended underclocking the GPU unless you really need it. If that leads to issues for your daily phone use then scale back min/max frequency to default levels or even overclocking.
More importantly, if you kernel allows (Dorimanx, Boeffla do), then reduce min GPU frequency to 27 MHz. That is a large battery saving feature with no performance impact.
See attached picture for the relationship of power usage of GPU versus frequency. GPU freq index 0 to 3 is low to high frequency.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
UNDERVOLTING:
Just a quick add to show tables of voltage versus frequencies and if you square the voltage times the frequency you will realize how quickly power consumption grows with frequency.
Example voltage versus frequency for Z2 (from here (credits @Haldi4803).
300mhz = 775mV
422mhz = 775mV
652mhz = 775mV
729mhz = 775mV
883mhz = 780mV
960mhz = 790mV
1036mhz = 810mV
1190mhz = 820mV
1267mhz = 850mV
1497mhz = 860mV
1574mhz = 880mV
1728mhz = 915mV
1958mhz = 975mV
2265mhz =1010mV
2457mhz =1010mV
Voltage OnePlusOne (credits @Lord Boeffla, at least that's where I take it from):
300mhz = 770mV
422mhz = 775mV
652mhz = 775mV
729mhz = 775mV
883mhz = 785mV
960mhz = 795mV
1036mhz = 805mV
1190mhz = 825mV
1267mhz = 835mV
1497mhz = 865mV
1574mhz = 875mV
1728mhz = 900mV
1958mhz = 945mV
2265mhz =1005mV
2457mhz =1040mV
2572mhz = 1095mV
2726mhz = 1125mV
2880mhz = 1155mV
**************************************************************************************************************************************************
**************************************************************************************************************************************************
Further Reading:
Qualcomm article on power consumption
Another Qualcomm article on battery & power
Integrated CPU-GPU Power Management for 3D Mobile Games
Wikipedia: Underclocking
An Analysis of Power Consumption in a Smartphone
Utilization-based Power Modeling of Modern Mobile Application Processor
GOVERNORS AND HOTPLUGS
explanations and recommendations
also see next post for a lot more details
If you like reading on kernels and such, there is also this phenomenal thread by Haldi: Haldi's Thread for Z2(credits @Haldi4803)
Governor Descriptions:
I will NOT go through descriptions of all the governors, by far the most complete I have found is this one: Best List of Governors
READ THE LINK ABOVE. It contains a LOT of very good information on governors.
You can find more links in here, and here and here and here.
(credits to authors, I am a bit confused who the authors actually are, lots of reposts).
Many governors listed in the links above are out of date and not optimized for modern quadcore processors, which are a lot better than they used to be (for example, voltage distribution can be different for each core, etc).
BEFORE YOU START, KNOW WHAT ARE CPU INTENSIVE TASKS:
- Heavy gaming (either graphic or AI intensive): you will lose almost 1% battery per minute, nothing you can do about this, but if you use battery saving features your game might lag/stutter.
- Browsing & multitasking (which usually involves browsing)
- Photo/video editing, viewing/zooming/generally playing around with visual multimedia
- GPS
- Long term background usage: your screen, network, apps that sync (facebook, gmail, etc). See in post 5 a few things you can do. But this thread is not about these issues so I won't talk about this.
- video playback, general phone use, etc are NOT heavy tasks
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
What is a governor for Noobs:
performance = how quickly things get done
power consumption = how much battery is used
Let's take a car as analogy. The performance (speed) would be represented by time to 100 kph and time to travel 1 km, for example. Consumption would be total fuel consumed.
The governor sets speed limits on the tracks for various distances to cover as well as how hard to step on the accelerator. This will CONTROL how quickly the car gets to the destination and how much fuel it consumes.
Some governors are battery friendly, they will ramp up the speed slowly and for longer distances but use less fuel.
Some governors are performance driven where they will jump to max speed straight away (I know, a car can't do that, but a phone can), and stay there until you reach the destination.
Some governors are balanced, accelerating more or less quickly to max speed or close to it, consuming more or less fuel.
IMPORTANT: the behavior of governors cannot really be un-linked from the hotplugs. You might find combinations of certain governors/hotplugs make a performance governor more battery friendly for your style of phone usage. See this list as a guideline.
What is a Hotplug for Noobs:
It is also important to talk about the hotplugs (very briefly here): if you imagine the car again, you would say there is NO WAY that you can achieve the same performance AND save fuel at the same time.
Let's have another car analogy: you have 4 lanes and 4 cars. They need to take 100 very heavy pizzas to the destination (let's ignore added friction due to car weight). You can let one car do ALL the work, or spread the load between one to four cars. That's what a hotplug does. Knowing that a car with 50 pizzas consumes a lot less fuel than a car with 100 pizzas you can now see how we can have the same performance and save on fuel: load two cars with 50 pizzas and let them accelerate as quickly as possible to the destination (performance governor). They will get there as quickly as one car with 100 pizzas (=same performance), but burn less fuel (=battery saving).
VERY IMPORTANT: Despite the existence of dedicated hotplugs in new CPU systems, a GOVERNOR can have its OWN hotplugging coding.
All it means is that the codes to switch additional cores ON and OFF is also included in the governor. Not all governors have this. PegasusQ and zzmove do for example. Therefore, if in your kernel those governors come with a dedicated hotplug you should use it.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
GOVERNORS:
This section will simply go through the various options in both kernels and let you know which ones are more or less performance or battery friendly.
Since I don't have all the phones and all the kernels, this might or might not apply to your kernel. However there are many governors that are common to everyone so that helps.
Governors:
Below is a list of the main governors loosely ranked from battery to performance focus:
MORE DETAILS ON A LOT OF THESE GOVERNORS IN THE NEXT POST.
NOTE: the combination with the hotplug is very important. Using a performance governor (that comes down to low freq often, such as ondemandplus or darkness or others, see below) with a battery saving hotplug can have very good balance and battery savings.
Extreme Battery Governors: Don't play heavy games with these
Conservative: anything with that name is very battery friendly and WILL sacrifice on performance, but could be OK for you.
Powersave: anything with that name is very battery friendly and WILL sacrifice on performance, but could be OK for you.
Intelimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor, I am not sure if it is more or then battery saving than Yankactive.
Yankactive: a modified interactive, good for battery save, bad for games. (low FPS).
zzmove extreme battery variants: zzmove governors with "battery extreme", "battery extreme yank", "battery yank" or "battery plus" in the title. "zzmove battery" is probably already in the balanced governors section (with a focus on battery savings).
Balanced Battery Governors:
zzmove battery: focus on battery savings, but not bad on performance, so in the balanced section.
Alucard: a favourite choice of many for battery without losing much performance.
Darkness: alucard that goes very quickly to max freq but does not stay there long. Better for responsiveness and good for battery too.
Balanced Governors:
Nightmare: has the coolest name. A PegasusQ modified, less aggressive and more stable. Good for performance without being battery unfriendly.
zzmove moderate/optimal: made to be balanced, please use with associated hotplug, moderate is an updated version of optimal. A lot of people are very happy with these two governors. zzmove governors ALL have battery saving features for phone idle, so waking up phone can seem more laggy than with other governors, but it saves battery. I find this a good compromise.
Balanced Performance Governors:
OndemandPlus: based on Ondemand and Interactive with modifications to the upscaling codes so it does scale to max freq as quickly, performance reported as very battery friendly in combination with a battery friendly hotplug such as Alucard, so not sure where to rank this one. For pure performance would use something else.
Ondemand (Dorimanx kernel ONLY): very good performance and balance oriented. Used by the man himself (Dorimanx).
Interactive battery variants: some variants of Interactive are more battery focused ("battery" or "extreme battery" in the title, etc) but assume those are balanced governors, probably on the performance side.
Pure Performance Governors:
zzmove performance/game/insane: performance governors, (please with with associated hotplug). "Performance" can be used as a balanced governor as well, depending on your other kernel settings. "Game" is designed to better handle hot phones when heavy gaming. "Insane" is more performing than "performance". Zzmove governors ALL have battery saving features for phone idle, so waking up phone can seem more laggy than with other governors, but it saves battery. I find this a good compromise.
Interactive: the basic android governor that focuses on quick jump to high frequency to please users when they switch on the phone and go straight to doing something on it. Very performance oriented and has a lot of more modern derivatives.
Impulse: based on interactive, more modern, making use of new phone architectures. Probably more efficient than Interactive. Could be better than Intelliactive for newest phones.
Intelliactive: based on interactive. Uses some tricks to save battery without sacrifice of performance. Preferred over Interactive basic.
Ondemand: very performance oriented, no thought to much battery savings. NOT to be confused with "Ondemand" in Dorimanx kernel, that one is more balanced performance oriented, heavily tweaked by one of the best kernel developers ever.
Slim: new governor, very performance oriented, not much thought (if any from what I hear) to battery savings. Use it with a phone with good battery life and performance is your thing. OnePlus One is mentioned as a good phone for this.
Wheatley: based on Ondemand. More modern, probably more efficient (=same performance but better on battery than Ondemand).
Intellidemand: based on Ondemand. Behaviour changes with GPU load, so if GPU load is high it behaves like Ondemand, otherwise tries to save a bit of battery. Use it if you play games for example but don't do only that.
PegasusQ: an old governor based on Ondemand and made for performance. There are probably better newer governors now, but people still report happy use of this one (probably with battery saving hotplugs).
Performance: usually means the cores will stay at maximum frequency. You can't have more performance than this but say goodbye to battery life.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
HOTPLUGS:
Ranked from battery friendly to performance:
It is very hard to "rank" hotplugs, but their combination with governors can make a world of difference, especially when going for a "balanced" approach. What usually works there is to use a battery-performance or pure performance governor with a battery saving hotplug.
Each kernel has their own hotplugs or variations thereof. You will really need to check your own kernels for more information.
Battery Hotplugs:
Alucard HP: very famous, a favourite of all "balanced" (usually in combination with a balanced battery governor to be on the more balanced battery side or with a performance governor to be more on the balanced performance side) or "pure battery" phone styles. Does not switch on cores excessively for low load tasks, but does NOT sacrifice performance much.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max).
Middle of the road Hotplugs:
Default LG HP (Doriamanx kernel ONLY): This is NOT the default LG hotplug, but a heavily tweaked version. Probably a middle of the road hotplug.
MSM HP with battery profiles: (I am only familiar with the Dorimanx implementation). It will switch on more cores very quickly. In Dorimanx kernel, this hotplug can be heavily tweaked to be battery friendly to pure performance. With the right tweaks it is a very good choice for balanced performance.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max).
Default HP: I fail to see how any hotplug called "default" would be anything but a middle of the road hotplug, UNLESS your kernel maker has made their own default kernel hotplug, in which case you should probably use it if recommended for that kernels' main governor or for whatever reasons the kernel maker created that hotplug. Phone manufacturers love to have happy users so it probably will not try and save too much battery and not be too clever either. Pick another hotplug more suited to your needs if you have one available.
Aggressive Hotplugs:
MSM HP: (I am only familiar with the Dorimanx implementation). Hotplug for pure performance. It will switch on more cores very quickly. Very good choice for balanced performance or pure performance styles. In Dorimanx kernel, this hotplug can be heavily tweaked to be battery friendly to pure performance. Recommended if you use the combination of low max frequency and multiple cores online.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max), so will not respond as quickly on phone wake up as other aggressive hotplugs.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
RECOMMENDATIONS:
THE GOLDEN RULE 1: IT ALL DEPENDS ON WHAT YOU USE YOUR PHONE FOR. EVERYONE WILL PREFER DIFFERENT SETTINGS.
THE GOLDEN RULE 2: YOU CAN'T ARGUE ABOUT TASTED AND COLORS AND YOU CAN'T ARGUE ABOUT GOVERNOR AND HOTPLUGS SETTINGS.
My recommendation for you to try, balanced, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1.7/1.5/1.5/1.5 || Governors = Intelliactive/Darkness x3 or Darkness x4 || HP = MSM
- (I have not tested Yankactive/nightmare/ondemand/impulse combinations, feel free).
- GPU: max speed = 389 MHz || min speed = 100 MHz
- MSM hotplug: suspend mode to always active.
- You can set higher frequencies than 1.5, but just try it this way anyway.
Very Battery Friendly :
- CPU: set your max frequency to something much lower than your phone's max frequency (not your kernel's overclocking max frequency). At least 40-50% lower but check if your phone is built for that. For high end phones use 1.3 to 1.5 GHz for example. Increase if you have issues waking up your phone.
- Governors: obviously a battery one.
- HP: obviously a battery one if available. If desperate for battery saving, try to use hotplugs that allow 1 or 2 cores max.
- GPU: underclock your GPU to one step above the minimum; set min GPU to the minimum you can find
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc)
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.
Balanced on the battery-side version 1: everything balanced
- CPU: set your max frequency two to three steps lower than your phone's default max frequency (not your kernel's overclocking max frequency). Depends so much on your phone that you will have to see.
- Governors: use a balanced battery friendly governor.
- HP: use a battery friendly hotplug.
- example: alucard governor with alucard hotplug
- GPU: underclock your GPU to one/two steps below default GPU max; set min GPU to the minimum you can find
- Optional:
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc).
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.
Balanced on the battery-side version 2: battery friendly hotplug and other settings and performance governor
- A lot of people like these settings as phone responsiveness is very good and good battery life. It might not be achievable with all kernels.
- CPU: set your max frequency one to four steps lower than your phone's default max frequency (not your kernel's overclocking max frequency), depending how "balanced" you want this. Depends so much on your phone that you will have to see.
- Governors: use a balanced performance governor or even a performance governor.
- HP: use a battery friendly hotplug or middle of the road if nothing else available.
- Example: ondemandplus/darkness governor with alucard hotplug, or zzmove moderate/optimal/performance governor with zzmove hotplug
- GPU: underclock your GPU to one/two steps below default GPU max (unless you play a lot of heavy games); set min GPU to the minimum you can find.
- Underclocking your GPU will not affect your video playback. Use default or max GPU only if you play games that require it or a lot of web browsing, etc.
- Optional:
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc).
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.
Pure Performance:
- CPU: set your max frequency to phone's default max frequency or overclock if you like (although with modern good phones I really think that is completely unnecessary).
- Governors: use a performance governor, or a high level "balanced performance" governor to save a bit of juice (depends on your other settings).
- HP: use an aggressive hotplug.
- Example: your choice, shouldn't be hard to figure it out.
- GPU: set to default GPU max or overclock if you like; set min GPU to default min frequency (many kernels allow a min GPU at 27 MHz for example, don't use that if you play games, otherwise you can still use it here).
- Additionally you can change: touchboost to higher frequency, CPU gov sample rate to a lower number, etc. Depends on what your kernel lets you do.
- There's probably more settings you can change to boost performance if desired.
GOVERNORS AND HOTPLUGS
Kernel Specific Dorimanx & Boeffla
but this contains useful info for all kernels
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
DORIMANX GOVERNORS AND HOTPLUGS:
Dorimanx Specifics:
Dorimanx kernel has many tweaking options, including the ability to set governor and min/max frequency independantly for each core. This gives a level of tweaking not often seen elsewhere.
Governors:
IMPORTANT: the behavior of governors cannot really be un-linked from the hotplugs. You might find combinations of certain governors/hotplugs make a performance governor more battery friendly for your style of phone usage. See this list as a guideline.
Below is a list of the main governors loosely ranked from battery to performance focus:
Battery Governors:
Conservative: keeps the core frequency at minimum most of the time, very battery friendly but not very clever. Terrible fore performance.
Powersave: keeps the core frequency lowish all the time, very battery friendly but not very clever. Terrible fore performance
Intelimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor, much more battery friendly than Yankactive.
Yankactive: a modified interactive, good for battery save, bad for games. (low FPS).
Balanced - on the battery-side:
Darkness: alucard that goes very quickly to max freq but does not stay there long. Better for responsiveness and good for battery too. Frequently prefered over alucard.
Alucard: very good for battery. Goes slowly to max freq, stays there longer if required.
OndemandPlus: based on Ondemand and Interactive with modifications to the upscaling codes so it does scale to max freq as quickly. It is a performance governor at heart, but reported as very battery friendly in combination with the right hotplug (alucard). I have doubts this is more battery friendly than alucard with an aggressive hotplug (eg: MSM). In summary, will not go as quickly to max freq as ondemand but downscaling is similar.
Balanced - on the performance-side:
Nightmare: has the coolest name. A PegasusQ modified, less aggressive and more stable. Good for performance without being battery unfriendly.
Ondemand: this is the dorimanx ondemand, not the standard one, do not be confused by the name and finding it in the balanced governors. I think his current version is more balanced between performance and battery. The basics of ondemand is to scale freq based on need, so will boost freq if needed much more than alucard will. Probably the most tweaked/up to date governor in this kernel. Seems to prefer staying at medium frequencies rather than scale up and down all the time.
Performance:
Impulse: Impulse governor is based on CAF Interactive but with additions to work smoothly with CPU Boost driver and improved freq stabilization. Based on the fact that this is based on interactive it is a performance governor but probably more battery friendly/efficient. More battery friendly than intelliactive. Probably on par with interactive but probably more efficient as it is newer.
Interactive: the basic android governor, based on pleasing users by very quick response to high freq to reduce lag when switching phone on and expecting user will interact with phone quickly (launch app, etc). This governor does come back to low frequencies quickly and therefore more battery friendly than intelliactive.
PegasusQ: an old governor for dual cores. The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. See governor link at beginning of post to find out more. It is a good governor but old, more efficient governors exist now, however, some people report good results with this. It is very performance driven, just like Ondemand, probably not many battery saving features other than better handling of loads through hotplug and its own queuing techniques.
Intelliactive: a better version of the interactive governor which is an ondemand on steroids, it will boost up very quickly on need but will stay there on timer. Freq will not fluctuate as much as ondemand. It is not a battery killer either because it is not a stupid governor, it will use other tricks to save battery. This governor was designed for quick user responsiveness, and is therefore one of the best "lag-free" governors. Seems to stay at medium frequencies when tasks are needed and not scale down to low frequencies until full rest. More battery friendly than intellidemand.
Intellidemand: based on Ondemand, so a performance governor. Its behavior is linked to GPU, if active GPU (games, etc) then it behaves like Ondemand. When GPU is inactive it will scale max freq differently to save on battery.
Performance: keeps the cores at max frequency. Obviously the best for performance and the absolute worst for battery. Good governor for running benchmarks if you want to study power consumption, etc as it is independent of hotplugs and everything else.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
Hotplugs:
The hotplug will change the performance/battery savings of your governor combinations. But in general, it will compound the differences:
- a battery friendly hotplug with a battery friendly governor will be very battery friendly
- an aggressive hotplug with a performance governor will have very good performance and poor battery
- it gets interesting with other combinations to achieve balance: a battery friendly hotplug and a performance governor (eg: alucard HP + ondemandplus) can give very good balance.
NOTE FOR DORIMANX KERNEL: since you can set your governors independently for each core, make sure you understand how the hotplug works. For example, alucard seems to switch on core 1 then core 2 then core 3 when needed but MSM seems to go to core 3 or core 2 first. So if you want to combine performance and battery governors in your setup make sure you select the right cores to do so based on your hotplug.
Ranked from battery friendly to performance:
Alucard HP: The most battery friendly, does not switch on cores excessively for low load tasks, but does NOT sacrifice performance much. A lot of users use this HP.
Default LG HP: This is NOT the default LG hotplug, but a heavily tweaked version.
MSM HP: The basic hotplug for pure performance. It will switch on more cores very quickly.
Intelligent HP: another good hotplug aggressive but seema to work well, a good alternative to MSM.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
Recommendations:
There are so many things you can tweak in this kernel that everyone has their own versions of what they consider "best". I can't post everyone's suggestions.
Dorimanx himself: uses "performance" profile in STweaks. That's it, no other tweaks. It is a performance focused balanced setup.
My recommendation for you to try, balanced, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1.7/1.5/1.5/1.5 || Governors = Intelliactive/Darkness x3 or Darkness x4 || HP = MSM or Intelligent HP if MSM drains too much battery
- (I have not tested Yankactive/nightmare/ondemand/impulse combinations, feel free).
- GPU: max speed = 389 MHz || min speed = 100 MHz
- MSM hotplug: suspend mode to always active.
- You can set higher frequencies than 1.5, but just try it this way anyway.
Battery friendly : set "battery" or "extreme battery" profile. Max freq = Alucard or Intelimm or yankactive || HP = Alucard
- GPU: max speed = 70,000)
- Keep "max screen off cpu freq" to 1.7 or higher for stability.
- CRON OFF (disabled)
- Sweep2sleep OFF
Balanced on the battery-side:
- Set profile to "default". Max freq = Darkness or Nightmare or OndemandPlus || HP = Alucard (preferred) or Default LG
- GPU: max speed = 2.3 || Governors >= Ondemand or OndemandPlus or Interactive or Impulse or Intelliactive || HP = alucard or intelligent for more performance
- GPU: max speed >= 450 MHz || min speed = 100 MHz
- Additional tweaks: decrease sample rate.
Performance: Just use "performance" or "extreme performance" profile. Max freq >= 2.5 || Governors >= Interactive or Intelliactive or Impulse or Intellidemand || HP = MSM or intelligent for better battery
- GPU: max speed >= 533 MHz || min speed = 200 MHz
- There are a lot of tweaks you can do to make it even faster:
- Important tweaks: decrease sample rate, play around with MSM Hotplug controls (descriptions in STweaks)
- Other tweaks: touchboost, powersave switch to performance, disable power-efficient workqueues.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
BOEFFLA GOVERNORS AND HOTPLUGS:
Governors:
Below is a list of the main governors loosely ranked from battery to performance focus:
NOTE: all governor parameters are tunable in boeffla pro version, so you can change how each governor behaves, only use of you really know what you are doing.
I will start with zzmove because it has the whole range of governor options to select from. They are pretty self explanatory.
Zzmove: Some idle/suspend battery saving features and many performance features in conjunction with its associated hotplug, large focus on "suspended" battery saving. There are many zzmove configurations pre-set in Boeffla kernel. From ZaneZam himself: "Basically this is the ported SGS1 version of the well known "smoove" governor from the good old midnight kernel from Michael Weingaertner (mialwe) with a modified CPU hotplug implementation of the ktoonservative governor from ktoonesz. The original implementation from ktoonesz worked well but I observed that on idle most of the time only one cpu was going to sleep. Well that was not enough for me so I made a modification to put the other cpu's also to sleep (except cpu0). That means that this governor uses more often only one cpu on idle and as a consequence of that it needs less energy. Depending on System load and governor settings all 4 cores will be instantly up again if it is needed." More details here.
IF YOU USE ZZMOVE GOVERNORS IT IS BEST TO ALSO USE ZZMOVE NATIVE HOTLUG.
Battery Governors:
Zzmove battery extreme yank
Zzmove battery yank
Intellimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor. Difficult to know exactly where it stands with respect to all the zzmove battery governors, but probably on par with battery or yank.
Zzmove battery plus this could be even more battery saving than the other zzmove battery governors, but this is based on a very short test, so could be wrong.
Interactive battery extreme: it is actually very hard to rank all these battery governors, please just see this as a very loosely ranked list, not a tested ranking.
Smartmax: battery oriented but still based on Ondemand with a mix of smartass2, however it seems to be very battery oriented with very slow scaling (?). More details here.
Zzmove battery: the more performing of the battery governors, getting to the grey area between battery and balanced governors.
Balanced Governors:
Interactive battery extreme: despite the title I am pretty sure this one has tipped into the balanced governors, but really on the edge.
Interactive battery: same as above, but more balanced. I would pick zzmove moderate
Zzmove moderate: an updated version of optimal, uses 2 cores most of the time, very good performance and battery saving balance. This and zzmove optimal are preferred choices for most balanced users (that's most of you too) of Boeffla.
Zzmove optimal: good balance governor, needs zzmove native HP for best effect. But see zzmove moderate, a more updated version of this. This one seems to go through more scaling steps. You probably won't see a difference between this an moderate, though. I still don't know which one I would pick.
Performance Governors:
Intelliactive: a better version of the interactive governor which is an ondemand on steroids, it will boost up very quickly on need but will stay there on timer. Freq will not fluctuate as much as ondemand. It is not a battery killer either because it is not a stupid governor, it will use other tricks to save battery. This governor was designed for quick user responsiveness, and is therefore one of the best "lag-free" governors. I would pick this over intellidemand or interactive performance for example, but I am not a game player.
Interactive performance: the basic android governor, based on pleasing users by very quick response to high freq to reduce lag when switching phone on and expecting user will interact with phone quickly (launch app, etc). Obviously performance but seems to use low frequencies more than other performance governors listed below.
Interactive standard : performance oriented, jumps quickly to high frequencies, no much coming back/staying at min freq, but more so that Interactive Performance. Depending on your style of phoning select this one or the interactive performance.
Zzmove performance: aggressive and very high performance governor, but will save battery when inactive compared to other performance governors. Please use zzmove native hotplug of course. I would pick this over intellidemand, interactive standard/performance. I would also probably pick this over slim/wheatley/etc.
Zzmove game: choose this one if you play heavy games. High performance but helps reduce cpu heat during gameplay, which helps save your cpus (thermal engines WILL lower your cpu frequencies when hot, so super heavy performance governors set at 2.5 GHz will NOT be at 2.5 GHz when you're playing).
Intellidemand: Based on Ondemand, so a performance governor. Its behavior is linked to GPU, if active GPU (games, etc) then it behaves like Ondemand. When GPU is inactive it will scale max freq differently to save on battery. try it if you use heavy games a lot, make sure you set your GPU highish.
Interactive performance: very high performance, jumps quickly to high frequencies, no much coming back/staying at min freq.
Zzmove insane: focused on very high performance, probably on par with all the ones this far down in the list. Probably better if used in combination with zzmove hotplug, it probably is much better at saving a little bit of battery when phone idle/suspended/screen ON but not doing much.
Slim: Very performance oriented, no battery saving features at all. A new governor from the cm branch and the slimrom project. A performance optimized governor. Found on newer devices only such as the One Plus One. This CPU governor will fall back to be the performance governor if very high load is detected.
Wheatley: Based on Ondemand, so a performance governor. It simply increases C4 state time of the CPU to save on battery. Might be more battery friendly than slim, but hard to say, these are not designed with battery in mind, just efficiency. Slim is more modern (I think) so would be a better choice in my opinion, but I have really tested them.
Ondemand: 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. But it is not very efficient for performance and certainly pretty bad for battery. Frequency variations are very large. Seems to lie somewhere between interactive standard and performance but you would probably not really notice the difference. I am putting it here because it has less battery savings and modern performance features than its derivatives (slim, wheatley).
Performance: keeps the cores at max frequency. Obviously the best for performance and the absolute worst for battery. Good governor for running benchmarks if you want to study power consumption, etc as it is independent of hotplugs and everything else.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
Hotplugs:
Boeffla kernel does not have a large array of hotplugs, but zzmove native hotplug is a great combination with zzmove governors, it will help focus the behaviors of those governors to what they were intended to do. So choose that one if you have a zzmove governor.
Optimized: focuses primarily on battery saving rather than performance, with 1 core max on suspend state (most of the time), but this is NOT a battery saving hotplug, just the more battery saving one here. Could be an alternative to zzmove native hotplug for zzmove battery oriented governors (try and see). Pick this one if you want a battery or balanced lifestyle and are not using zzmove governors.
Default: a balanced hotplug almost by definition. Use this one for performance lifestyles (or balanced with performance focus) if you are not using zzmove governors.
zzmove native: If you use zzmove governors, use this hotplug, it is built to work in conjunction with the governors and will have both performance and battery savings features based on your choice of zzmove governor (however, if you use zzmove battery governors you might want to try optimized hotplug and compare). It is an aggressive hotplug, enables fast scaling of multiple cores for heavy loads but also focus on suspended state battery saving (1 core max). It will save more battery
X core min/max/exact: these hotplugs simply set the minimum, maximum or the exact number of cores active. Of course 1 core only is very battery friendly and 4 cores is very bad for your battery and great for performance. Play around with these if you wish, they are good for running benchmarks when setting the exact number of cores you want to test.
*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************
Recommendations:
- There is a dedicated thread HERE.
- Boeffla himself: does not use a single setup but varies it. More common would be Interactive gov, max cpu 1,947, noop scheduler, touboost 1294, GPU max 330 MHz.
My recommendation for you to try, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1497 MHz || Governors = zzmove performance || HP = zzmove native default
- (I have not tested other similar combinations, feel free and let me know).
- GPU: max speed = 389 MHz || min speed = 27 MHz
- touchboost OFF
- You can set higher frequencies than 1.5, but just try it this way anyway.
Battery Extreme: example from here. Credit @raybit10. CM12 ROM, but should apply to CM11S.
- Max freq = 1,574 || Governors = zzmove battery extreme yank || HP = zzmove native default
- GPU: max speed = 200 MHz || min speed = 27 MHz
- Additionally: Scheduler Zen, readahead 1408, touchboost 1036 MHz, Swipe screen to wake ON, Android logger OFF
- Disable all animations or you will get stuttering, lack of smoothness.
- BEWARE: undervolting light. ONLY APPLY UNDERVOLTING IF YOU KNOW WHAT YOU ARE DOING.
- 10-12 hours SOT achieved with tasker, greenify, massive de-bloating of unused apps.
Battery friendly : Max freq = zzmove battery plus/yank/extreme yank or intellimm or smartmax || HP = zzmove native default or optimized
- GPU: max speed = 578 MHz || min speed = 200 MHz
- Additional tweaks: increase sample rate, touchboost freq
GOVERNORS AND HOTPLUGS - SOME VISUALSAnd discussions
I ran combinations of governors (and some hotplugs) in Vellamo benchmarking tool in an uncontrolled test, purely for comparative purposes, using the "single core" test.
Uncontrolled means the tests were not carried out in the exact same situation each time, this happens mostly because cores heat up during tests and if you do not wait long enough then next test will not be under similar conditions. Also, in between test (or even during) some apps might have started, some RAM be used, and many more things could have changed.
I do not exactly how Vellamo chooses to represent the cpu usage in its "single core" tests, as there are obvious influences of hotplugs and other things.
All that being said, these tests are probably not reproducible exactly by other people, but I would suggest you do your own tests with your kernel to find out more about your various governors, hotplugs and combinations thereof.
I DON'T CARE ABOUT THE SCORE ITSELF! If you control your tests more you might look into some of the score details (example: I/O, etc) and learn something, I did NOT do that.
However, I found the following very useful in visualizing governors and hotplugs.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
GOVERNORS (based on BOEFFLA):
Setup:
- governor: as per name indicates
- hotplug: zzmove native default
- cpu max: 2.8 GHz
Just for reference:
- I/O scheduler: FIOPS
- GPU: 389 MHz
How to read the graphs:
They simply represent 6 different tests that Vellamo carries out in this benchmark. For each, they represent time in state for various cpu clocks, adding all cpus together.
I don't think the large dots are to scale, by that I mean that once they are a certain size they cannot get bigger, so a large dot at min frequency might not mean the same time spent as the same size large dot at max frequency. I just don't know.
So the way I read them is as follows: (again, this is how I read them, if you have other ideas please let me know.
- IMPORTANT: remember that using different hotplugs will change these graphs behaviors (I checked), so please use these comparatively only for your own set ups.
- look for large dots at low frequencies: the more there are, the more battery friendly the governor, even if there are a lot of large dots at max frequency.
- look for dots between min and max frequency: the more there are the more the governor uses all available frequencies steps. This usually means it is less aggressive and would be good for balanced styles with the phone doing a lot of small tasks (playing around with your phone). If a governor does NOT have a lot of small dots between min/max frequencies then it is very aggressive in going to max and can be very good as a balanced style using "performance governor" + "battery hotplug" and underclocked CPUs.
- look for large dots at max frequency: do not be fooled by large dots at max just below highest frequency, that's an artifact of the uncontrolled tests where the cores were probably a bit hotter to start with. Anyway, the more large dots at the top, the more performance driven the governor is of course. But you have to look at the dots at min frequency and the dots in between min/max to really judge a governor as pure performance as most governors will have large dots at the max frequency.
You can easily pick out the Battery versus the Pure Performance governors
Look at intellimm versus Interactive Performance for example.
In alphabetical order.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
"MULTICORE" TESTS FOR HOTPLUGS (based on BOEFFLA):
Setup:
- governor: zzmove battery and zzmove moderate
- hotplug: as per name
- cpu max: 2.8 GHz
Just for reference:
- I/O scheduler: FIOPS
- GPU: 389 MHz
These are the "multicore tests" from Vellamo. They take longer to run so I only did a few. For this one I varied the hotplugs to see the effect.
This test is much more susceptible to the fact this is an uncontrolled test (it runs longer, the cores are hotter, leading to even less similar conditions at each test).
As you can see the effect of the hotplug varies with the governor.
RESULTS:
- zzmove moderate: I believe these show for zzmove moderate that the zzmove hotplug brings out the desired performance factor more than the other hotplugs and seem to make it use intermediate frequencies more. Maybe.
I would rank the hotplugs as optimized/default making the governor more battery friendly (as expected, and also not much difference between the two).
The zzmove native hotplug does it more performance oriented, as expected also.
- zzmove battery: the default HP makes it more battery friendly, BUT THIS IS A SHORT TEST! Don't be fooled. The optimized HP is probably more battery friendly in the long run due to its idle/suspend characteristics (1 core max most of the time). The zzmove native hotplug seems to make it less battery friendly, but probably not by much (my interpretation), but once again this is as expected.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
GOVERNORS (based on DORIMANX):
See above section for details on the runs and plots.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
"SINGLE CORE TESTS FOR GOVERNORS (based on DORIMANX):
If not otherwise noted, hotplug is "Default LG"
COMPARISONS
2 CORES HIGH FREQUENCY (2.88 GHz)
VS
4 CORES LOW FREQUENCY (1.5 GHz)Similar Performance, Lower Power Consumption
**************************************************************************************************************************************************
**************************************************************************************************************************************************
SETUP:
Running the great app trepn from qualcomm to monitor power and core frequencies.
For each case:
1. Monitor System with trepn
2. Launch PCMark and run "Work Benchmark"
3. When done, go to Vellamo and run "Multicore" benchmark
4. When done, end System Monitoring with trepn
5. Also for each case run a baseline power consumption (trepn does consume a lot of power): run system monitor and do nothing on the phone. This enables taking out trepn for comparison.
Caveat: I didn't have time to run these in perfect controlled manner. Some heating issues could have come in, some extracurricular apps been launched in the meantime, and some timing issues since I did this by hand.
However, I did wait about 2 hours between runs, and the tests being about 10 minutes removes some of the timing issues.
**************************************************************************************************************************************************
**************************************************************************************************************************************************
Case 1 - 2 Cores at High Frequency:
Setup:
- OnePlus One running Boeffla kernel
- Intelliactive governor
- CPU max frequency: 2.8 GHz
- GPU max frequency: 462 MHz
- Hotplug: "2 cores exact" this also means that cores do NOT go to idle when done with their tasks
Results:
The first graph below show the frequencies for each core during the entire test. As expected 2 cores are never switched on. The other 2 follow the exact same scaling and load (pretty much).
The Second graph shows TOTAL frequency on the left with time (I just added them up) and power on the right as well as cumulative power.
TOTALS:
- Time: 584 seconds
- Power: 14.24748 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 20,001,424,800 (approximate assumption that each data point happens at regular interval, makes life easier)
TOTALS for baseline:
- Time: 316 seconds
- Power: 4.202236(approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 5,183,685,600 (approximate assumption that each data point happens at regular interval, makes life easier)
- Power to subtract for 584 seconds of trepn: 7.766
- Clock Frequencies to subtract for 584 seconds of trepn: 9,579,975,919
- Baseline power consumption per clock: 0.81
- Baseline power consumption per second: 0.0133
=> TOTAL NET POWER CONSUMPTION: 6.48
=> TOTAL NET CLOCK CYCLES: 10.4
=> POWER per clock cycle: 0.623
FULL RUN:
BASELINE:
**************************************************************************************************************************************************
**************************************************************************************************************************************************
Case 2 - 4 Cores at Low Frequency:
Setup:
- OnePlus One running Boeffla kernel
- Intelliactive governor
- CPU max frequency: 1.497 GHz
- GPU max frequency: 462 MHz
- Hotplug: "4 cores min" this also means that cores do NOT go to idle when done with their tasks
Results:
The first graph below show the frequencies for each core during the entire test. As expected 4 cores are always online, no idle core.
core1 seems to have a weird result of going up to 2.5 GHz. Not sure what happened there. graphs from PCMARK and Vellamo do NOT show this.
The Second graph shows TOTAL frequency on the left with time (I just added them up) and power on the right as well as cumulative power.
TOTALS:
- Time: 624 seconds
- Power: 12.45498 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 23,214,439,200 (approximate assumption that each data point happens at regular interval, makes life easier)
TOTALS for baseline:
- Time: 311 seconds
- Power: 3.90047 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 7,385,724,000 (approximate assumption that each data point happens at regular interval, makes life easier)
- Power to subtract for 624 seconds of trepn: 7.826
- Clock Frequencies to subtract for 624 seconds of trepn: 14,818,944,617
- Baseline power consumption per clock: 0.53
- Baseline power consumption per second: 0.01254
=> TOTAL NET POWER CONSUMPTION: 4.629
=> TOTAL NET CLOCK CYCLES: 8.39
=> POWER per clock cycle: 0.552
FULL RUN:
BASELINE:
**************************************************************************************************************************************************
**************************************************************************************************************************************************
Conclusions:
Baselines:
- Difficult to compare since anything could have been happening to the phone while this was carried out (emails, syncing, etc).
- However, 2 cores at 2.8 GHz show higher consumption. Since is true: 2 cores were idle at 0 whereas the 4 cores baseline had all cores switched ON. Allowing cores to go back to idle would have favoured the 4 cores case and the difference in power consumed would have been greater.
- I could remove all 300 MHz frequencies and redo everything but I won't, don't have time.
Power consumption:
- I will assume that each run performed the exact same tasks.
- Without removing baselines, the 4 cores at low frequency consumed 13% less power
- Removing baselines, the 4 cores at low frequency consumed 30% less power
- However, the 4 cores at low frequency took 7% longer to achieve the task
It would be great if some of you could test this in your own setups for daily life! And let me know how it goes.
BATTERY SAVING TIPS AND SMOOTHNESS TIPS
RULE NUMBER 1: There are no miracles when it comes to this. It is always a compromise, on performance for battery savings, and on animation and beauty for smoothness/lag-free.
RULE NUMBER 1b: However, I believe there are ways to achieve the same performance with less battery consumption.
RULE NUMBER 2: If you play intensive games (either AI or graphic intensive), expect 1% battery drain per minute.
RULE NUMBER 3: There is not much you can do about RULE No 2. You either have a longer game (AI takes longer to respond) or worse visual experience (lower Frames Per Second).
See attached picture of relative power consumptions of various aspects of the phone in idle (on, but no apps running) and suspended (off).
Screen and network are the worst offenders as everyone knows.
However, this is without apps running. Depending on what you use your phone for your battery life will vary greatly.
Battery unfriendly tasks:
- intensive gaming (either graphic intensive or AI intensive).
- photo/video taking, editing, viewing (ie: looking at your photos, zooming, scrolling, panning, etc). However, watching videos is NOT a very intensive activity.
- internet browsing, especially with 20,000 tabs open.
- downloading, syncing (folder sync, utorrent, etc).
************************************************************************************************************************************************
************************************************************************************************************************************************
SMOOTHNESS AND LAG-FREE:
If you want a lag-free experience, the most important aspect apart from CPUs and GPU is to remove the useless extras, but with the machines we have (G2, OPO) you can actually have it all!
Home Screen:
- Home screen lag: avoid using the default launchers (LG default or OPO Trebuchet). These are horrible, lack customization and are much worse than the good launchers out there. Default launchers are terrible. Some launchers such as themer use very large widgets and can have some lag.
- Animations: remove completely, or reduce animation speeds in "Settings => developer options => animation scale". You can also usually reduce/remove animations in your launcher's settings (apex, nova, buzz, etc).
- Xposed framework: avoid using theme related hacks, statusbar/navbar, etc. It is more battery and performance friendly to simply apply a MOD, but it is more of pain to do so.
- Theming engines: the CM theming engine is fantastic, I use it extensively. However, you will notice improved home screen performance if you simply have the default theme.
Applications Launching and Loading:
- See the rest of this thread.
- Use a good kernel, they include re-written drivers/code that will make your machine better.
- Use aggressive governors that scale quickly to max freq.
- Use touchboost options in your kernel.
- Use 2 cores minimum for your hotplug, this is the least battery-friendly option.
************************************************************************************************************************************************
************************************************************************************************************************************************
BATTERY SAVING TIPS:
You will find ten million pages on this on the internet. I will not repeast what you can find in under 1 minute using google.
Screen brightness:
The biggest culprit is of course your screen. The power consummed by the screen raises quickly with brightness, it is close to linear in theory, but in practice I do not believe that brightness % is a linear scale on the phones, your brightness slider does NOT cover the whole range, your hardware CANNOT cover true black to true white, etc. See below for how some phones take care of low level brightness.
See attached picture of brightness vs power usage. A phone brightness slider will not cover the whole range.
Reduce your brightness setting to something useable (no point destroying your eyes to save battery), you'd be surprised that 50-70% brightness works very well (for LG G2). It depends on your machine, your eyes and what you do with it. For OPO there is no brightness %, mine is almost a third to the left and brightness is perfectly fine. The OPO also has a very good Auto-Brightness engine.
However, turning your screen brightness to a very low level does not necessarily reduce power consumption. The hardware (LEDs, whatever) cannot produce light levels that are so low and the phone will simply display a more or less dark grey layer over the screen to reduce the brightness. That does not reduce power consumption AT ALL. It doens't mean they're useless settings, they are still useful at night for example to reduce eye strain.
Some machines have very good "auto-brightness" engines, others have crappy ones. Try them if you want.
You can play around with your phone's brightness and take screenshots of a black/white picture then use a photo editor app to see what the color is of the white that is now grey. Use the 00 (black) to FF (white) as a scale and use that to see how much % reduction. See if that matches your brightness level percentage reduction.
Network settings:
The network, wifi or LTE or GSM, will also use a lot of power in idle (ON, but no apps running) or suspended state (OFF).
- The signal quality is the most important part of this. If you are on the edge of a wifi network your phone will drain battery quite quickly trying to maintain a connection.
- Airplane mode can help if you don't need a connection.
- Move closer to a tower.
- Switch off wifi when you are out and about.
- Play around with your TCP NET CONGESTION settings, but that will probably not do much.
Kernel settings:
- UNDERCLOCK!!!!!!!! You don't need that 2.8 megagigacrazyhertz.
- Also underclock your GPU, unless you play stupidly intensive graphic games, especially the min frequency. Your video playback will NOT be affected if you underclock your max GPU frequency, but you might have more lag in forward/reverse scanning.
- GAMING: have a charger nearby. But also play with kernel settings, there should be a level at which you can have decent FPS with some power consumption reduction. Here I would actually recommend some benchmarking tools to test your FPS for various kernel settings, as that would be close to your real world user experience.
Greenify:
Use it.
Task killer apps:
Use the automated killing features if you want, nothing wrong with that. Does create wakelocks on idle, but probably saves more battery in the end. I never measured.
It might even save on wakelocks by killing apps that didn't die properly and are still waiting for something and keeping your phone awake.
************************************************************************************************************************************************
************************************************************************************************************************************************
Further Reading:
There are about ten million pages dedicated to this on google.
For Dorimanx users, (but also some good tips for others): The Dorimanx Q&A thread in general, tehbigbug write this.
For Boeffla users, it is of course very useful to read the main thread and linked FAQs.
TCP NET CONGESTION
A very quick description of some TCP net congestion algorithms and especially how to find out which one works for you.
TCP Congestion Avoidance Algorithms:
You can find more detailed descriptions here for example, or here.
(Credits: richteralan, other linked in his/her post)
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Taho, but.. if 3 of the same packets are received, it will halve the window, instead of reducing it to one MSS. It changes the slow start threshold equal to that of the congestion window.
Vegas:
One of the smoothest (next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date."
**********************************************************************************************************************************************************
**********************************************************************************************************************************************************
WHICH ONE TO USE?
It all depends on your local network situation. It might vary from your home to your local jail or work place.
Only one way to find out: test your internet speeds.
Credits: Dorimanx:
"you need to run net speed tests with each protocol at least 3 times to compare the average, and use best performing protocol for YOUR network."
Don't be surprised if you end up using CUBIC or WESTWOOD.
I/O SCHEDULER
I don't actually know much about this, so will just repeat what I see elsewhere. However, all tests I have done were not as conclusive as I would have hope.
This will not change your life. Don't expect I/O scheduler to have any drastic effect on your phone experience unless you've been using a crappy one.
*************************************************************************************************************************************************************
*************************************************************************************************************************************************************
SUMMARY:
ROW vs FIOPS:
FIOPS is better performance and battery but not for multitasking.
ROW is a very good balanced scheduler.
THERE ARE OTHER OPTIONS, see below.
What matters:
- external SD card or not
- multitasking or not
- whether you care about battery life or not
- your machine
*************************************************************************************************************************************************************
*************************************************************************************************************************************************************
WHICH ONE TO SELECT?
I will link to someone else's work:
http://androidmodguide.blogspot.co.uk/p/io-schedulers.html
credit to the author, who I am sure is lurking around here in xda.
Please read his article.
Results (again, not mine):
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Third choice)
- Deadline (Forth choice)
- ROW (My second choice)
- ZEN
For battery life:
- SIO (First choice)
- FIOPS
- NOOP (Second choice)
- ROW (Third choice)
- FIFO
For gaming:
- Deadline (First choice)
- CFQ (Second choice)
- ROW (Third choice)
For performance(Benchmarking):
- VR
- SIO (Third Choice)
- Deadline (Second choice)
- FIOPS (First choice)
For multitasking:
- BFQ (Third choice)
- Deadline (Second choice)
- CFQ (First choice)
IO Scheduler Comparison:
Overall performance:
BestWorst
FIOPS> Noop > ZEN >SIOplus > SIO > ROW > Tripndroid > VR > Deadline > BFQ > CFQ
Multitasking performance:
Less AppsMany Apps
Noop < FIOPS < SIO < SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < CFQ < BFQ
Battery life:
Best Worst
Noop > FIOPS > SIOplus > SIO > ROW> ZEN > Tripndroid > Deadline > VR > CFQ > BFQ
*************************************************************************************************************************************************************
*************************************************************************************************************************************************************
Read-ahead:
http://andrux-and-me.blogspot.fr/2014/06/various-conditions-and-io-performance.html
The usual answers I see seem to indicate that you should leave at default, whatever your kernel maker seems to think is best.
Having too high a number can lead to issues if the I/O needs to read/write a lot of things on the fly with streaming going on and multitasking.
*************************************************************************************************************************************************************
*************************************************************************************************************************************************************
Further Reading:
If you use google you will easily find a lot of material on I/O schedulers.
Here is a page with some descriptions and advantages/disadvantages: http://tinzdroid.blogspot.co.uk/2012/07/android-kernel-governors-modules-io.html
Another link: http://androidmodguide.blogspot.co.uk/p/io-schedulers.html
UPGRADE/DOWNGRADE bootloaders/recovery/kernels and flash ROMs
THIS GUIDE WAS WRITTEN FOR DORIMANX KERNEL AND LG G2, BUT THE STEPS SHOULD BE THE SAME FOR ALL.
JUST MAKE SURE YOU USE THE RIGHT FILES FOR YOUR DEVICE!!!!!!!!!!!
I WILL REPEAT: MAKE SURE YOU USE THE RIGHT FILES FOR YOUR SPECIFIC PHONE!!
Files for LG G2: http://www.dorimanx.com/LG/
NOTE: This is for D802, if you have another variant just substitute "flash KK bootloader" or "flash JB bootloader" with the following (from OP):
"I have created ONE flash zip with all that needed for D802, including stock stuff from 20D KDZ image.
find for your model, extract needed partitions as in my zip, replace and flash.
too hard??? leave it alone and keep using JB bootloader till you find mind power to do it".
This means: download the D802 KK bootloader flash file, download your model's kdz, extract the files needed (same as in the D802 KK booloader flashfile), replace them in the zip and flash or install everything manually.
Same for JB bootloader zip file.
If you are reading this then you know how to do this. If not then just stick to JB or buy a D802.
IMPORTANT: if you do NOT know how to unbrick a phone through download mode and installing custom KDZ and all the rest of it then please don't blame anyone. There are threads in xda for un-bricking.
************************************************************************************************************
First I repeat the steps for installing BUMPED KK bootloader:
Phone status: non-bumped recovery, non-bumped kernel, JB bootloader, stock-based ROM
You want to: install KK bootloader
1) reboot to recovery
2) flash bumped TWRP 2.8.1.1
3) reboot to recovery
4) flash Dorimanx 9.1 kernel
5) flash KK bootloader
6) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************
IMPORTANT: After you have installed BUMPED TWRP, you NEVER need to replace it with non-BUMPED version. It works with JB bootloader too.
************************************************************************************************************
Installing a new/different stock-based JB ROM (or dirty flash or clean flash existing ROM) but want to keep KK bootloader:
Phone status: Bumped recovery, bumped kernel , KK bootloader , stock-based ROM (ie: you just did all the steps above)
1) reboot to recovery
2) flash stock-based JB ROM as per OP (inc wipes if necessary)
3) flash BUMPED dorimanx 9.1 kernel BEFORE REBOOT TO SYSTEM
4) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************
************************************************************************************************************
Returning to JB bootloader with your current ROM:
Phone status: Bumped recovery, Bumped kernel, KK bootloader , stock-based ROM
1) reboot to recovery
2) flash JB bootloader
3) reboot to system
You now have: bumped recovery, bumped kernel, JB bootloader, same ROM as before
************************************************************************************************************
************************************************************************************************************
Installing JB AOSP ROM (with non-bumped kernel):
Phone status: Bumped recovery, Bumped kernel, KK bootloader , stock-based ROM
1) reboot to recovery
2) flash JB bootloader
3) flash JB AOSP ROM as per OP (inc wipes if necessary)
4) reboot to system
You now have: bumped recovery, non-bumped kernel, JB bootloader, AOSP ROM
************************************************************************************************************
************************************************************************************************************
Installing stock-based JB ROM and go to KK bootloader from AOSP ROM:
Phone status: Bumped recovery, non-bumped kernel , JB bootloader , ANY ROM
1) reboot to recovery
2) flash stock-based JB ROM as per OP (inc wipes if necessary)
3) reboot to system
4) install ROM, let it settle for 5 minutes
5) reboot to recovery
6) flash BUMPED dorimanx 9.1 kernel
7) flash KK bootloader
8) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************
PS: thanks to vpro97 for checking and Dorimanx of course for making all this happen
BENCHMARKS
Please don't. Nobody intelligent gives a crap.
"Benchmarking:
The next possible answer for measuring CPU speed and overall system performance is benchmarking.
Unfortunately, benchmarks are necessarily flawed. A benchmark can only prove how quickly a system runs the benchmark. A benchmark cannot show how quickly a system will run a user’s mix of applications in the real world."
(http://www.tech-faq.com/cpu-speed.html)
"With that said, synthetic benchmarks by definition are not real-world applications and they can be misleading and abused. It is ideal to test applications that represent end user experience".
(qualcomm.com/power-versus-performance-management-cpu)
Benchmarks have their uses in comparative studies under same conditions, but they will not tell you anything about how to setup your governors/hotplugs/frequencies.
Example of the proper use of a benchmarking tool (antutu, and you won't see a single score): http://www.bu.edu/peaclab/files/2014/06/Cotler-RISE-Poster.pdf
The best end-user experience benchmark is yourself. If you can't tell the difference in day to day use then why bother with more battery consumption?
If you want to test the thermal engines, undervolting reliability (please don't undervolt), use something like "stability test". You won't get a score to post on facebook but you will actually learn something useful.
******************************************************************************************************************************************************
******************************************************************************************************************************************************
If you insist:
Settings for facebook-friendly benchmark scores:
1. your thermal engine is your worst friend. Disable it/increase limit and destroy your cpus, or (SERIOUSLY) run your benchmark with the phone in the freezer/fridge (leave it there a couple minutes before starting, maybe use a ziplock bag so it doesn't get wet). BUT DON'T FORGET TO NOT BLAME ME FOR ANYTHING THAT HAPPENS TO YOUR PHONE.
Note: I never ran my phone in freezer, but have done many times in the fridge when doing TWRP backups or flashing ROMs to speed up the process and avoid overheating/pixel destruction.
2. set a hotplug with ALL CORES ONLINE all the time. Like "4 cores min".
3. set the governors to "performance", this usually sets the cpus at their max frequencies forever.
4. set the max frequency to the highest possible frequency.
5. don't forget the GPU, this is a big score for antutu and others. Set min GPU to the max possible allowable for your kernel and the max GPU to the max possible.
6. DON'T kill all the tasks before you start a test, the phone will be busy restarting them. If you want to kill tasks, then please do but then wait a few minutes before doing your test. Same if you reboot, wait several minutes after reboot to start your test.
7. And then don't forget to NOT BLAME ME.
COOL TOOL custom labels GPU freq, CPU temp, CPU 1/2/3 on/off stateI have put in one place three custom labels that are often asked for but answers are spread through several posts. I hope this will help future people find everything in one place.
I did NOT do these myself, just reporting them here. Credit goes to the people who created cool tool and
App: cool tool from play store
Quick tutorial: you need to go to Labels -> Fine tuning (at the bottom) -> Click on Custom label -> enter settings as shown below
You can modify the prefix and postfix as you like.
************************************************** ********
1. GPU freq
Prefix: GPU:
Postfix: MHz
Path: sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/gpuclk
Regex: (\d+)\d{6}
Replacement pattern: $1
************************************************** ********
2. CPU temperature:
Prefix: T:
Postfix: *degrees symbol* C (or just "C")
DORIMANX KERNEL on LG G2: Path: /sys/class/thermal/thermal_zone5/temp
BOEFFLA KERNEL on OPO: Path: /sys/class/thermal/thermal_zone2/temp
Regex: (\d+)\d{3}
Replacement pattern: $1
NOTE: zone5 is global temperature tested by driver. zone0 is cpu0.
************************************************** ********
3. CPU 1/2/3 on/off state
Unfortunately it is not possible yet to display CPU1/2/3 freq. What can be done is to display a "0" or "1" state which corresponds to "OFF" and "ON".
Prefix: CPU1:
Postfix:
Path: /sys/devices/system/cpu/cpu1/online
Regex:
Replacement pattern: $1
NOTE: replace "1" in prefix and path to "2" or "3" for CPUs 2 and 3.
************************************************** ********
keywords for search results:
cool tool, cooltool, GPU freq frequency, CPU temp temperature, CPU online state on off, custom labels
Awesome dude!!!!!! Can I suggest something? Alucard hotplug and Ondemand plus gov is more battery friendly than Alucard/Alucard...
@bloof
Check out the post linked in my signature. I'm sure there are a few things there that you could add to post #5.
@bloof
May I add a very helpful link, Android Kernel-Governors, Modules, I/O Schedulers. It has heaps of detailed, in-depth information about Kernel-Governors, Modules and I/O Schedulers from a very Beginner-Friendly point of view .
OK, I am done for now, first draft of this thread is UP. Please provide comments/feedbacks/additional knowledge.
have fun
Hi there,
I'm gsstudios and I'm the creator of the android modders guide website (androidmodguide.blogspot.com). Please mention my name in the OP. This isn't a fake message that I've sent, as I have referenced on my website that it was created by myself.
Thanks, gsstudios
gsstudios said:
Hi there,
I'm gsstudios and I'm the creator of the android modders guide website (androidmodguide.blogspot.com). Please mention my name in the OP. This isn't a fake message that I've sent, as I have referenced on my website that it was created by myself.
Thanks, gsstudios
Click to expand...
Click to collapse
DONE and thanks for that guide, the most up to date I found. When creating this thread I checked so many sites and links I ultimately lost track and gave up on re-opening every link.
I'm glad you mention it and happy to give credit of course, it needs to go where it is due.
Well done buddy!
Appreciate your effort to make this thread awesome!
This is a must read for everyone!
Hats off!
this shoud be stickied - well done @bloof ...