(If you own a Nexus 5X or 6P and you are too lazy to read the philosophy of this technique, head on down to the 2nd post and pop those values into your kernel manager and be happy. If you own a different device, please read this post in full.)
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor. :good:
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*At least on the Nexus 5X, you shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
After a bit of tweaking and experimenting, I developed some settings that provide absolutely incredible battery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even a Nexus 5X. This will work on any ROOTed phone with the Interactive governor!
So, after writing a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Nexus 5X you can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
(Note: If your device supports per-core hotplugging, you might be better off using the old guide to determine your nominal clock rates. The Nexus 5X and all current kernels only support hotplugging entire CPUs, so your results may vary if you use any other device.)
For example, on my Nexus 5X, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 460Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Nexus 5X is 460Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Because I cannot find the stock voltages of the Nexus 5X clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the 5X's Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz
Video - 787Mhz
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 1 ("little"–the one with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000 460000:60000 600000:20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 600000
min_sample_time - 30000
target_loads - 98 460000:19 600000:80 672000:12 787000:81 864000:9 960000:69 1248000:95 1440000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels (including stock on Nexus 5X) that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the 2nd CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable. On the Nexus 5X, touchboost adds no perceptual performance gain and only hurts efficiency and battery life. If your kernel doesn't allow you to turn off touchboost, try another one, like the excellent ElementalX.
Your battery life will thank you!
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
I will be happy to answer any questions, or provide any guidance I can. However:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.
I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.
I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized Nexus 5X running ElementalX Kernel, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
In the "CPU" section, turn off "Touchboost". (This is crucial!! YOU MUST TURN OFF TOUCHBOOST OR ELSE YOU WILL NOT SEE ANY BATTERY SAVINGS!!!) Make sure the "Max CPU Frequency" is set to the maximum possible value for each CPU. Make sure the "Min CPU Frequency" is set to the minimum possible value for each CPU. Then set the following values for each CPU under "Governor options" for each CPU respectively:
CURRENT STABLE – Version 2.0
Nexus 5X - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "has 4 cores", aka "maxes out at 1440Mhz")
target_loads - 75 460000:69 600000:80 672000:76 787000:81 864000:81 960000:69 1248000:78
timer_slack - -1
hispeed_freq - 460Mhz
timer_rate - 20000
above_hispeed_delay - 30000 600000:20000 672000:10000
go_hispeed_load - 75
min_sample_time - 60000
CPU #2 (aka "big", aka "has 2 cores", aka "maxes out at 1824Mhz")
target_loads - 72 480000:68 633000:74 768000:80 864000:81 960000:69 1248000:83 1344000:84 1440000:84 1536000:84 1632000:86 1689000:83
timer_slack - 80000
hispeed_freq - 633Mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 72
min_sample_time - 100000
Under "CPU Boost", set "input boost milliseconds" to "0".
Nexus 6P - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "low", aka "maxes out at 1555Mhz")
target_loads - 75 460000:69 600000:80 672000:79 768000:80 864000:81 960000:69 1248000:84 1344000:82 1478000:86
timer_slack - -1
hispeed_freq - 460Mhz
timer_rate - 20000
above_hispeed_delay - 30000 600000:20000 672000:10000
go_hispeed_load - 75
min_sample_time - 60000
CPU #2 (aka "big", aka "fast", aka "maxes out at 1948Mhz")
target_loads - 72 480000:68 633000:74 768000:80 864000:81 960000:69 1248000:84 1344000:84 1440000:84 1536000:85 1632000:85 1728000:85 1824000:84
timer_slack - 80000
hispeed_freq - 768mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 72
min_sample_time - 100000
Under "CPU Boost", set "input boost milliseconds" to "0".
(Having trouble applying these? Check out these great scripts from @Alcolawl PLEASE NOTE THAT THESE ARE OFFICIALLY UNSUPPORTED–direct your queries to Alcolawl so he might provide assistance.)
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
NEW! GlassFish (For most devices!) - High battery savings with buttery smooth interface!
NEW! HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
ARCHIVE
v1.0
Nexus 5X - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "has 4 cores", aka "maxes out at 1440Mhz")
target_loads - 98 600000:80 787000:81 960000:69 1248000:85 1440000:90
timer_slack - 80000
hispeed_freq - 600Mhz
timer_rate - 20000
above_hispeed_delay - 10000
go_hispeed_load - 64
min_sample_time - 80000
CPU #2 (aka "big", aka "has 2 cores", aka "maxes out at 1824Mhz")
target_loads - 90 633000:74 768000:80 960000:69 1248000:83 1536000:84 1689000:90
timer_slack - 80000
hispeed_freq - 1248Mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 80000
Under "CPU Boost", set "input boost milliseconds" to "0".
Nexus 6P - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "low", aka "maxes out at 1555Mhz")
target_loads - 98 600000:80 768000:80 960000:69 1248000:84 1478000:85 1555000:90
timer_slack - 80000
hispeed_freq - 600Mhz
timer_rate - 20000
above_hispeed_delay - 10000
go_hispeed_load - 64
min_sample_time - 80000
CPU #2 (aka "big", aka "fast", aka "maxes out at 1948Mhz")
target_loads - 90 633000:74 768000:80 960000:69 1248000:83 1536000:84 1632000:85 1824000:90
timer_slack - 80000
hispeed_freq - 633mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 80000
Under "CPU Boost", set "input boost milliseconds" to "0".
Changelog:
8/23/16 - Added GlassFish profile
8/16/16 - Added HawkTail profile
1/24/16 - Added instructions to use EXKM's native profiles
1/4/16 - Archived v1.0; elevated "crazy alpha 2" to v2.0 and posted; added links to other alpha settings
12/27/15 - Updated for better performance on 5X and 6P
12/25/15 - Updated to improve battery use on 6P and somewhat on 5X
12/23/15 - Made the beta #2 settings the default; added settings for 6P
FAQ
In this guide, I am using the ElementalX Kernel on the Nexus 5X. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that isn't ElementalX on Nexus 5X, for which this guide was written. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!
been waiting for this since I saw a few posts saying it would be released on r/nexus5x
Thanks!
What program to use to set all these tweaks?
Smultie said:
What program to use to set all these tweaks?
Click to expand...
Click to collapse
I recommend using the ElementalX kernel with the ElementalX Kernel Manager, because it supports all of the features necessary to get the most out of this guide. (Especially turning off touch boost.)
That said, you can try any kernel manager to make these changes. Just search Google Play!
How important is io_is_busy? Can't find that string in the elemental X app.
What are your thoughts, if any, on zram and swappiness values?
soniCron said:
I recommend using the ElementalX kernel with the ElementalX Kernel Manager, because it supports all of the features necessary to get the most out of this guide. (Especially turning off touch boost.)
That said, you can try any kernel manager to make these changes. Just search Google Play!
Click to expand...
Click to collapse
I tried it with Kernel Adiutor, but I noticed that I can't set "hispeed_freq - 600000" on CPU1. Closest options are 480000 and 633600. Which one to choose?
Smultie said:
I tried it with Kernel Adiutor, but I noticed that I can't set "hispeed_freq - 600000" on CPU1. Closest options are 480000 and 633600. Which one to choose?
Click to expand...
Click to collapse
What kernel are you using?
soniCron said:
What kernel are you using?
Click to expand...
Click to collapse
Stock
dg4prez said:
How important is io_is_busy? Can't find that string in the elemental X app.
What are your thoughts, if any, on zram and swappiness values?
Click to expand...
Click to collapse
Sorry, that was inadvertently copied from the old guide. I'll remove it from the post. You can ignore that setting.
Far as zram, I'm not sure, yet. I haven't spent time exploring it on this device. That said, I'm not sure disabling it will improve performance in any noticeable way on this device. With these governor settings, things are screamingly fast, and my concern would be with more apps unloading because of the smaller RAM.
I'll make additional posts as I discover the most reasonable tweaks for this device, but not before I test each methodically and thoroughly...
soniCron said:
Sorry, that was inadvertently copied from the old guide. I'll remove it from the post. You can ignore that setting.
Click to expand...
Click to collapse
I already set it at 0. Should I put it back at 1?
Smultie said:
Stock
Click to expand...
Click to collapse
Would you mind posting all the frequencies available for both CPUs? I'll update the guide to reflect the proper values.
I'm using ElementalX because of its ability to turn off touch boost, so I haven't worked much with the stock kernel.
Thanks!
Smultie said:
I already set it at 0. Should I put it back at 1?
Click to expand...
Click to collapse
Leave it at 0 until I can investigate the stock kernel options.
soniCron said:
Would you mind posting all the frequencies available for both CPUs? I'll update the guide to reflect the proper values.
I'm using ElementalX because of its ability to turn off touch boost, so I haven't worked much with the stock kernel.
Thanks!
Click to expand...
Click to collapse
Big:
Deep Sleep, 384, 480, 633, 768, 864, 960, 1248, 1344, 1440, 1536, 1632, 1689, 1824
Little:
Deep Sleep, 384, 460, 600, 672, 787, 864, 960, 1248, 1440
Also: Stock kernel in combination with Kernel Adiutor allowed me to disable 'Input Boost Frequency Core 1' which I assumed is the same as touch boost. It's described as 'CPU frequency to be boosted to this frequency upon input detection'.
Thanks for your quick replies.
Smultie said:
Big:
Deep Sleep, 384, 480, 633, 768, 864, 960, 1248, 1344, 1440, 1536, 1632, 1689, 1824
Little:
Deep Sleep, 384, 460, 600, 672, 787, 864, 960, 1248, 1440
Also: Stock kernel in combination with Kernel Adiutor allowed me to disable 'Input Boost Frequency Core 1' which I assumed is the same as touch boost. It's described as 'CPU frequency to be boosted to this frequency upon input detection'.
Thanks for your quick replies.
Click to expand...
Click to collapse
Ohhhhh! Okay, I see what's going on! The little CPU is #1 and the big CPU is #2. Reverse your assignments and it should all be fine.
I'll update the post to clarify. (I thought it was a little strange that there would be different clock rates for different kernels. Didn't even think that was possible since it's a hardware feature, not a kernel feature. You had me thinking I missed some major technological advancement! )
soniCron said:
Ohhhhh! Okay, I see what's going on! The little CPU is #1 and the big CPU is #2. Reverse your assignments and it should all be fine.
I'll update the post to clarify. (I thought it was a little strange that there would be different clock rates for different kernels. Didn't even think that was possible since it's a hardware feature, not a kernel feature. You had me thinking I missed some major technological advancement! )
Click to expand...
Click to collapse
Might be a bug in Kernel Adiutor cause I can select the same hispeed_freq for both CPU's (big/little or 1/2).
Also, you state that you want the big CPU to only run at 384, 1248 and 1824 MHz, but I notice it never reaching lower than 633MHz. Are you sure your settings are correct?
Smultie said:
Might be a bug in Kernel Adiutor cause I can select the same hispeed_freq for both CPU's (big/little or 1/2).
Click to expand...
Click to collapse
I made a simplified guide for you (and others):
http://forum.xda-developers.com/showpost.php?p=64279960&postcount=2
I haven't used a kernel manager besides EX Kernel Manager that supports 2 CPUs reliably, so if you're having problems, I suggest you try EX.
If you find one that will modify the stock kernel reliably, please let me know and I'll update the simplified version of the guide to reflect that.
Thanks for your feedback! (And warnings! And concerns!)
Smultie said:
Also, you state that you want the big CPU to only run at 384, 1248 and 1824 MHz, but I notice it never reaching lower than 633MHz. Are you sure your settings are correct?
Click to expand...
Click to collapse
Can you set the minimum clock rate for the big CPU? If that's not possible to set at 384 in stock, I'll update the guide. If it is, then that needs to be done as well.
soniCron said:
Can you set the minimum clock rate for the big CPU? If that's not possible to set at 384 in stock, I'll update the guide. If it is, then that needs to be done as well.
Click to expand...
Click to collapse
In your main guide you state for CPU1:
above_highspeed_delay - 20000 460000:60000 600000:20000
In the "learn to read" guid you state:
above_highspeed_delay - 20000
Which is the correct one?
Also, can't find "Touchboost" under "CPU". Can you be a bit more specific maybe?
Related
I've been using setcpu for a while now, but have never bothered to mess with the advanced settings. Searching around I have only found out what most of this stuff means, but I'm missing some still. I thought I would share my findings. I have included SetCPU's descriptions (in italics) supplemented with my findings.
Governor choices (I'm using king's bfs kernel #1 on fresh 3.1.0.2) -
Ondemand - Uses the highest frequency when tasks are started, decreases step by step
Conservative - Increases frequency step by step, decreases instantly
Interactive - I couldn't figure this one out... any help?
Powersave - Uses the lowest possible clock speed to complete its tasks
Userspace - Manual controll of the frequency
Performance - Always uses the highest clock speed
Advanced Settings -
Sampling Rate - An interval (in microseconds) at which the governor will poll for updates. When this happens, the governor will decide whether to scale the CPU up or down. It uses such little power that it is better at lower values when using profiles such as screen off.
Up Threshold (1%-100%) - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU up. When using low min values (245), this happens instantly, using higher values (768) it overclocks less often. With Conservative lower values are better because it slowly increases your clock speed to what you need, with Ondemand, higher is better, as it overclocks less often.
Down Threshold (1%-100%) (conservative only) - Defines a percentage from 1% to 100%. When the CPU load reaches this point, the governor will scale the CPU down. Higher values will offer more aggressive battery saving, lowering the clock speed quicker.
Ignore Nice Load (0/1) - If this value is "1," the system will ignore "Nice" processes when deciding to scale up or down. I need a little more info for this one, what exactly is a nice process? DO NOT GOOGLE 'NICE LOAD' ESPECIALLY AT WORK OR AROUND CHILDREN/WIFE
Freq Step (0%-100%) (conservative only) - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold. Increased the value slightly to be able to overclock quicker, but not to high to avoid unnecessary overclocking.
Powersave Bias (0-1000) (ondemand only) - Setting this value higher will "bias" the governor toward lower frequencies. This is a percentage, where 1000 is 100%, 100 is 10%, and 0 is 0%. The ondemand governor will scale the CPU to a frequency lower than its "target" speed according to this value. Gives ondemand some more battery saving potential. High values give worse performance than conservative with equal or worse battery saving. If you want the performance of ondemand with some more battery use values under 200.
I hope this info was helpful to someone, and here are my setcpu settings. I have attempted to target 150-175ms for short and 350-400ms for long benchmarks to match my performance governor and save battery at the same time.
With ondemand I get about 170ms short and 380ms long. I use 90 for up and 50 for powersave. The performance is slightly better than the default settings, and the battery is about equal. I might play with this more, as it should hit the same values as performance with better battery life.
In conservative long benchmarks in setcpu are actually faster than short ones because it takes setcpu time to adjust the speed. Run a short one immediately after a long one to see its actual value. Up changed 75 and down to 25, not much of a change, but drastic performance increase with no battery change. I also increased freq step to 10% to obtain higher speeds faster. Getting the same 170ms short and 370ms long.
My Settings
Conservative 245-1190
Temp > 50C - 768 conservative
Screen Off - 499 ondemand (allows for the screen to be unlocked faster, especially useful with incoming calls)
Charging/Full - 1190 performance
Battery < 15% - 652 conservative
Sampling - 200000
Up Thresh - 75
Down Thresh -25
Ignore Nice - 0
Freq - 10
More DFS Info
SetCPU Info
davebu said:
DO NOT GOOGLE 'NICE LOAD' ESPECIALLY AT WORK OR AROUND CHILDREN/WIFE
Click to expand...
Click to collapse
LMAO 10chars
HondaCop said:
LMAO 10chars
Click to expand...
Click to collapse
Yeah. I almost spit out my Vanilla Coke on that one. LOL
Anytime have any info about nice load or anything to add?
Sent from my HTC EVO 4G.
HondaCop said:
LMAO 10chars
Click to expand...
Click to collapse
I missed this yesterday... Post of the day in my opinion
Thanks dave...good write up
This is what I found about the interactive governor in github:
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Also, in the original application thread as explained by the dev, "nice" processes are:
2. Nice processes are used by the IO scheduler to designate a low-priority process. Ignore nice load basically tells ondemand to disregard processes with higher nice values.
Good topic. You covered the bases pretty well. Glad someone finally put this together as it is useful to know. Now prepare for 1000 threads in the next month asking for the information you just posted.
hey question. i went and purchased SetCPU and attempted to follow your instruction. problem is, whenever SetCPU tries to gain super user permission, it says "no root access granted. Are applications allowed root access?" i dunno what to do. can someone advise me?
Umm, is your phone rooted?
Sent from the void...
Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk
SilverStone641 said:
Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk
Click to expand...
Click to collapse
Try uninstalling and reinstalling it.
Then double check all of your superuser settings.
SilverStone641 said:
Yessir. Since day 2 ^_^ (plus its in my sig)
Sent from my Evo using Tapatalk
Click to expand...
Click to collapse
Sorry, using the xda app which doesn't display the sig.
Sent from the void...
So, as far as speed/responsiveness of governors goes:
Fastest ------------------------------------------------------> Slowest
Performance ------> ondemand ------> Interactive? ------> Conservative
Poor battery consumption --------------------> Best battery consumption
This thread is exactly what i was looking for, thanks for the detailed explanation of the what and why.
Will try it out this week with Fresh 3.1 and KK#8.
this thread helped a lot, i was just in setCPU messing around with things, now i can use this thread to help get what i want. i bookmark'd the hell out of this thread
Thanks...OP...hopefully people will read it first...try things..then ask questions...
I am still working to see how to get the best battery life from cm6 and snap..
Thanks for the helpful post!
I experienced a "nice load" when I unboxed my EVO. Anyway the only setting I use is:
Screen off: 245/128 on demand.
Works for me. And thanks for this helpful post to help us understand all that technical mumbo jumbo.
So I got a rooted Vanilla install of the latest Sprint OTA Froyo build on my EVO. (the 3.29.651.5 build).
I purchased the latest version of SetCPU (2.03) last night and used the autodetect method for the CPU governor.
I notice on my EVO that I only have these 3 options:
Scaling:
ondemand, userspace and performance....
Is this normal to not have the conservative setting since I have the defacto kernel with a vanilla rom?
Thanks
Sheldon
Okay, so I figured it out, my default kernel does not have these other options, oh well......
Nice app though, so far its working really well.
I wanted to know what the different governors do, rather than filling dev's threads up with questions I thought i would have a look around and do this for others who like me wanted to know what they do:
1: Interactive
The CPUfreq governor "interactive" is designed for low latency, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However there is no polling, or 'sample_rate' required to scale the CPU up. Sampling CPU load every X ms can lead to under powering the CPU for X ms, leading to dropped framerate, stuttering UI etc..Scaling the CPU up is done when coming out of idle, and like "ondemand" scaling up will always go to MAX, then step down based off of cpu load.
There is only one tuneable value for this governor: min_sample_time: The ammount of time the CPU must spend (in uS) at the current frequency before scaling DOWN. This is done to
more accurately determine the cpu workload and the best speed for that workload. The default is 50ms.
2:Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
3:Smartass
(Quoted from another author http://www.ziggy471.com/2010/11/07/s...-governor-info ) - "is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
4:Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
I assume performance, conservative, powersave and ondemand are self explanatory,
Userspace - finding conflicting info, so if a dev wants to help me out ??
All this info was found on the web in various places, where possible I have quoted where from. If people would like me to link back to them please let me know I will add.
This is purely to help people understand the governors a little without filling dev threads
Can people also leave user feedback on the governors they have been using to give us a reference point to help us all
if it helped hit thanks
Dooms Kernel : http://forum.xda-developers.com/showthread.php?t=1226826
Schedulers post 3
Nice one Chiefy, good to know we have a thread for quick reference when needing it.
Schedulers
NOOP scheduler
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent
HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a
switched Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.
Anticipatory
Anticipatory scheduling is an algorithm for scheduling hard disk input/output. It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
"Deceptive idleness" is a situation where a process appears to be finished reading from the disk when it is actually processing data in preparation of the next read operation. This will cause a normal work-conserving I/O scheduler to switch to servicing I/O from an unrelated process. This situation is detrimental to the throughput of synchronous reads, as it degenerates into a seeking workload.[1] Anticipatory scheduling overcomes deceptive idleness by pausing for a short time (a few milliseconds) after a read operation in anticipation of another close-by read requests.[2]
Anticipatory scheduling yields significant improvements in disk utilization for some workloads.[3] In some situations the Apache web server may achieve up to 71% more throughput from using anticipatory scheduling.[4]
The Linux anticipatory scheduler may reduce performance on disks using TCQ, high performance disks, and hardware RAID arrays.[5] An anticipatory scheduler (AS) was the default Linux kernel scheduler between 2.6.0 and 2.6.18, by which time it was replaced by the CFQ scheduler.
BFQ
The Brain **** Scheduler (or BFS) is a task scheduler designed for the Linux kernel in August of 2009 as an alternative to the Completely Fair Scheduler and the O(1) scheduler.[2] BFS was created by veteran kernel programmer Con Kolivas[3].
The objective of BFS, compared to other schedulers, was to provide a scheduler with a simpler algorithm, that did not require adjustment of heuristics or tuning parameters to tailor performance to a specific type of computation workload. The BFS author asserted that these tunable parameters were difficult for the average user to understand, especially in terms of interactions of multiple parameters with each other, and claimed that the use of such tuning parameters could often result in improved performance in a specific targeted type of computation, at the cost of worse performance in the general case.[4] BFS has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.
CFQ
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority. While CFQ does not do explicit anticipatory IO scheduling, it achieves the same effect of having good aggregate throughput for the system as a whole, by allowing a process queue to idle at the end of synchronous IO thereby "anticipating" further close IO from that process. It can be considered a natural extension of granting IO time slices to a process.
I am testing scary at the mo on stock gb so will edit my post tomorrow bro.
over the next week I will use scary, smartass, ondemand, conservative and interactive and report my findings back here
please all get involved and report back your findings
Can people also post their voltage findings with Dooms new kernel
Scary Report
Phone been on 9h 39m, medium usage, clocking set 128-1113, voltages changed as above post,phone very responsive and no lags, battery remaining 39%, AnTuTu benchmark 2755 linpack 39.
Interactive Report
128-1132 up time 6h 25mins, phone responsive no lag, medium usage 36% left, AnTuTu benchmark 2502 linpack 36 this governor doesnt seem to help battery level very much
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Neo said:
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Click to expand...
Click to collapse
so far the best governors that i have used have been Smartass and Scary but i will continue testing the governors and reporting back. Smartass was working great with no o/c for me, i will add this to this test. tomorrow i will test Scary with no o/c
Ok, my conclusions of using the scary gov on my modded stock gb is probally the best my phone has been, nearly all frequencies are being used, had to use min 192 and max 1190 as had a few screen off reboots but once using those settings my no more reboots. Battery life is the best i have had on custom kernel with flat line overnight, 3% loss, with wifi off and hourly updates of email, deep sleep working perfect as it should.
Overall, this is my personal favorite so far, just to add also this is using...
http://doomlord.sylvester20007.com/x10/x10_gb/dk/v02/dk-v02-X-modfxp_xrec.zip
I have not started using v03 of Dooms new kernel because of the good results with v02x.
Samrtass Report
Running Smartass governor uptime 5hours 1minute 128-1132cpu, medium usage, twitter, facebook two calls, brightness and 50%, AnTuTu Benchmark 1569 linpack 31 ( second linpac got WLOD ) battery 69%
Edit 10hours up time 42% battery left
As you can see smartass is a battery friend but performance suffers, although for my usage i find that this is the best governor for me at the minute
further governor tests continue
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
keep going!!
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
om23 said:
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
Click to expand...
Click to collapse
From what I have encountered it depends on the age of your phone, it is safe and won't blow you phone up but some models can handle far greater stress. the newer phones tend to be able to overclock higher, all that will happen if you phone cant handle the overclock is you will get the dreaded WLOD and your phone will reboot, then if you have set the speed from boot you may get stuck at boot image, but if that is the case then you use flash tool and reflash
chiefy009 said:
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
Click to expand...
Click to collapse
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
MinMax Governor (Battery Saver)
This governor will try to minimize the frequency jumps/changes which cause voltage spikes/changes and supposedly drain more battery life
Click to expand...
Click to collapse
Just my 2 cents!
My_Immortal said:
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
Just my 2 cents!
Click to expand...
Click to collapse
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
chiefy009 said:
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
Click to expand...
Click to collapse
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Scary Governor
Description coming from the author:
A new governor I wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
Click to expand...
Click to collapse
Performance suffers, in my opinion.
It scales the CPU conservatively, so it is very annoying when playing games
or even syncing to get your Gmails.
Also, and this applies to all governors, speed is decreased when the sampling rate is high. Which means that if the CPU constantly checks for load in order to increase/decrease frequency, that will take its toll both to performance and battery life.
Smartass - Interactive - Ondemand
I am putting those 3 governors in the same category, because at least for me, they functioned very similarly.
What I noticed is that indeed the phone used almost all available frequencies before going to MAX, but the phone was laggy. Especially when scrolling in big lists, interactive and smartass gave me unacceptable performance. Ondemand was a tad better, but still, the phone seemed to "resist" scrolling for a few seconds and then go ahead and finally do it!
Battery life was pretty much the same as stock
(since ondemand is the default governor for stock kernel).
MinMax
As I stated in my previous post, minmax gave me the smoothest and fastest results.
This governor doesn't take intermittent load samples, when it first detects CPU load, aka you start using your phone, it jumps to the max frequency and stays there until you stop using it.
At this point, I want to express my opinion on the subject of "High Freq When Screen On", because many users complain about it, but I beg to differ.
In theory, CPU running at max frequency all the time, is heat generating and/thus battery consuming. Alas, be careful: in theory...
Because practically, when you use your phone, you usually do CPU demanding tasks.
When the phone is in my pocket/bag/drawer/whenever doing nothing, I want to be in Deep Sleep.
When I turn it on to look at the time of if there's any new notification, that lasts 30 secs - 1 minute. What frequency will be used then, is not that important.
When I turn it on to actually do something, I want it to be FAST.
If I can scroll a list faster, if I can open an app faster, then I will be using the phone for less time.
If the CPU is sampling and scaling up conservatively, the phone will be laggy
and I will need more time to accomplish my tasks.
All in all, I am not intimitaded by high frequencies while using the phone.
I would start worrying if I got no Deep Sleep -which isn't the case fortunately.
And my battery life is amazing, I get about 1 day and a few hours more,
with pretty heavy use.
Just my 2 cents on the matter.
Powersave
If you are ever really mad at your X10 and you want to see it struggle and suffer, then this is the governor for you! Enough said!
Performance
Pretty snappy, good for gaming and benchmarking, as it uses only MAX frequency. Not for prolonged use though, because it will ONLY use the max frequency (and Deep Sleep of course).
I'll make sure to make more tests in the future and post more thorough reviews!
Again, thanks for this thread chiefy009!!
My_Immortal said:
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Click to expand...
Click to collapse
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
chiefy009 said:
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
Click to expand...
Click to collapse
I have undervolted my phone using these values:
128000 Hz - 875 V
192000 Hz - 900 V
245760 Hz - 925 V
384000 Hz - 950 V
460800 Hz - 975 V
576000 Hz - 1000 V
652800 Hz - 1050 V
768000 Hz - 1100 V
844800 Hz - 1150 V
921600 Hz - 1200 V
998400 Hz - 1250 V
The phone runs pretty stable, didn't have a single reboot or WLOD so far (3 days).
Xperia X10i via Tapatalk
I will try those settings for undervolting
Smartass Update
This governor is working wonders for me at the minute, phone been online for 6hours, medium/light usage 128-1132mhz few calls, connected to bluetooth speaker in car, little web usage and twitter and the battery is still on 88%
That is impressive
{
"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 ...
First of all read orginal thread for Nexus 5
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557i
Please read this post in full
also read this document:
https://android.googlesource.com/ke...7aebe08b/Documentation/cpu-freq/governors.txt
For now the tweak is only for ARDE overclocked kernel,Underclocked kernel from @Unjustified Dev
If you are too lazy to read the post and configure what suites best for your device I made a template kernel with already integrated tweaks working on all Cm based roms and ill upoload it asap
or simply use Kernel Aduitor to input theese settings
updated Mar.29.2016
Setting for little CPU :
above_highspeed_delay - 25000 800000:50000 998400:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 89
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 80 523400:60 800000:77 998400:81 1113600:77 1309000:81 1448000:81 1601000:10
timer_rate - 20000
timer_slack - 60000
Setting for BIG CPU:
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:24 960000:16 1113600:20 1334000:81 1497600:7 1612800:6 1651200:96
timer_rate - 20000
timer_slack - 80000
NOTE:If the big cpu minimum frequencie keeps reverting to 960mhz change governeur to smartmax, liitle cpu max frequencie to 1334000
settings for underclocked kernel (200mhz-1.4ghz) in post 54
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*You shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
So, after reading a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Idol 3
In this guide, I am using the ARDE overclocked and underclocked kernel by @Unjustified Dev Kernel on moded stock rom by @DallasCZ AICP rom and latest CM 12.1 by @The Marionette. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that mpdecision driver. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!u can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the little CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the BIG CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allow
For example, on my Idol 3, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 800Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Idol3 is 800Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
Because I cannot find the stock voltages of the Idol 3 clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Idols Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 533Mhz
Page Scrolling - 800Mhz -
Video -960Mhz-
App Loading - 960Mhz-
High Load Processing - 144800Mhz-
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Idol 3 If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 533Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 960Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1656Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 533333:60000 800000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 533Mhz. Once it has exceeded 533Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Idol 3, use the following Interactive governor settings for little CPU 1 (with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Idol 3, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (533Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "30000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 800Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Idol 3.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
Max. Eff. Load:
Clock rate/next highest clockrate * 90%
533MHz/800MHZ * 90%
Min. Eff. Load:
(Next highest clock rate / clock rate - 1) * 100%
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(Next highest clock rate / clock rate - 1) * 100%
(800Mhz/533Mhz-1)*100
For the Idol 3, the maximal efficient loads of little CPU are:
533333:60
800000:72
998400:80
1113600:76
1303000:81
1448000:81
1601000:95
For the Idol 3, the minimal efficient loads of little CPU are:
533333:5
800000:24
998400:11
1113600:17
1303000:10
1448000:10
1601000:0
For the Idol 3, the maximal efficient loads BIG CPU are:
533333:60
800000:75
960000:77
1113600:74
1344000:80
1497600:83
1612800:87
1651200:95
For the Idol 3, the minimal efficient loads BIG CPU are:
533333:5
800000:24
960000:16
1113600:20
1344000:11
1497600:7
1612800:2
1651200:2
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That BIG CPU?!
So we've all but ignored the BIG CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Idol, the system is pretty smart about when to employ the power of this inefficient BIG CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
533Mhz
1344Mhz
1651Mhz
In this case, we configure it just as we did with little CPU , but only worry about keeping it idle as much as possible, allow it to jump to 1651Mhz immediately when needed, and encourage it to fall back to 1344Mhz if a sustained load is needed.
These values are ideal for the Idol, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
The Money Shot: Part Deux
If you are using a Idol 3, use the following Interactive governor settings for BIG CPU 2. (the one with 2 cores)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the little CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
i am currently using it for two days...will report how it goes
DallasCZ said:
i am currently using it for two days...will report how it goes
Click to expand...
Click to collapse
this is still not finished only copy paste thread .i have frequencies and loads on paper ,after i finish trhead i few minutes its for everyone ill upload two kernels with implemeted setting one with min 200 mhz and one with 533 min on your rom,and i was wondering is it posible to disable mpdecision on your stock rom since i have buttiful battery life for some thime but as just as i lock or go to deepsleep min frequencies are revertet to 960 instead of 533
nero curin said:
this is still not finished only copy paste thread .i have frequencies and loads on paper ,after i finish trhead i few minutes its for everyone ill upload two kernels with implemeted setting one with min 200 mhz and one with 533 min on your rom,and i was wondering is it posible to disable mpdecision on your stock rom since i have buttiful battery life for some thime but as just as i lock or go to deepsleep min frequencies are revertet to 960 instead of 533
Click to expand...
Click to collapse
I cant help you with the mpdecision, I am only modder not a dev.
the hernel would be awsome. Please correct the title * [GUIDE] [PERDORMANCE] [BATTERY] Idol 3 (6045x) advanced Interactive gouv settings* is wrong, it should be * [GUIDE] [PERFORMANCE] [BATTERY] Idol 3 (6045x) advanced Interactive gov settings* ..but if you will implement those settings to ARDE DEV kernel, please ask them for permission, or rename this thread to something like this *[KERNEL] 6045x ARDE DEV KERNEL MOD*
I'm using this governors and the battery and perfomance are greater on my personal build flyme os 4.5.4
---------- Post added at 04:19 PM ---------- Previous post was at 04:11 PM ----------
And in Which Rom the governors works best ?
i use Arde OC on Flyme my personal build
Here's mine Screenshoots with this governors on Flyme
charged to 92 %
and the Screentime is 31 min
and the mm-pp-daemon doesn't drains battey
{
"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"
}
DallasCZ said:
i am currently using it for two days...will report how it goes
Click to expand...
Click to collapse
are you using these setting wich I updated just now or you have done your calculations
i am using the calculations you wrote in the cm12. 1 thread.
Odesláno z mého 6045X pomocí Tapatalk
so far it looks great. 3 hours of SoT and 40% battery left.
Odesláno z mého 6045X pomocí Tapatalk
DallasCZ said:
so far it looks great. 3 hours of SoT and 40% battery left.
Odesláno z mého 6045X pomocí Tapatalk
Click to expand...
Click to collapse
Those were rough calculations,these are more precise,I got like 7 hrs sot time it can get more also I got 34750 score on antutu only problem is mpdesicion which raises min CPU freq to 960 and that drains more battery
nero curin said:
Those were rough calculations,these are more precise,I got like 7 hrs sot time it can get more also I got 34750 score on antutu only problem is mpdesicion which raises min CPU freq to 960 and that drains more battery
Click to expand...
Click to collapse
if oyu look on my screens from the LITLLE cluster it is almost all the time on 533 MHz
DallasCZ said:
if oyu look on my screens from the LITLLE cluster it is almost all the time on 533 MHz
Click to expand...
Click to collapse
can you upload screenshot of BIG cluster
Did somebody stock rom for TWRP recovery? ...6045Y
This is a very interesting thread but very in depth, I'm not sure where to start I'd like to tweak interactive for my m8 would you be able to give me some guidance of its not too much trouble thank you in advance.
Sent from my HTC One_M8 using Tapatalk
smeejaytee said:
This is a very interesting thread but very in depth, I'm not sure where to start I'd like to tweak interactive for my m8 would you be able to give me some guidance of its not too much trouble thank you in advance.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
this is the guide,take a pice of paper wright your frequencies and use the formula above to calculate wich frequencies to use more and wich less,its acttualy real simple
Sent from my 6045X using Tapatalk
nero curin said:
this is the guide,take a pice of paper wright your frequencies and use the formula above to calculate wich frequencies to use more and wich less,its acttualy real simple
Sent from my 6045X using Tapatalk
Click to expand...
Click to collapse
I've been reading for an hour or so mate, what's throwing me is the big CPU and little CPU bit I'm guessing this is referring to octocore but I have a quad core, I've set up according to your template which is quite similar to the interactive settings i had set anyway, but there are parameters missing are they not needed like sync frequency and up threshold. I'll try and do some more reading but it is a lot to take in lol thanks for the reply.
Sent from my HTC One_M8 using Tapatalk
smeejaytee said:
I've been reading for an hour or so mate, what's throwing me is the big CPU and little CPU bit I'm guessing this is referring to octocore but I have a quad core, I've set up according to your template which is quite similar to the interactive settings i had set anyway, but there are parameters missing are they not needed like sync frequency and up threshold. I'll try and do some more reading but it is a lot to take in lol thanks for the reply.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
then read orginal thread,theere is a guide for dual core wich can be aplyed to quad core,or simply use setting based based my little cores with applyng your frequencies becouse they are doing al the work and big cores only burst.cheers
Sent from my 6045X using Tapatalk
nero curin said:
First of all read orginal thread for Nexus 5
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557i
Please read this post in full
For now the tweak is only for ARDE overclocked kernel,Underclocked kernel from @Unjustified Dev in a few days
If you are too lazy to read the post and configure what suites best for your device I made a template kernel with already integrated tweaks working on all Cm based roms and ill upoload it asap
or simply use Kernel Aduitor to input theese settings
Setting for little CPU :
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
Setting for BIG CPU:
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*You shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
So, after reading a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Idol 3
In this guide, I am using the ARDE overclocked and underclocked kernel by @Unjustified Dev Kernel on moded stock rom by @DallasCZ AICP rom by @The Marionette. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that mpdecision driver. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!u can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the little CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the BIG CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allow
For example, on my Idol 3, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 800Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Idol3 is 800Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
Because I cannot find the stock voltages of the Idol 3 clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Idols Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 533Mhz
Page Scrolling - 800Mhz -
Video -960Mhz-
App Loading - 960Mhz-
High Load Processing - 144800Mhz-
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Idol 3 If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 533Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 960Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1656Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 533333:60000 800000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 533Mhz. Once it has exceeded 533Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Idol 3, use the following Interactive governor settings for little CPU 1 (with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Idol 3, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (533Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "30000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 800Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Idol 3.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Idol 3, the maximal efficient loads of little CPU are:
533333:60
800000:72
998400:80
1113600:76
1303000:81
1448000:81
1601000:95
For the Idol 3, the minimal efficient loads of little CPU are:
533333:5
800000:24
998400:11
1113600:17
1303000:10
1448000:10
1601000:0
For the Idol 3, the maximal efficient loads BIG CPU are:
533333:60
800000:75
960000:77
1113600:74
1344000:80
1497600:83
1612800:87
1651200:95
For the Idol 3, the minimal efficient loads BIG CPU are:
533333:5
800000:24
960000:16
1113600:20
1344000:11
1497600:7
1612800:2
1651200:2
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That BIG CPU?!
So we've all but ignored the BIG CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Idol, the system is pretty smart about when to employ the power of this inefficient BIG CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
533Mhz
1344Mhz
1651Mhz
In this case, we configure it just as we did with little CPU , but only worry about keeping it idle as much as possible, allow it to jump to 1651Mhz immediately when needed, and encourage it to fall back to 1344Mhz if a sustained load is needed.
These values are ideal for the Idol, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
The Money Shot: Part Deux
If you are using a Idol 3, use the following Interactive governor settings for BIG CPU 2. (the one with 2 cores)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the little CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
Click to expand...
Click to collapse
Whick Rom did you USE,and Which kernel ?
Alek Dev said:
Whick Rom did you USE,and Which kernel ?
Click to expand...
Click to collapse
moded stock from @DallasCZ currently with oc kernel already in rom
Sent from my 6045X using Tapatalk
nero curin said:
moded stock from @DallasCZ currently with oc kernel already in rom
Sent from my 6045X using Tapatalk
Click to expand...
Click to collapse
okay,when you will upload new kernel you maded with governors,in the rom made by dallascz i get reboots with this kernel
Alek Dev said:
okay,when you will upload new kernel you maded with governors,in the rom made by dallascz i get reboots with this kernel
Click to expand...
Click to collapse
there is alternative kernel for versions with reboots on his thread also OC kernel,im experimenting with difrent frquencies.when im sure i got the right thing ill upload until then everyone can calculate frequencies for kernel they are using ore use the themplate settings
Sent from my 6045X using Tapatalk