As we all know, the Snapdragon 810 processor in our OnePlus 2 phones is prone to overheat, especially during heavy tasks such as gaming. With the stock kernel (which probably most of you are using) this leads to the A57 cores being partially or fully shut down and the display - which generates additional heat - being dimmed in order for the phone to keep a healthy temperature (healthy for both its components and the hands that are holding it.) This, in turn, leads to lag when playing especially demanding games. Which in turn leads to a frustrated user.
With root access, it's possible to use custom kernels and/or custom thermal throttling profiles in order to (at least partially) circumvent these issues, by throttling the CPU frequency and/or limiting the number of active cores, using different schedulers and governors, and by applying thermal profiles that allow the phone to get hotter (in order to keep higher CPU frequencies for a longer duration).
Since I bought the OPT, I was playing a very power hungry game - Republique - which, at its highest graphics quality setting, pushes the phone to its limits. I quickly switched from the stock kernel to the Boeffla kernel and started experimenting with schedulers, governors, hotplugging settings, CPU/GPU frequencies and thermal profiles, but nothing I have done so far makes it possible to play the game for more than 15-20 minutes before some kind of throttling / heat control sets in and the game starts lagging.
I tried limiting both CPU clusters to only 2 cores while maintaining higher frequencies, I tried throttling the frequencies and keeping all 8 cores active, and I tried all kinds of solutions in-between with anything from 4-8 cores active and frequencies anywhere between 60% and 100%. I also tried the various thermal profiles that the kernel offers. But whatever I did, the game was either lagging right from the start, or running smoothly for about 15 minutes before the screen was dimmed and the CPU was throttled, leading to a laggy experience.
So my question is, what do you guys do to keep the OnePlus 2 from overheating during gaming, while at the same time maintaining a lag-free experience? I don't seem to get anywhere with anything I try, so I'd be extremely grateful for some useful input.
vonotny said:
As we all know, the Snapdragon 810 processor in our OnePlus 2 phones is prone to overheat, especially during heavy tasks such as gaming. With the stock kernel (which probably most of you are using) this leads to the A57 cores being partially or fully shut down and the display - which generates additional heat - being dimmed in order for the phone to keep a healthy temperature (healthy for both its components and the hands that are holding it.) This, in turn, leads to lag when playing especially demanding games. Which in turn leads to a frustrated user.
With root access, it's possible to use custom kernels and/or custom thermal throttling profiles in order to (at least partially) circumvent these issues, by throttling the CPU frequency and/or limiting the number of active cores, using different schedulers and governors, and by applying thermal profiles that allow the phone to get hotter (in order to keep higher CPU frequencies for a longer duration).
Since I bought the OPT, I was playing a very power hungry game - Republique - which, at its highest graphics quality setting, pushes the phone to its limits. I quickly switched from the stock kernel to the Boeffla kernel and started experimenting with schedulers, governors, hotplugging settings, CPU/GPU frequencies and thermal profiles, but nothing I have done so far makes it possible to play the game for more than 15-20 minutes before some kind of throttling / heat control sets in and the game starts lagging.
I tried limiting both CPU clusters to only 2 cores while maintaining higher frequencies, I tried throttling the frequencies and keeping all 8 cores active, and I tried all kinds of solutions in-between with anything from 4-8 cores active and frequencies anywhere between 60% and 100%. I also tried the various thermal profiles that the kernel offers. But whatever I did, the game was either lagging right from the start, or running smoothly for about 15 minutes before the screen was dimmed and the CPU was throttled, leading to a laggy experience.
So my question is, what do you guys do to keep the OnePlus 2 from overheating during gaming, while at the same time maintaining a lag-free experience? I don't seem to get anywhere with anything I try, so I'd be extremely grateful for some useful input.
Click to expand...
Click to collapse
All the phones throttle while gaming. I use thermal extreme with boeffla kernel. And use 2 a53 at 1,3ghz and 2-4 a57 at 1,4ghz and I modified the throttle file and it underclock to 1,2ghz when it gets hot but it doesn't happen if you don't play longer than 30minutes and it doesn't lag either. You can leave stock settings but if course it will get hot quicker. Also with thermal hotplugged or something like that, I used it all cores online all the time at full speed and it doesn't throttle for a long time, so I don't know what overheating are you talking about. My nexus 5 throttle faster and disable 2 of 4 cores and leave the other 2 at half speed, and our processor overheats?. Oneplus throttle the device a lot because of the rumors, fortunately we can change that. Try what I said, cheers.
Sent from my ONE A2005 using Tapatalk
Migdilu said:
All the phones throttle while gaming. I use thermal extreme with boeffla kernel. And use 2 a53 at 1,3ghz and 2-4 a57 at 1,4ghz and I modified the throttle file and it underclock to 1,2ghz when it gets hot but it doesn't happen if you don't play longer than 30minutes and it doesn't lag either. You can leave stock settings but if course it will get hot quicker. Also with thermal hotplugged or something like that, I used it all cores online all the time at full speed and it doesn't throttle for a long time, so I don't know what overheating are you talking about. My nexus 5 throttle faster and disable 2 of 4 cores and leave the other 2 at half speed, and our processor overheats?. Oneplus throttle the device a lot because of the rumors, fortunately we can change that. Try what I said, cheers.
Sent from my ONE A2005 using Tapatalk
Click to expand...
Click to collapse
Thanks for the tip with thermal extreme! The implementation in the latest Boeffla kernel v1.1 beta1 seem to do a very good job of not letting the phone get too hot while at the same time not throttling the CPU too much. Today, the performance was stable for almost 30 minutes of gaming, and when I checked the CPU stats I saw that all cores were still active (2x A53 + 4x A57), and only throttled to 960 MHz. This still delivered enough performance. (I started the game with both CPU clusters at 1.2 GHz, so this also seemed to help with keeping the phone at an acceptable temperature. I'm sure it would've gotten much hotter much quicker at higher CPU frequencies.)
I have to admit though, I was playing inside in an unlit room and thus the screen wasn't at max. brightness. We'll see how it will perform during my next work break when I have to make the screen much brighter.
vonotny said:
Thanks for the tip with thermal extreme! The implementation in the latest Boeffla kernel v1.1 beta1 seem to do a very good job of not letting the phone get too hot while at the same time not throttling the CPU too much. Today, the performance was stable for almost 30 minutes of gaming, and when I checked the CPU stats I saw that all cores were still active (2x A53 + 4x A57), and only throttled to 960 MHz. This still delivered enough performance. (I started the game with both CPU clusters at 1.2 GHz, so this also seemed to help with keeping the phone at an acceptable temperature. I'm sure it would've gotten much hotter much quicker at higher CPU frequencies.)
I have to admit though, I was playing inside in an unlit room and thus the screen wasn't at max. brightness. We'll see how it will perform during my next work break when I have to make the screen much brighter.
Click to expand...
Click to collapse
Does it throttle to 960mhz? for me never reach 1,2ghz. Playing real Racing for 30min it stays at 1,2ghz. And with thermal hotplugged (all cores enabled, all at stock freq gpu too) it doesnt throttle for 30 min, gpu only sometimes to 510mhz, i played 30 minutes and it didnt throttle, i dont know when it was going to throttle because i stop playing. But also, gaming with all cores and no throttling eats the battery.
Migdilu said:
Does it throttle to 960mhz? for me never reach 1,2ghz. Playing real Racing for 30min it stays at 1,2ghz. And with thermal hotplugged (all cores enabled, all at stock freq gpu too) it doesnt throttle for 30 min, gpu only sometimes to 510mhz, i played 30 minutes and it didnt throttle, i dont know when it was going to throttle because i stop playing. But also, gaming with all cores and no throttling eats the battery.
Click to expand...
Click to collapse
I guess it throttled to 960 MHz because the game I'm currently playing (République) is pretty resource hungry.
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
Update: The Aroma installer should work again. You can also only use the v1.6 (it installs the recommended extreme profile and doesn't need the aroma installer). Thanks @Seyaru and @yochananmarqos
Make sure to backup your orignal thermal-engine. I attached it just in case.
Update: It seems as there is a hardcoded limit for the thermal throttling of the big cluster (may be kernel related). That means that the profiles above extreme decrease the performance instead of increasing it (they only prevent the big cluster from going offline, even though it is not utilized any more)
Update: Zip now supports magisk! thanks @tohtorin and @yochananmarqos for the new updated zip
Update: now with a flashable zip that supports both system and systemless root! thanks @tohtorin for that zip
Instructions for the zip install:
Instructions:
magisk:
Installing/Updating Magisk to a new version:
Download Magisk via the Manager, but do not flash it
Reboot to recovery, flash the stock boot.img to clear the ramdisk
Flash Magisk before the custom kernel so it creates a backup of the stock boot.img just in case
Flash the custom kernel (ElementalX in my case) and reboot
Installing the module:
You have to have Magisk installed (for more information see Magisk thread).
Flash magisk-thermal_tweaking_v1.6.zip (installs the recommended extreme profile by defaullt)
If you want another profile, flash "thermal_tweaking_systemless_v1.2.3.zip" and selecet "Magisk" as installation type
Enjoy your flying hot potat.. phone
You can still use the installer without magisk. In that case, ignore step 1 and 2 and do NOT select magisk as installation type.
Also, if you are using elemental/franco kernel, don't forget to enable core control, disable msm_thermal and set "throttling temp" according to the profile
Click to expand...
Click to collapse
Hello and welcome!
Do you like shiny graphics but your phone does not? Do you sometimes wonder why the Nexus 5X has a big cluster that's offline almost the entire time? Tired of lags and stutters? Well, search no more. The solution is right around the corner!
Attention: Setting these values too high can cause damage. I'm not responsible if this fries your phone or burns down your house.
Update: It seems like there is a hardcoded limit, see above.
If you don't want to tweak the settings yourself, you can scroll down to the recommended settings section.
Note: Right now this has only been tested on elemental and franco kernel with core control enabled (msm_thermal does nothing). I will update this as soon as I have some information from the kernel devs.
update: francokernel has the same settings regarding hotplug, so you need to enable core control and set the thermal limit with a kernel manager
update: don't know about phasma yet. It seems to work with phasma
update: have not tried this with stock kernel, but it should work
update: this will not work with jolla kernel since it has it's own thermal tweaks and does not use the thermal-engine
update: racer kernel now works and has the extreme_v4 profile implemented
Let's first try to understand the thermal throttling of the Snapdragon 808. Here is a comparison of thermal throttling on several 808 devices. The LG G4 throttles much later at much higher temps, and as a result gets alot warmer on the outside. Since the Nexus 5X uses the same SoC, it should be safe to increase the thermals. However, you have been warned!
Before you can get started, you need root access and a root explorer. The file we want to edit is named "thermal-engine-8992.conf" and can be found in "system/etc". Permissions have to be rw- r-- r--
We can easily influence the following behaviors (I'm only showing the relevant lines, not the entire file). A reboot is required after applying changes.
Hotplug temp, Temperature at which the big cluster will be taken offline:
This should be set at the same temp as the throttle temp of the big cluster. It must never exceed it by more than 2°C or you will loose performance!.
Note: On elemental/franco kernel, enabling "core control" in a kernel manager, and setting a "thermal throttling" limit, overrides this setting. Disabling core control disables hotplugging altogether, so the cores will never shut off (don't do this)!. So, if you are using elemental/franco kernel, set core control to enabled and set your desired hotplug temp in the kernel manger. The values below have no effect on elemental/franco kernel. This behavior was only tested on elemental kernel. Only If you are on stock kernel you will need to edit those lines.
Note2: using "msm_thermal" in a kernel manger overrides this setting with "infinte" so the core never shuts down (don't do this). Msm_thermal seems to have no effect on the Nexus 5X.
Code:
[CPU4_HOTPLUG_MONITOR] and [CPU5_HOTPLUG_MONITOR]
thresholds [B][COLOR="Blue"]41[/COLOR][/B]000
thresholds_clr [B][COLOR="Blue"]39[/COLOR][/B]000
The bold blue digits represent the temperatures in °C. Threshold means the temp to shut down, threshold_clr the temp to go online again. The higher these digits, the longer the big core will be usable by the phone (but only as long as the throttle temp is not more than 2°C lower). The difference between the two temps should be at least 2°C.
Throttle temp of big cluster, Temp at which the big cluster starts to throttle it's clock:
This should not be higher than the hotplug temp of the big cluster
Code:
[PID-BIG_CLUSTER_management]
set_point [B][COLOR="blue"]39[/COLOR][/B]000
set_point_clr [B][COLOR="blue"]37[/COLOR][/B]000
At the set_point a PID algorithm will be used to throttle the CPU step by step. The set_point_clr determines how soon the the clock speed will increase again. Keep at least 2°C between those two. Increasing these temps will allow the big cluster to be utilized longer at higher clock speeds.
Throttle temp of little cluster:
Code:
[PID-LITTLE_CLUSTER_management]
set_point [COLOR="Blue"][B]44[/B][/COLOR]000
set_point_clr [COLOR="blue"][B]41[/B][/COLOR]000
Determines when the little cluster will be throttled. Keep 3°C between the temps.
Throttling of the GPU:
Code:
[SS-GPU_management]
set_point [COLOR="blue"][B]44[/B][/COLOR]000
set_point_clr [COLOR="blue"][B]41[/B][/COLOR]000
Same as above. 3°C difference.
LCD brightness reduction:
Code:
[LCD_management]
thresholds [COLOR="Blue"][B]36[/B][/COLOR]000 [COLOR="blue"][B]39[/B][/COLOR]000 ...
thresholds_clr [COLOR="blue"][B]34[/B][/COLOR]000 [COLOR="blue"][B]37[/B][/COLOR]000 ...
Now this works slightly differntly. The threshold and threshold_clr works the same. But this time we have every step as it's own line. If you want to increase the temp at which the screen starts to reduce it's brightness by 2°C, you would need to raise every threshold and threshold_clr in this category be 2°C. As usual keep 2°C between the temps.
update:
battery charging current reduction.:
Code:
[battery_monitor]
thresholds [COLOR="royalblue"][B]40[/B][/COLOR]000
thresholds_clr [COLOR="royalblue"][B]38[/B][/COLOR]000
If you want to increase the temperaure at which the phone reduces its charging rate, you can raise the blue values. I would not recommend anything higher than 4°C.
Recommended Settings:
How to use:
update: back online, please uninstall the old version and install the new one (only for systemless)!: @tohtorin and @yochananmarqos have created a nice zip with Aroma installer. It can install the engine with a classical system install (overwrites the file in system/etc) or a systemless method, that does not touch your system partition. You only need the v1.6 to install the extreme profile. That means you can still apply OTAs and won't even lose the thermal tweak (as long as you have systemless root working).
You can grab the file and the uninstaller (can also be uninstalled via magisk manager) in the attachements below. Just flash it, no need to wipe anything. If you are using elemental/franco kernel, you still need to enable core control, disable msm_thermal and set the value for thermal-throttling to the appropriate setting (see profiles below) in EXkernel manager.
Note: If you have installed the script via system-method (or manually replaced/edited your thermal-engine) the systemless install will not work. In order to use the systemless version, you will need to have the stock thermal-engine in your system/etc.
Old:
Either edit the file yourself or download the attachement. Rename it to "thermal-engine-8992.conf", copy/overwrite it to "system/ect" and set permissions to "rw- r-- r--". Enable core control and set the thermal limit accordingly (elemental/franco). Reboot after editing/replacing.
Using these thermal-engine tweaks does not necessarily decrease battery life. It only negatively impacts battery life if you are using the phone for so long or so heavily, that it would throttle or shut off the big cluster (or GPU/screen brightness) with stock settings.
Normal user:
Not playing graphically demanding games or doing CPU heavy workloads? Try this setting. With this, the big cluster will be online almost the entire time while "normally" using the phone. Also, this will not increase the maximum phone temperature so it should be almost risk-free.
only on stock kernel: hotplug big cluster 46/44
elemental/franco: core control enabled ; "thermal throttling" in kernel manger to 46
any: throttle big cluster 46/44
Gaming:
Like those shiny graphics? Most games need lots of GPU power but are actually not that demanding on the CPU side. So the little cluster should provide enough horsepower. For this we need to raise the phone's maximum temperature limit, so it will get noticibly slightly warmer. With this, the GPU has alot more breathing room and will run at higher speeds for a longer time. This may be increased even more, because the G4 has even higher values (Moto X doesn't throttle GPU at all)
only on stock kernel: hotplug big cluster 43/41
elemental/franco: core control enabled ; thermal throttling" in kernel manger to 43
any: throttle big cluster 43/41. So you have a better experience during "normal" use
any: little cluster throttle 47/44 ; GPU throttle 47/44
heavy duty: update v5
Think you can handle the heat? No Less of a compromise in daily use and increased gaming performance with a brighter screen. This will turn your phone into a hot beast a slightly warmer phone.
update v2: increased the hotplugging temp of the bigs for longer usage.
update: heavy_v2 fixed now (it was the same as v1, sorry for that)
update v3: Increased throttle temp for the littles. They throttled too soon after longer usage.
update v4: I decided to increase the temperature at which the charging current gets reduced since it is pretty low. Increasing it by 4°C should be safe. This will still not rapidly charge your phone during navigation or gaming, though. However, with light usage such as browsing this will increase the charging rate.
update v5: fixed a wrong value for big cluster throttle clear temp (was 46, should be 47)
stock kernel: big hotplug 46/44 v2 49/47
elemental/franco: core control, limit 46 v2 49
any: LCD 38/36, 41/39, 44/42, 47/45
any: little throttle 47/44 v3 49/47
any: big throttle 46/44 v2 49/47
any. GPU throttle 47/44
any: battery monitor 40/38, 43/42
extreme
update v4: Been using this for many days months now. Even under heavy load the phone is not uncomfortably hot. Didn't have any problems so far.
Not for the faint of heart! This pushes the phone even further than heavy. These settings are still below those of the LG G4, but are significantly higher than stock. Only for those who like it hot.
update v2: Increased the throttle temp of the big cluster. Throttling under medium/heavy load can cause lag. So now it doesn't throttle much before it goes offline. This results in a more fluid experience and smoother transition between big->little cluster.
update v3: I decided to increase the temperature at which the charging current gets reduced since it is pretty low. Increasing it by 4°C should be safe. This will still not rapidly charge your phone during navigation or gaming, though. However, with light usage such as browsing this will increase the charging rate.
update v4: Increased the little cluster throttle temp. Before this the littles throttled too soon under heavy usage.
stock kernel: big hotplug 51/49
elemental/franco: core control, limit 51
any: LCD 40/38, 43/41, 46/44, 49/47
any: little throttle 49/46 v4 51/48
any: big throttle 48/46 v2 51/49
any. GPU throttle 49/46
any: battery monitor 40/38, 43/42
Update: The Profiles above extreme are outdated and do not work properly.
Thanks:
@RogerF81, @GoldGanja for making me aware of the thermal-engine, @flar2, @franciscofranco, @tohtorin for that awesome Aroma installer that supports systemless root, @yochananmarqos, @Seyaru for the new updated magisk zip
Did I forget you? Just PM me and I'll add you
I have attached the default thermal-engine of the Nexus 5X below for anyone who needs it.
This is some good **** right here. Between this and the governor profiles, this is the best community effort I've ever seen to improve a device. And the difference is extraordinary. I cannot wait to see how some of these changes play along with the Interactive Governor Profiles. Love all of the work you've put into researching the throttling behaviors on this device. Keep it up bro!
There is a flashable zip for 5x ?
Inviato dal mio SM-T715 utilizzando Tapatalk
little cluster throttle 47/44 ; GPU throttle 47/44
Click to expand...
Click to collapse
47??? It will throttle always! I can understand 70..75* (and at least 50* for the big cluster), but not 47.
siealex said:
47??? It will throttle always! I can understand 70..75* (and at least 50* for the big cluster), but not 47.
Click to expand...
Click to collapse
What? Could you imagine how hot the outside of the phone would become? These aren't air/liquid cooled desktop CPUs these are tiny passively cooled ARM CPUs crammed into a hunk of plastic and other chips and radios that get just as hot, sandwiched between a battery that can reach 40+ Celsius and an LCD screen. Trust me, you don't want your CPU or any other part of your phone approaching those temps.
is it possible to look into this same info for the 6P? It has that same file but the info inside the file is not the same as the 5X. Thank you
siealex said:
47??? It will throttle always! I can understand 70..75* (and at least 50* for the big cluster), but not 47.
Click to expand...
Click to collapse
The LG G4 throttles the GPU at 48°C, the big cluster at 45°C and the little cluster at 53°C. As a result, the outside temps are 7°C higher (44) than the Nexus 5X's (37). I would consider this uncomfortably hot. Also, the G4 might (or not) have better thermal conduction from the inside to the outside, because of different materials, but we don't know that.
You are welcome to try higher values and report your results. The G4 has an emergency shut down if temps get too high, the 5X probably has it, too.
chiahead52 said:
is it possible to look into this same info for the 6P? It has that same file but the info inside the file is not the same as the 5X. Thank you
Click to expand...
Click to collapse
Sure, but I don't have a 6P so I would need someone to send me the thermal engine.conf someone already did this for the Nexus 6P
tony.quartararo said:
There is a flashable zip for 5x ?
Inviato dal mio SM-T715 utilizzando Tapatalk
Click to expand...
Click to collapse
I don't think a flashable .zip is neccessary, because you only need to change a few lines. It's faster and easier than booting to recovery and installing the .zip. Also, you have much more flexibility by editing it yourself.
I will upload some predefined files later, so you just need to replace them and set permissions.
OP update 1
5x has one of the colder skin temperatures (37.4 degrees C max) compared to other high end Android devices. So there should be lot of breathing room for increasing thermals if you don't mind the added heat in your hand.
For instance the Nexus 5 skin temperature went up to 45 degrees C and then performance crashed hard due to heavily throttling the CPU and GPU.
bblzd said:
5x has one of the colder skin temperatures (37.4 degrees C max) compared to other high end Android devices. So there should be lot of breathing room for increasing thermals if you don't mind the added heat in your hand...
Click to expand...
Click to collapse
I generally agree, but it's hard to compare two phones, even if the use the same SoC (G4/5X). Different materials and component placement inside and outside of the phone can affect the results heavily.
Still, I believe raising the Nexus 5X's thermals by a few degrees won't hurt anything, but makes a great difference in sustained performance.
How does the 'thermal throttling' setting in EXKM relate to all this?
Smultie said:
How does the 'thermal throttling' setting in EXKM relate to all this?
Click to expand...
Click to collapse
I updated the main post:
The thermal throttling in kernel managers only changes the hotplug temp of the big cluster. On franco and elemental kernel anyway (don't know about phasma or stock). On elemental/franco, core control has to be enabled, otherwise your big cores will be either online or offline forever.
Interesting, I have been setting thermal limit to like 70C in ex manager with Elemental kernel. 46 is ungodly low and I have no idea why the default is that. Sitting on a cold desk doing nothing you can load the proc up to 60c in seconds..
xecuter2 said:
Interesting, I have been setting thermal limit to like 70C in ex manager with Elemental kernel. 46 is ungodly low and I have no idea why the default is that. Sitting on a cold desk doing nothing you can load the proc up to 60c in seconds..
Click to expand...
Click to collapse
Without changing the throttle temp of the big cluster, increasing the hotplug temp hurts performance. As soon as the big cluster reaches the low end of it's throttling algorhitm, it is no lnger utilized. So it sits around at it's min frequency doing nothing but heating up the phone.
The core temperature (can jump to 90°C) says nothing about how soon the CPU is throttled. I'm not sure which temp is responsible for throttling. EXM shows a total of 16 temps, it has to be some of the lower temps. Doesn't matter which it is, though.
This is great man! Thank you for that! It's a big step for improving our phones
I am using the heavy config file. What value should i use in EXM for thermal throttling? Should i leave it at 44 as previously recommended or a higher value? Does it interferes with the values already set in the config file? Thank you!!
neinfricatu said:
I am using the heavy config file. What value should i use in EXM for thermal throttling? Should i leave it at 44 as previously recommended or a higher value? Does it interferes with the values already set in the config file? Thank you!!
Click to expand...
Click to collapse
What kernel are you using? On elemental and franco the "thermal throttling" setting in the kernel manager overrides the values in the thermal-engine for the big cluster only.
In that case set core control to enabled and set thermal throttling to 46.
The recommendation of the 44 throttle temp in a kernel manager still holds true for completely stock settings.
Razorless said:
What kernel are you using? On elemental and franco the "thermal throttling" setting in the kernel manager overrides the values in the thermal-engine for the big cluster only.
In that case set core control to enabled and set thermal throttling to 46.
The recommendation of the 44 throttle temp in a kernel manager still holds true for completely stock settings.
Click to expand...
Click to collapse
I am using elementalx. Thanks!
Did some tests with Antutu. Compared the stock settings with my "normal" config.
ambient temperature 22°C
Code:
stock first run total 65591 CPU 15583
stock third run total 53800 CPU 11053
normal first run total 71362 CPU 19492
normal third run total 65239 CPU 16226
This should be enough for most "normal" users.
Here is a flashable .zip of the normal values 44/46
Credits goes to Razorless for the settings and RogerF81 for his flash routine (hope it's Ok)
Work this fhashable zip ?
Inviato dal mio Nexus 5X utilizzando Tapatalk