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.
Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/show...65&postcount=2
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24:Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Goveronor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: Hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817
This is really interesting , so is smartass better than v2 for battery as we know from tests that with deep idle 400mhz is best...
Sent from my Nexus S using Tapatalk 2
italia0101 said:
This is really interesting , so is smartass better than v2 for battery as we know from tests that with deep idle 400mhz is best...
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
for my part in the various tests I've done for me, smartass v2 works better
Did you keep defaults of v2?
Sent from my Nexus S using Tapatalk 2
italia0101 said:
Did you keep defaults of v2?
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
is also factory defaults no problem
as governor frequently used and why?
so we try to give references to new users
stempox said:
as governor frequently used and why?
so we try to give references to new users
Click to expand...
Click to collapse
changes coming
added badass
Enlightening, I wasn't even aware there were so many governors.
next governor added pegasus
stempox said:
next governor added pegasus
Click to expand...
Click to collapse
Thanks for new user like me very useful
blonde90 said:
Thanks for new user like me very useful
Click to expand...
Click to collapse
thanks, always available
new governors coming
Wheatley added
I am astonished how many governors are available.
Very clear and easy to understand.
This has enabled me to choose which governor to use based on habits.
Thanks for this. Added to subscribe for future reference!
Sent from my Nexus S using Tapatalk 2
thread updated
Great thread. It explained some of what I didn't know about the various governors and even showed me some new ones.
Sent from my ADR6400L using Tapatalk 2
This really helped me out! Great thread! Thank you.
Sent from my Nexus S using xda app-developers app
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ultimate battery guide
Battery, one of the most important thing on todays phones. Even if we have awesome battery life we always want more and it is never enough.
This is the small guide to tips, trick and tweaks to improve battery life.
This topic is to share tips and tricks and basically just small talk about battery and sharing screenshots.
Use Gsam or Android battery history to show your battery life.
Our goal is to make most of the screen on time with average use of 24 hours. So lets start.
Post 1: Tips
Post 2: ROMS, kernels, undervolting, underclocking
Tips to improve battery life
Location services
One of the first thing that your device will ask when you are setting up your phone. Most of the users let them ON and just forgot about them. Location services are battery hungry and the will drain your battery like you drinking juice.
Thing is that you do not need them always, just sometimes. Turn it OFF then. I have them turned off always and when I need it I just simple turn it ON.
Wi-Fi
Wi-Fi scanning is thing that will drain your battery always. When you are out and you are not expecting to use wi-fi any time soon turn it off. You do not need to run scanning all the time.
You could also edit build.prop to reduce.
Edit wifi.supplicant_scan_interval. Default value is 180. You can set it higher to reduce the scanning intervals.
Signal strength / Network mode
Signal strength is always trouble for battery. Weak signal will drain more battery. Also, constant changing between 4G/3G and 2G will drain battery faster.
Tweak to this is to set your phone to only use 2G, 3G or 4G.
Example: when I am not using my phone, or it is connected to wifi my network is on 2G. I dont need 3G or 4G then and changing network state is disabled then because it will stay always on 2G. I found it has positive effect on battery.
When I need, I just simple toggle 3G or 4G.
Screen brightness
Screen is the thing that drains most of our battery. There is not much philosophy here. Higher brightness will drain more battery.
My personal setup is that I do not use auto brightness. I always change brightness manually. Right now during winter my brightness does not go more then 25% outside, and inside it is lower. At night it is under 10%.
I found that not using auto brightness has also slight positive effect on battery.
Syncing / Airplane mode / Vibration / Animations / Task Killers
Lets start in order.
Syncing: more syncing your device does it drains more battery. On your phone probably you do not to sync all accounts and apps you have every few minutes or hours. Set those apps you do not need on manual sync.
Airplane mode: I am using airplane mode during night because I do not want to be disturbed during sleep. With airplane mode battery consumption during night is 0%. Yes, zero percent.
Vibration: more your device vibrates, more battery it drains. You can reduce vibrations on keyboard settings and similar. I found that is not much effect on battery but it has slight.
Animations: animations drains your battery also and who really needs them. Personally, I am annoyed with them and I always switch them to 0 or .5. You can do that in Settings-Developers options
Task Killers: task killers, clean maters and similar software is a big NO. You dont need it. It does more damage then good.
Bloatware
Yes, bloatware. There is huge amount of bloatware on our phones and we really do not need it. So, what to do? Freeze that bloatware.
You can find list of apps HERE. There is also available tool for auto disable, ImproveG3
ROMS and kernels
Custom ROMs and kernels will give you in most cases better battery life then stock firmware. Plus there is huge amount of options to play with. You can read more in posts bellow.
Summary:
If you change some of those thing you will see the effect.
You can always use apps like Greenify or Tasker and play with their options.
How to follow your battery life
GSam Battery Monitor
This one of the most useful apps to track your battery. On Lollipop (even on Kitkat) it will not give you much useful info without root.
If you are using it without root everytime you reboot the phone statistic would be reset also. If you have root it will give you access to wakelocks and some other stuff, plus stats would not get reseted.
Play store link
Wakelock detector
Wakelocks, one of the painful things on phone. If you see your battery is draining faster in idle then you got problem with wakelocks. This is useful app because it shows wakelocks on very simple setup and you can discover which app is causing which wakelock.
Play Store link
Disable service
If you are using Wakelock detector you need this app also. With this app you can freeze every single process that app can launch. It will provide detail look on all processes from apps. With this app I have reduced wakelocks to 1%.
Play Store link
ROMS
Discussion about ROMs never looked nice. It always gets to what you personally like. Some ROMs will be easier on battery, some will be rough. You will never know before you try them.
Kernels
Kernels are similar to ROMS but you can play with them. Currently there is not much kernels available but you can play even with stock one.
I recommend to use Trickster MOD Kernel Settings app to play with kernel settings.
Undervoting
Undervolting is the thing when you control how much power each CPU frequency can have. Trickster MOD app gives really nice view on them. You can undervolt every frequency by itself or all in one.
My personal recommendation is to undervolt them at once. I always use -50 value. Found it stable.
Of course, you can always play with different values but remember: when you play with this do not click on option "Set on Boot" or you will end in bootloop if you click it. Click that option when you find out that values are safe for using and stable.
Underclocking
Underclocking is changing your CPU frequency. Rough truth is that we dont need our CPU to run on 2,7 GHz in normal use. Only gamers will need that probably but since this is not thread were we are aiming gamers we dont need that high frequency.
Me personally, I use always 1,7 GHz or 1,9 GHz. To my daily usage (most common like everyone else but without games) this is more then enough. Everything is still smooth and runs fast.
Governors
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
You can find explanation hidden here.
Many users have wrote about governors and they are practically the same on most of the phones so I will copy list from droidphile.
On his topic you have more details about governors.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
20) Wheatley
21) Smartmax
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
20) Wheatley
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
21) Smartmax
Its no benchmark or ultimate perfromance governor, its a proper balanced ondemand.
The basic idea - which comes from smartass - is the concept of an "ideal" frequency.
The following strategy is used:
1) If load is above upper-threshold and current frequency is below ideal freq
-> jump to ideal in one step
2) If load is above upper-threshold and current frequency is at or above ideal freq
->do "ramp up" steps which will include all frequencies for a specific
amount of time - so compared to ondemand no "jumping" to max frequency
3) if load is below lower-threshold and current frequency is below ideal freq
->do "ramp down" steps
4) if load is below lower-threshold and current frequency is above ideal freq
-> jump down to ideal in one step
All those thresholds ramp steps and frequency stepping times are
fully configurable using sysfs. By default I tried to create a good balance.
The ideal frequency for "us" is 475000 which is the maximal frequency
of the LP mode of the tegra chip. This will allow using LP mode as much as possible
Additional to make it "snappy" smartmax has "touch poke"
So input events from the touchscreen will boost the cpu for a specific
time to a specific frequency.
Schedulers
Everything has been said about them so I will use droidphile explanations.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
reserved
Lets talk and share tips
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Ok so the best setting for governors and I/O control battery life and perfomance
veekay said:
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Click to expand...
Click to collapse
I am using SmartassV2 and noop.
TIP
For those who most of the day stay indoors and don't need a very bright screen like me, may install this xposed module, Minimum Brightness.
With this you can lower the minimum brightness of the screen beyond the usual value. It aids in saving quite some juice. :good:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Saratoga79 said:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Click to expand...
Click to collapse
Nice setup.
On first look it looks like stable setup.
DelBoy said:
Nice setup.
On first look it looks like stable setup.
Click to expand...
Click to collapse
Thanks buddy!
Yes it is pretty stable with no reboots or feezes. Also perfomance seems to be good enought and I haven't notice any lag.
This is my todays battery.
22% left. Used 75% with 19 hours on battery and SOT 5 hours for now.
During this 19 hours airplane mode was ON for like 6 hours during the night.
Results can get better. This is on V20A. I believe V20D will get me better results.
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
Early to judge, but it is the same I believe. Not much difference.
Updated post with few more governors
Very nice one
Would you mind adding a link to ImproveG3 to the "Bloatware" section?
Oh and I didn't change much cpu wise, just Amplify'ed Wakelocks RILK, NlpWakeLock and NlpCollectorWakeLock, device remains at 100% during night (~7-8 hours) without using airplane or turning off data/wifi/syncing
Don't have extremely many apps installed though, and set syncing intervals that make sense, depending on app/account.
Thank you very much.
Regards,
sub
@subworx - added
How can I use those governors I have Stweaks but can't find it there
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
For me 4.4.2 has a lot better battery life
AAA118 said:
How can I use those governors I have Stweaks but can't find it there
Click to expand...
Click to collapse
You need to have custom kernel that has that governors (Rin kernel, or ChupaChups).
After that use TricksterMod or CPUcontrol to change governors.
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 ...