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.
Hi,
Can anyone direct me to some info on altering CPU settings on my N10?
I've recently rooted and flashed the latest AOKP ROM and am interested in the performance control.
The current max is set to 1700Mhz which, of course, is the rated value for the CPU. Will I do any damage by increasing it and what effects do changing the voltage setting have?
Also, is there a guide to using Governor and IO schedulers?
Thanks in advance.
Pharmbob said:
Hi,
Can anyone direct me to some info on altering CPU settings on my N10?
I've recently rooted and flashed the latest AOKP ROM and am interested in the performance control.
The current max is set to 1700Mhz which, of course, is the rated value for the CPU. Will I do any damage by increasing it and what effects do changing the voltage setting have?
Also, is there a guide to using Governor and IO schedulers?
Thanks in advance.
Click to expand...
Click to collapse
Well I have to say that I haven't come across any device specific tutorials for governors or schedulers, and I would love to see someone put one together for the N10. My understanding is that the stock MHz value is purposely set on the slightly lower side to prevent any possibility of electrical issues. In regards to the voltage, lowering it may cause loss of display due to a lack of power and a major problem with increasing voltages is usually thermal throttling from high CPU temperatures.
But if you're interested in more governor and over clocking capabilities you should look at the KTManta kernel, I'm running it right now. You should be able to relatively safely over clock up to 1800MHz without crazy effects, but much more than that and you'll significantly reduce the tablet life.
Sent from my Nexus 10 using XDA Premium HD app
Huggogguh said:
Well I have to say that I haven't come across any device specific tutorials for governors or schedulers, and I would love to see someone put one together for the N10. My understanding is that the stock MHz value is purposely set on the slightly lower side to prevent any possibility of electrical issues. In regards to the voltage, lowering it may cause loss of display due to a lack of power and a major problem with increasing voltages is usually thermal throttling from high CPU temperatures.
But if you're interested in more governor and over clocking capabilities you should look at the KTManta kernel, I'm running it right now. You should be able to relatively safely over clock up to 1800MHz without crazy effects, but much more than that and you'll significantly reduce the tablet life.
Sent from my Nexus 10 using XDA Premium HD app
Click to expand...
Click to collapse
Does overclocking to 1800MHz make much of a difference to performance?
I've just flashed the KTMANTA kernel and I am impressed.
Would it be detrimental to increase the GPU Max?
Pharmbob said:
I've just flashed the KTMANTA kernel and I am impressed.
Would it be detrimental to increase the GPU Max?
Click to expand...
Click to collapse
im not on AOKP ROM so i dont know how the CPU performance is optimized but on original rom the CPU speed rarely/never gets over
1000mhz
so overclocking to 1800mhz is pointless.
you need to upper the boost pulse instead
Patrik G said:
im not on AOKP ROM so i dont know how the CPU performance is optimized but on original rom the CPU speed rarely/never gets over
1000mhz
so overclocking to 1800mhz is pointless.
you need to upper the boost pulse instead
Click to expand...
Click to collapse
And what does the boost pulse do?
Pharmbob said:
And what does the boost pulse do?
Click to expand...
Click to collapse
it will boost the CPU speed higher when its under load
change this settings (leave the rest at default) in KTweakerT and the N10 will fly
CPU Governor: pegasusq
I/O Scheduler: ROW
under "Governor Adjustmensts" change these:
boostpulse_value: 1700
up_threshold: 40
up_threshold_at_min_freq: 20
Under Extras:
to keep your saved settings when the screen i off you will need to change the "Screen off profile Mhz" to something else than the Defualt setting
change it to 100mhz
also go in under the "Thermal Throttle Control" (settings for kids)
change these values to:
CPU start Throttle: 100
CPU Stop Throttle: 99
Memory Start Throttle: 100
Memory Stop Throttle: 99
that is the only way to get rid of the Throttling control.
one note is when you play games lock the min/max mhz to the same speed for an example (MIN 1500mhz/MAX 1500mhz)
its the up/down CPU speeds changes that causes it to lag
for movies lock the min/max speed at 800mhz and your blu ray movies will play without microstutter
also use BS player that has the fastest HW decoding
NOW Enjoy your Nexus 10 as it was ment to be used
Patrik G said:
it will boost the CPU speed higher when its under load
change this settings (leave the rest at default) in KTweakerT and the N10 will fly
CPU Governor: pegasusq
I/O Scheduler: ROW
under "Governor Adjustmensts" change these:
boostpulse_value: 1700
up_threshold: 40
up_threshold_at_min_freq: 20
Under Extras:
to keep your saved settings when the screen i off you will need to change the "Screen off profile Mhz" to something else than the Defualt setting
change it to 100mhz
also go in under the "Thermal Throttle Control" (settings for kids)
change these values to:
CPU start Throttle: 100
CPU Stop Throttle: 99
Memory Start Throttle: 100
Memory Stop Throttle: 99
that is the only way to get rid of the Throttling control.
one note is when you play games lock the min/max mhz to the same speed for an example (MIN 1500mhz/MAX 1500mhz)
its the up/down CPU speeds changes that causes it to lag
for movies lock the min/max speed at 800mhz and your blu ray movies will play without microstutter
also use BS player that has the fastest HW decoding
NOW Enjoy your Nexus 10 as it was ment to be used
Click to expand...
Click to collapse
Thanks for the info, I'm apprehensive about altering the thermal settings though. Will letting the processor get as hot as 100 degrees not reduce the life of the chip?
Pharmbob said:
Will letting the processor get as hot as 100 degrees not reduce the life of the chip?
Click to expand...
Click to collapse
sure if it would
i have already measured the CPU temp without the back case and its nowhere near 100 degrees
50 is more true so you are safe even without the Throttling control.
the thermal throttling control isnt measuring temps it only guess them.
Patrik G said:
it will boost the CPU speed higher when its under load
change this settings (leave the rest at default) in KTweakerT and the N10 will fly
CPU Governor: pegasusq
I/O Scheduler: ROW
under "Governor Adjustmensts" change these:
boostpulse_value: 1700
up_threshold: 40
up_threshold_at_min_freq: 20
Under Extras:
to keep your saved settings when the screen i off you will need to change the "Screen off profile Mhz" to something else than the Defualt setting
change it to 100mhz
also go in under the "Thermal Throttle Control" (settings for kids)
change these values to:
CPU start Throttle: 100
CPU Stop Throttle: 99
Memory Start Throttle: 100
Memory Stop Throttle: 99
that is the only way to get rid of the Throttling control.
one note is when you play games lock the min/max mhz to the same speed for an example (MIN 1500mhz/MAX 1500mhz)
its the up/down CPU speeds changes that causes it to lag
for movies lock the min/max speed at 800mhz and your blu ray movies will play without microstutter
also use BS player that has the fastest HW decoding
NOW Enjoy your Nexus 10 as it was ment to be used
Click to expand...
Click to collapse
Sorry for being such a noob but this is my first android device. I installed the kt room and the tweaker it all works fine. Bit whem i changed the room all my stift dissapeard. I vacker up my last rom can i just switch to that and backup with titan?
Btw it improved gta gaming very much. Bit what happens IF i always have the min/max on 1500?
Sent from my Nexus 10 using XDA Premium HD app
p0xis said:
Bit what happens IF i always have the min/max on 1500?
Sent from my Nexus 10 using XDA Premium HD app
Click to expand...
Click to collapse
the tablet will explode after 30 minutes.
its the new Self destruction detection from samsung.
(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?
Now that we have root access and are able to make modifications to the interactive governor, I have worked through the same principles of the nexus 6p governor tweaks as they would be applied to the Pixel C X1.
Original Guide:
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
and extra help from @xSilas43 to further refine the settings
So the main differents between the qualcomm and nvidia are core count and cpu freq steps are different, so some options aren't available (touchboost etc) but the theory is still the same. The only thing missing now is a method to determine voltage of each cpu freq step so we can get better effective values.
So I went through and did all the maths based on the proper target loads and i think its optimised properly now with lower cpu values then before.
Important: set the min cpu speed to 102Mhz as seems that its set to 204 by default but perfectly fine to sit that low.
So based on my testing with stock given the recently discovered bug on stock
I don't recommended using these tweaks at present so please only use if you are on dirty unicorn or other asop build
V3.1 PixelBits testrev
target_loads - 8 102000:40 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
Previous Versions
V3.0 PixelBits
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.2 more refinements edition with help from @xSilas43
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:8 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 408000:20000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.0 Optimised for X1 (based on nomial loads with min and max thresholds based on target loads)
target_loads - 45 102000:45 204000:50 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:11 1020000:10 1122000:9 1224000:83 1326000:8 1428000:84 1530000:7 1632000:85 1734000:6 1836000:86
timer_slack - 80000
hispeed_freq - 306Mhz
timer_rate - 40000
above_hispeed_delay - 30000 612000:20000 714000:20000
go_hispeed_load - 99
min_sample_time - 30000
V1.0 Lazy Values
target_loads - 75 408000:69 612000:80 714000:79 816000:80 918000:81 1020000:69 1326000:84 1632000:82 1836000:86
timer_slack - -1
hispeed_freq - 306Mhz
timer_rate - 20000
above_hispeed_delay - 30000 612000:20000 714000:10000
go_hispeed_load - 75
min_sample_time - 60000
Attached the latest profile for use with EX Kernel Manager for those that have it.
Place in Elemental X/gov_profiles and should appear in the app under gov options.
Please try out and let me know any feedback or issues with these settings, but everything should be stable as i have been running this for about 3 weeks now with no issues.
What other governors are available with the pixel kernel?
bill3508 said:
What other governors are available with the pixel kernel?
Click to expand...
Click to collapse
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
beardymcgee said:
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
Click to expand...
Click to collapse
Does the conservative governor have the touch boost option?
bill3508 said:
Does the conservative governor have the touch boost option?
Click to expand...
Click to collapse
nope nothing does
So no one interested in trying it?.....
beardymcgee said:
So no one interested in trying it?.....
Click to expand...
Click to collapse
Trying it now. Feels real snappy so far.
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
beardymcgee said:
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
Click to expand...
Click to collapse
I definitely think so. Ive never really been a big fan of interactive but until the 5x and 6p threads no one has really modified the values like that. I still haven't messed with any of the scripts folks are running on those devices but I may play around with the numbers some. Seems to be working great on the C. Thanks again.
So based on my usage I got 3 days of use with 9.5 hours SOT and 10% to go, would love to hear from more people if this did anything.
I just charged up so I'll let you know at the end.
Cheers for helping out, its sad that people would rather complain about software issues that will be fixed soon, than do the normal xda custom thing.
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
beardymcgee said:
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
Click to expand...
Click to collapse
I'll try the new values next charge up.
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
Root method has been fixed just don't flash su in twrp and follow the method in the twrp thread.
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
beardymcgee said:
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
Click to expand...
Click to collapse
But I doubt we would have the throttling problems that the 810 does so I could only see it as beneficial. Also the smaller cored would likely only improve already stellar battery life using setups like we're seeing on the 6p.
so I been reading the original thread and came up with 2 paths.
one using the original basic tuned method to have a nominal target speed for different functions like web browsing and video playback etc and increase the focus on these speed steps only while minimising the time on others.
or based on what the current recommendation in the "easy way" say to just use max efficient loads on each step
but as I have been tinkering too much i cant tell any more which is better so I have created a poll so please try these 3 version and vote on which is better
Hi everyone,
I've been reading this
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
and was wondering if anybody was interested and knew their way around to try and adapt these tweaks for our trusty htc ones?
Some n5x users (specifically those who tend to not game heavily or use the camera extensively) seem to reek performance boosts while also considerably extending SOT. The OP's tweaks got the attention (and as far as I know the support) of flar2 (elementalx kernel) considering he implemented the ability to apply profiles into his ex kernel manager specifically so the interactive governor settings could be applied more easily (unless I misunderstood something - correct me if I'm wrong on that). These tweaks can be made regardless of kernel or rom - the only prerequisite is the availability of the interactive governor. It may be something worth looking into and I'm willing to learn and test - I just kinda need someone to take me by the hand and help and explain because I feel a bit lost in regards to how to best proceed :silly:
What do you guys think?
over the next few days,im gonna be working on testing out some settings (of course following that guide)
if i get anywhere with them,i shall share them
That's great to hear, thank you :good: If I can be of any help please let me know!
These are my minimal settings for now based on my usage analysis . Will probably adjust them with battery performance this week.
Idle - 384000
Page Scrolling - 702000
Video - 918000
App Loading - 1134000
High Load Processing - 1728000 ( or 1566000 )
Sinistersky said:
These are my minimal settings for now based on my usage analysis . Will probably adjust them with battery performance this week.
Idle - 384000
Page Scrolling - 702000
Video - 918000
App Loading - 1134000
High Load Processing - 1728000 ( or 1566000 )
Click to expand...
Click to collapse
If this is a stupid question I apologise but how do you apply these in ex kernel manager (or equivalent app you use)?
antimatter.web said:
If this is a stupid question I apologise but how do you apply these in ex kernel manager (or equivalent app you use)?
Click to expand...
Click to collapse
This is my setup right now. Can someone who is working on this check if I did it correctly, I have some stuttering here and there so I think i'm missing something, since it should be buttery smooth and battery friendly.
Sinistersky said:
This is my setup right now. Can someone who is working on this check if I did it correctly, I have some stuttering here and there so I think i'm missing something, since it should be buttery smooth and battery friendly.
Click to expand...
Click to collapse
Thanks :good:
Again, I'm not sure about this, but I believe you shouldn't be needing to spend that much time at max. frequency. No idea how to get it down, but I feel like I did read something in the original thread. To me (as a fairly noob, layman forum user) that 32% seems high.
Have you seen any battery savings with your current setup?
antimatter.web said:
Thanks :good:
Again, I'm not sure about this, but I believe you shouldn't be needing to spend that much time at max. frequency. No idea how to get it down, but I feel like I did read something in the original thread. To me (as a fairly noob, layman forum user) that 32% seems high.
Have you seen any battery savings with your current setup?
Click to expand...
Click to collapse
Yea, I kinnda have. But Im still tweaking it. I just dont know how to bring down the frequency It's like I setup something wrong. I do have more battery life, but I think I can do even better. Just need the right values
Sinistersky said:
Yea, I kinnda have. But Im still tweaking it. I just dont know how to bring down the frequency It's like I setup something wrong. I do have more battery life, but I think I can do even better. Just need the right values
Click to expand...
Click to collapse
One follow up to my post on the N5X thread: (http://forum.xda-developers.com/showpost.php?p=66100620&postcount=2990)
set
highspeed freq to 810000 or 702000
go highspeed load to a value between 95 and 98
the first value on taget loads to 95 384... (90 or anything lower should be ok, too, doesn't matter much as this already is the lowest freq)
the target_load value for your highspeed freq (the value after the ":" ) to a value between 81 and 90
---Edit:
Oh, and: lower target_loads => earlier to the next freq => less laggy. You can tweak that behavior with the delays and timer rate, too
But: Many frequency changes / jumps => more lag
.hEiMDaLL. said:
One follow up to my post on the N5X thread: (http://forum.xda-developers.com/showpost.php?p=66100620&postcount=2990)
set
highspeed freq to 810000 or 702000
go highspeed load to a value between 95 and 98
the first value on taget loads to 95 384... (90 or anything lower should be ok, too, doesn't matter much as this already is the lowest freq)
the target_load value for your highspeed freq (the value after the ":" ) to a value between 81 and 90
---Edit:
Oh, and: lower target_loads => earlier to the next freq => less laggy. You can tweak that behavior with the delays and timer rate, too
But: Many frequency changes / jumps => more lag
Click to expand...
Click to collapse
Ok. So what happens if I don't set every frequency? I think I saw a EVO 4G thread with this and OP had only 3 freq set in the target_load ? Is that more efficient? So to make this have proper results, I need to change the numbers after ":" until i get the perfect results?
--Edit:
Ok. These are waaay better results than I ever had. Now the other frequencies are actually being used
Sinistersky said:
Ok. So what happens if I don't set every frequency? I think I saw a EVO 4G thread with this and OP had only 3 freq set in the target_load ? Is that more efficient? So to make this have proper results, I need to change the numbers after ":" until i get the perfect results?
Click to expand...
Click to collapse
It uses the target_loads you set for the lower freq. efficiency depends on the numbers it's less text to write if the loads are all the same for each freq...
The numbers behind the ":" (the target_loads) are only one part. the other settings like timer_rate and above_highspeed_delay have a huge impact on how fast the cpu reacts under load, too. sonicron described them very well in his guides.
---EDIT:
Seems you are on the right way with these values. Max freq still is used a bit to much, but I'm sure you'll find the best values after some tries. Took me hours, sometimes days to set up my profiles...
.hEiMDaLL. said:
It uses the target_loads you set for the lower freq. efficiency depends on the numbers it's less text to write if the loads are all the same for each freq...
The numbers behind the ":" (the target_loads) are only one part. the other settings like timer_rate and above_highspeed_delay have a huge impact on how fast the cpu reacts under load, too. sonicron described them very well in his guides.
---EDIT:
Seems you are on the right way with these values. Max freq still is used a bit to much, but I'm sure you'll find the best values after some tries. Took me hours, sometimes days to set up my profiles...
Click to expand...
Click to collapse
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them
Sinistersky said:
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them
Click to expand...
Click to collapse
I've read sonicrons first post a few times myself (as I'm very interested in the idea) but my technical knowhow stops at basic adb and recovery knowledge for flashing roms... May I bother you for the current values you are using? Sorry if I seem like I'm not trying - I am
antimatter.web said:
I've read sonicrons first post a few times myself (as I'm very interested in the idea) but my technical knowhow stops at basic adb and recovery knowledge for flashing roms... May I bother you for the current values you are using? Sorry if I seem like I'm not trying - I am
Click to expand...
Click to collapse
Yes, of course. You can have it, it's no bother. I'll attach my settings. However, these are not final. The phone jitters here and there, and I think the battery life is better by only a slight percent. I am hoping during hte next few days to find values that wil give more SoT and smooth performance. I will also need help with that
Sinistersky said:
Yes, of course. You can have it, it's no bother. I'll attach my settings. However, these are not final. The phone jitters here and there, and I think the battery life is better by only a slight percent. I am hoping during hte next few days to find values that wil give more SoT and smooth performance. I will also need help with that
Click to expand...
Click to collapse
Thanks for those I will apply those and see how they work for me. I'm currently using CM12.1 (Snapshot) and greenify for a few apps. What setup are you using?
If I can be of any help (I'm not going to pretend I will be of much) please let me know
Edit: I may have spotted an error: in the first line of target loads your second frequency should be 486000:60 not 48600:60, right? Could that be the reason for your jitters maybe?
antimatter.web said:
Thanks for those I will apply those and see how they work for me. I'm currently using CM12.1 (Snapshot) and greenify for a few apps. What setup are you using?
If I can be of any help (I'm not going to pretend I will be of much) please let me know
Edit: I may have spotted an error: in the first line of target loads your second frequency should be 486000:60 not 48600:60, right? Could that be the reason for your jitters maybe?
Click to expand...
Click to collapse
Yes, that is correct. I spotted it myself this morning. And the battery life has gotten insane. 8% in 1 hour of texting and screen on :highfive: So generally, this would mean about 8 hours of screen on time for sure.
--EDIT: Im using AICP with stock kernel and greenify and amplify
Sinistersky said:
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them
Click to expand...
Click to collapse
In short, the timer_rate is just the intervall after which the governor reevaluates the loads. So it doesn't affect which frequencies are used more, but how long it "waits" to check whether it should go up to the next freq. However, this is indirectly linked to the fact, that the device will stay at a lower freq for longer.
After the decision is made to change the freq, the next thing that keeps the cpu ramp up to the next freq instantly is the delay timer (above_highspeed_delay)
timer_slack defines the max additional time that can be added to timer_freq, thus the time to defer handling the governor sampling timer.
From kernel docs: [...] at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed.
For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed.
A value of -1 means defer timers indefinitely at all speeds. Default is 80000 uS.
here's the link to the document. Might come in handy https://android.googlesource.com/kernel/common/+/android-3.4/Documentation/cpu-freq/governors.txt
Questions are there to be asked and do not only help the one who asked the question, but the one who get's asked as well So asking and answering, both can be about learning something new, for both parties.
.hEiMDaLL. said:
In short, the timer_rate is just the intervall after which the governor reevaluates the loads. So it doesn't affect which frequencies are used more, but how long it "waits" to check whether it should go up to the next freq. However, this is indirectly linked to the fact, that the device will stay at a lower freq for longer.
After the decision is made to change the freq, the next thing that keeps the cpu ramp up to the next freq instantly is the delay timer (above_highspeed_delay)
timer_slack defines the max additional time that can be added to timer_freq, thus the time to defer handling the governor sampling timer.
From kernel docs: [...] at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed.
For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed.
A value of -1 means defer timers indefinitely at all speeds. Default is 80000 uS.
here's the link to the document. Might come in handy https://android.googlesource.com/kernel/common/+/android-3.4/Documentation/cpu-freq/governors.txt
Questions are there to be asked and do not only help the one who asked the question, but the one who get's asked as well So asking and answering, both can be about learning something new, for both parties.
Click to expand...
Click to collapse
Is there an app that I could use to determine instantly what load the CPU uses when I open chrome, or messenger or just scroll around?
I want to make it so I get a higher frequency on the app opening load, and a lower one on the idle and scrolling load. But if i for instance, set target_load 1566000:85, it uses the 1242000:89 for app opening I think, since it's kinnda laggier?
I can't get rid of these little jitters when switching screens, or apps I'm trying to learn what happens if I put higher numbers after ":" on certain mHz, does that make it so it stays longer on that mHz value or does it wait longer before it goes higher/lower to/from that mHz? And if so, would it be logical and less laggy to put something like 1242000:50 1350000:83 1458000:80 1566000:87 ( I'm guessing these frequencies are used the most when opening an app?)
Sinistersky said:
Is there an app that I could use to determine instantly what load the CPU uses when I open chrome, or messenger or just scroll around?
I want to make it so I get a higher frequency on the app opening load, and a lower one on the idle and scrolling load. But if i for instance, set target_load 1566000:85, it uses the 1242000:89 for app opening I think, since it's kinnda laggier?
I can't get rid of these little jitters when switching screens, or apps I'm trying to learn what happens if I put higher numbers after ":" on certain mHz, does that make it so it stays longer on that mHz value or does it wait longer before it goes higher/lower to/from that mHz? And if so, would it be logical and less laggy to put something like 1242000:50 1350000:83 1458000:80 1566000:87 ( I'm guessing these frequencies are used the most when opening an app?)
Click to expand...
Click to collapse
I use the overlays from DevCheck by flar2 and the process/cpu usage overlay one can enable in the developer options in settings. I guess there are plenty of tools/apps out there that do the same (I remember an app called "cool tool" which I had on my M7).
The jitters might get better when you change the delays (and/or timer rate to a lower value). setting the target_loads lower also helps, but you have to remember that the frequency might not be used at all (which is not a bad thing in general). When you set the load to eg. 40, the cpu will will go up to the next frequency as soon as the load under actual circumstances reaches 40%. As an example (with fantasy numbers): With a setting like 1000000:80 1100000:30 1200000:80, the 1100MHz might never be used at all when ramping up, cause the 80% at 1000MHz are already higher than 30% at 1100MHz. Of course, if the gap between those two frequencies would be higher (lets say 1000MHz and 2100MHz) the cpu might not be ulilized over 30% when coming from 80% at 1000MHz). Thats why you have to calculate the efficient loads, to find out what the most (power) efficient frequencies are, and give those a bit more "priority". You can do this by setting the target load higher on those (lower on the others)
I can't tell you what numbers (target_loads) you have to put in, I'd need the actual device to test how it performs under different loads with stock and tweaked settings.
.hEiMDaLL. said:
I use the overlays from DevCheck by flar2 and the process/cpu usage overlay one can enable in the developer options in settings. I guess there are plenty of tools/apps out there that do the same (I remember an app called "cool tool" which I had on my M7).
The jitters might get better when you change the delays (and/or timer rate to a lower value). setting the target_loads lower also helps, but you have to remember that the frequency might not be used at all (which is not a bad thing in general). When you set the load to eg. 40, the cpu will will go up to the next frequency as soon as the load under actual circumstances reaches 40%. As an example (with fantasy numbers): With a setting like 1000000:80 1100000:30 1200000:80, the 1100MHz might never be used at all when ramping up, cause the 80% at 1000MHz are already higher than 30% at 1100MHz. Of course, if the gap between those two frequencies would be higher (lets say 1000MHz and 2100MHz) the cpu might not be ulilized over 30% when coming from 80% at 1000MHz). Thats why you have to calculate the efficient loads, to find out what the most (power) efficient frequencies are, and give those a bit more "priority". You can do this by setting the target load higher on those (lower on the others)
I can't tell you what numbers (target_loads) you have to put in, I'd need the actual device to test how it performs under different loads with stock and tweaked settings.
Click to expand...
Click to collapse
Oh, so, if I understand this correctly, the number after ":" is like a roof. And when the CPU load hits that roof, it goes to a higher frequency, for example if i have 810000:81, as soon as the load goes to 81 it will switch to 918000, which is the next frequency ? And If i put 918000:90, it will stay on 918 mHz until the CPU load reaches 90? and then go to the next one? And the timer is just used to determine how long it takes to jump between the frequencies? So, what happens if I put 0 on the timers? Do they do it instantly? Does it take more battery life that way?