Hello android fellas..i am an sgs 2 owner and a log time android user..for the most of android devices the most screen time i could ever get is 5 hours (screen on, not idle..idle means ntn..with uv i can get week++)..
So the question i rise here is, will ice cream sandwitch help our battery effeciency with hw acceleration?i noticed that my phone can do as much as 10 hours+ of video playback, but can only surf the web for around 4-4,5 ...which is amazingly ridiculous..if i let the phone idle , with screen turned on, at all times(there are actually apps to do that) i can get almost 11 hours of screen on time..but if i use my phone to as much as navigate through menus, i am lucky if i get 30% of that time.
That led me to the conclusion that cpu usage for 2d ui elements drawing is at best idiotic, but other than that, its that its not my device(s) problem..its the os that sucks it up..
So, do you believe, that ICS will fix that?is there hope on the horizon?4 hours screen on time/day , just wont cut it for a tought work day for me..
( i would like to close that section by saying that i am a 2 year android user and i know what i need to shut down, when to have on and what so that my batt is at its max effeciency..)
Opinions please? Will our GPUs make us look less embarassing?
Unlikely... partially, because the majority of actions needed by a web browser is unable to utilize the GPU (it's really only usable for compositing and rendering, which occurs surprisingly seldom outside of games: really only while the document loads... of course that's bound to change at some point, but for now, there really isn't much to gain other than more fluid animations), but mostly because it's a bit of an unfair comparison: Video playback today is more or less handled by special-purpose silicon, not what you'd usually call "The GPU".
Hans Schmucker said:
Unlikely... partially, because the majority of actions needed by a web browser is unable to utilize the GPU (it's really only usable for compositing and rendering, which occurs surprisingly seldom outside of games: really only while the document loads... of course that's bound to change at some point, but for now, there really isn't much to gain other than more fluid animations), but mostly because it's a bit of an unfair comparison: Video playback today is more or less handled by special-purpose silicon, not what you'd usually call "The GPU".
Click to expand...
Click to collapse
no, i am aware that java still needs to be rendered in cpu... but i was not only bein referred to in browsing...menu browsing as well..ui navigation should be humongousl benetited am i right?
Accelerated is usually faster and smoother, especially multiple layers benefit greatly from additional acceleration (note however, that Android already uses that in most cases)... it just doesn't really translate to power saving.
Java doesn't really have anything to do with that: it may put a bit of additional load on the CPU, but that's not what's eating your battery, especially since virtually all computation-intensive parts of Android are written in C++. The real problem is that while the GPU is faster in these "burst" situations when there's suddenly a whole lot of layers to render, it's hard to predict those. So the CPU most always run at an acceptable rate... which in the end often means that the accelerated version uses more power since the system isn't able to clock down the CPU nor the GPU.
Hans Schmucker said:
Accelerated is usually faster and smoother, especially multiple layers benefit greatly from additional acceleration (note however, that Android already uses that in most cases)... it just doesn't really translate to power saving.
Java doesn't really have anything to do with that: it may put a bit of additional load on the CPU, but that's not what's eating your battery, especially since virtually all computation-intensive parts of Android are written in C++. The real problem is that while the GPU is faster in these "burst" situations when there's suddenly a whole lot of layers to render, it's hard to predict those. So the CPU most always run at an acceptable rate... which in the end often means that the accelerated version uses more power since the system isn't able to clock down the CPU nor the GPU.
Click to expand...
Click to collapse
Damn..The load that cpu took from being less effecient to draw 2d, was my best explaination as to why our batteries suck so much..
It is definately not the phones..As i said earlier if i let the phone screen on, just idling, at, say auto brighness, it can go for 10-11 hours..but if during that time i, as much as navigate at menus, or settings , or whatever ui...BAM..4-5,5 hours maximum..
It HAS to be something wrong with the os..heck i can do 10 hours of .avi playback on a single charge , but i cannot go over 5 for just panning around the app drawer..(and my screen is amoled so it greatly benefits from black background of the drawer)...
If you could shed some light to that, for me i'd love ya even more!
Btw on my second post i meant to type javascript, not java my bad!
(Scroll down to The Money Shot if you just wanna know the settings to use and skip all my preamble, but be aware that you may sacrifice results if you don't understand everything fully! You've been warned!!)
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?! I'm talking about 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! 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 EvoLTE, 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.
The Background
I got my first Android phone (Galaxy S4) about 8 months ago, and after dropping it in the toilet a couple months ago, I had to get something cheap. Enter the EvoLTE.
Performance on the EvoLTE was not what I was used to, and that disappointed me. (I should rephrase. Performance while getting similar battery life was disappointing. What good is a fast phone if you can't use it cuz it's dead?) While I had immediately caved and ROOTed and installed a new ROM (CM 10.2), I soon pined for a new kernel with promises of overclocking, under-volting, new fangled governors, etc.
So, I S-OFFed and installed Haunted Kernel. Played with overclocking, used the suggested governor (smartmax), under-volted, all that jazz. One problem: constant reboots. My focus shifted from performance and battery to just getting it to run reliably.
To my dismay, I learned that my phone has no tolerance for overclocking, so I lost that speed boost. Further, it has no tolerance for under-volting, so I lost that power savings. And then I discovered the recommended governor (which gave pretty good battery life and so-so performance) was too buggy to be reliable, so I lost that balance.
I was never fully satisfied with the performance of that governor. It promised a lot. People raved about it. It was certainly very power-friendly and lag free, but it stuttered. Notice how everyone promises lag free, but rarely do they talk about smoothness as things slow down. You know what I mean... quick scroll through a webpage or list, and as it slows down it hops and jerks. I hate, hate, HATE that! But hey, you can't have all three--smoothness, snappiness, and stutter-free... right?
Wrong! (But I'm getting to that!)
Shifting back to stock CPU settings (clock speed and voltages) I turned my focus to the governors. Surely, I thought, one of these other fancy governors will satisfy my needs. But after weeks of tweaking and testing, I had to make a compromise in one way or another. None of them delivered the results I wanted, no matter how I tweaked them. They were better than the standard governors in many ways, but still didn't meet my expectations. I sat there, so disappointed. All these cool features to boost performance, save battery, all that... out of my reach. I was back to square one. Stock speeds, stock voltages, basic governors...
Basic governors...
...basic governors...
...basic governors..?!
Well that's something I hadn't looked into much, I thought.
I mean, why bother? Either they keep your CPU at a low clock speed, or a high one, or slowly scale between the two, or jump quickly between the two. Pretty basic stuff. The new fangled governors were designed to more efficiently finesse these brute choices to improve performance and battery life, so what would basic governors have to offer?
Nothing, I thought. Until I looked at the kernel source and realized that the Interactive Governor had some advanced features I'd never seen anyone use in their recommended settings. On any forum. Ever.
That's not to say it's some well-kept secret or that I'm the first person in the world to post about such things. But it's certainly not widely known or promoted well. Most people just jump onto some new fangled governor with default settings to provide some features that, in all honesty, we can find in a governor featured in practically all kernels, and actually may out-perform the new fangled governor in both performance and battery life!
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 an EvoLTE. This will work on any ROOTed phone with the Interactive governor!
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 decompressing 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 both cores 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, and multiply that clock speed by your number of cores.
For example, on my EvoLTE, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the both CPUs clock rates are no less than 432Mhz. (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.) Because the EvoLTE has 2 cores, we multiply 432Mhz * 2 = 864Mhz. Thus, the nominal clock rate for scrolling a webpage on my EvoLTE is 864Mhz.
Now, here's the rub. If you turn off one of the cores and turn the other core to 864Mhz, you will not find that it is smooth anymore. I will not write a dissertation regarding why this is the case. Suffice it to say, despite what is often incorrectly conveyed, multi-core usage is more efficient in multi-dimensional processing loads--such as rendering graphics, playing sound, or decoding video--than a single core's performance because the time spent at a given clock rate is non-linearly less than if it were processed on a single core at a higher frequency. We want a balance of battery life and performance, and that requires using both cores. The other core will kick on when necessary to "fill in the gaps" under such a load, so our measurement stands. For our purposes, the nominal frequency for a given task is the sum of the frequencies of all cores always on at a given clock rate.
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.
Using stock voltages, the EvoLTE's efficient clock rates are:
384Mhz
702Mhz
1026Mhz
1512Mhz
These are the clock rates that are at the top tier of each of their voltage ranges, before each anomalous ratio jump. These are the most voltage efficient clock rates using stock EvoLTE voltages. If you are using a custom kernel or have changed your voltages (or a totally different phone altogether), your efficient clock rates may be different. Calculate them as applicable to your setup! List the clock rate differences between each frequency step and the differences for each frequency's voltages. You will see an anomalous voltage jump every several frequency steps. The frequency before this jump is the next efficient clock rate. Write it down and keep going through the frequency steps until you have exhausted them.
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 am using stock voltages, I use the efficient clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 189Mhz
Page Scrolling - 864Mhz
Video - 1134Mhz
App Loading - 1350Mhz
High Load Processing - 1512Mhz
(Note that my nominal idle speed is less than stock. This is why 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!)
Once you've listed all of your nominal clock rates, try to consolidate them if you have more than 3. (This is not entirely necessary as you'll see later, but it simplifies things significantly until you're more comfortable dictating more than a few clock rates for your needed task loads.) If you have any tasks that rest in the far upper portion of the frequency spectrum, discard them! We are by no means underclocking anything, but we are trying to keep the CPU clock rate as low as possible for as long as possible. However, the fastest frequencies will be available for sustained load processing, as you will see later. In my case, in addition to discarding the "high load processing", I'll sacrifice a (very) little app loading speed and consolidate video and app loading:
Idle - 189Mhz
Page Scrolling - 864Mhz
Video/App Loading - 1134Mhz
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:
Idle - 189Mhz efficient / 189Mhz nominal
Page Scrolling - 710Mhz efficient / 864Mhz nominal
Video/App Loading - 1026Mhz efficient / 1134Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient 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 702000:60000
"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 702Mhz. (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!)
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 an EvoLTE, use the following Interactive governor settings and then tweak with the instructions below:
(If you are using a phone other than an EvoLTE, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000 702000:60000 1026000:150000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 384000
io_is_busy - 0
min_sample_time - 40000
target_loads - 98 384000:40 702000:80 1026000:95
timer_rate - 30000
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 710Mhz/864Mhz rates, 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 "710000" 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.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
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.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
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 EvoLTE, 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!
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Great article!
jmkarnai01 said:
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I was wondering the same thing.
jmkarnai01 said:
Really nice write up! Easy to read and understand. One question, how exactly are you changing the above high-speed delay. I input exactly but when I save and go back it's bank only to 20000
Sent from my EVO LTE using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I use the the fku updater app the paid version and all my settings stick on my g3 and my m8
Nice write up. Just the sort of info I've been looking for
Well done sir
Great information here!
Finally someone makes complete guide on this governor
hello..i am not an advanced user like you guys..great work !..i try my best to understand,i read threw every word,even though i dont have your device.i am useing a htc m8 on sprint..i flashed the kernal after reading all about it..i do want amazeing battery life,i work all the time,constantly networking and listening to music,useing data all the time really,i understand these things will kill battery no matter what..i also know you said if we have abother device other than the evo the device you laid out exact settings for,we would have to tweak on our own..and without you haveing the device i have im sure be hard to give some advice..couple questions?- 1.)if i just use default settings,and change nothing will it benifit me at all,or did i just flash the kernal for nothing,since im not advanced enough to really tweak kernal on my own..2)is there anyway possible to get exact instrutions for my device like you gave for the evo...just wanted to add how lucky users of that device are for you to of givein these details,you seem to of really mastered that device..thanks for hard work either way..if i cant get nothing out of this,its ok i can allways just wipe device and restore back up without the kernal installed...
Very nice, well-written guide. Thanks a lot!
@soniCron: How do I turn on and of cores one by one? I have quad core.
Hi soniCron, I just wanted to let you know that I followed your guide and tweaked my OnePlus One. Great results so far, and stellar battery life. I'm very happy with it, thanks
Phazonclash said:
Hi soniCron, I just wanted to let you know that I followed your guide and tweaked my OnePlus One. Great results so far, and stellar battery life. I'm very happy with it, thanks
Click to expand...
Click to collapse
Can you share your changes/parameter settings?
Maybe via pm if not using the thread?
solar666 said:
Can you share your changes/parameter settings?
Maybe via pm if not using the thread?
Click to expand...
Click to collapse
above_hispeed_delay 20000 652800:20000 1190400:40000 1497600:60000 2265600:80000
boost 0
bootpulse duration 80000
go_hispeed_load 99
hispeed_freq 652800
io_is_busy 0
mac_freq_hysteresis 10000
min_sample_time 60000
target_loads 98 652800:40 1190400:70 1497600:80 2265600:90
timer_rate 30000
timer_slack 40000
How the lemon does this guide only have 2 pages?
Great guide, thanks a lot, going to try it with my oneplus one now
thewind730 said:
I use the the fku updater app the paid version and all my settings stick on my g3 and my m8
Click to expand...
Click to collapse
Can you share please your M8 settings and tell if it really had an impact on performance and battery life. Thanks.
Also I cannot save the edited parameters files under /sys/devices/system/cpu/cpufreq/interactive although I have full root. Any suggestions? I have an HTC One M8 with ViperOneM8 4.3, rooted and S-Off.
Sent from my HTC One_M8 using Tapatalk
tghandour said:
Can you share please your M8 settings and tell if it really had an impact on performance and battery life. Thanks.
Also I cannot save the edited parameters files under /sys/devices/system/cpu/cpufreq/interactive although I have full root. Any suggestions? I have an HTC One M8 with ViperOneM8 4.3, rooted and S-Off.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Sent from my HTC One_M8 using Tapatalk
I'm testing this guide on my LG G2 and it seems to work pretty well.
Good job :good:
Awesome! I just tweaked mine now to the lowest frequencies that is lag free and will check tomorrow if battery life of my htc one m9 has improved somehow.
Also you might want to add this link to kernel cpu governor documentation. Which pretty much explains the other variables.
tghandour said:
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Can u share ur m8 settings to try out please...... Thanks
HTC m8 on arhd 43 using dark blue Tapatalk from jokerpoker1
Hey, this is my first post here! **Edited for... uh... clarity and to add some information. Hopefully it's more readable now.
I found a way to control and manage the thermal throttling of the device.***
Modern smartphones create a lot of heat, and usually the casing of the device or the aluminum midframe chassis is used as a heatsink. Unlike a laptop, it does not have a cooling fan, so it must rely on the passive dissipation of heat through the casing of the device and the display panel to keep the CPU temperature down. On the Nexus 6P, there is decent thermal contact between the processor IC and the midframe. However, due to both the fact that the RAM is layered over top of the CPU and because the thermal contact is still not ideal, it is difficult to keep the CPU as cool as a computer implementation.
In order to reduce heat production and control the temperature of the device, the OEM implements thermal engine for Qualcomm MSM chipset in order to slow the frequency of the CPU and GPU cores down when the temperature is high.
Right now it is set to 50C throttling temperature, presumably so that the heat production does not cause the display panel to heat up to the touch, as at lower powers, the thermal mass of the aluminum frame plus passive dissipation will make case temperature increases not very noticeable. However, at 50C, the CPU will often throttle even at medium load, because the hardware does not make it easy to keep the temperature under that. This has been true for every phone I have worked with in the past and some are even worse at this.
Personally, I find that having a high (>45C) surface temperature is not a huge problem (You can decide that for yourself. if it is a problem for you, this won't help you. You can't change the power efficiency limit of the processor). In my use case, when I have a lot of applications open, especially Firefox in desktop mode, or 4-way Android M multitasking or something like that (or just typing to a lot of people in Facebook Messenger or something similar). I kinda use the thing like a computer so obviously it has extended periods of high CPU workload and the device starts to throttle back to something like 1344 or 960MHz or even lower.
Given this, what I want to do is change the CPU throttle temperature to a higher one. Generally, we don't need to worry about protecting the processor hardware because it has built in thermal shutdown/reset functions should something go wrong. It's at something like 110C, which sounds high, but as someone who uses a MacBook Pro, it is normal to see the CPU temperature that high! Intel generally throttles at a much higher temperature because they don't care about the actual temp of the heat sink, only that of the processor die.
In the past kernel I tried, there was an option to set up the thermal throttling temperature (God's Kernel). However, I switched to the AK kernel recently, due to its High Performance Audio feature. This kernel did not include support for this configuration.
I am running MH19Q Marshmallow stock.
I used File Explorer with root access to go to system/etc I think and there is a file called thermal_engine.conf or similar. If you edit it, you see there are a lot of values. Actually basically if you look around, there are a lot of temperature values in there seperated by the things they control. I would like to explain more, but I think it is better if you can open up your file and my file side by side and see for yourself what's different. The gist is that there's a table of values and a bunch of actions to take when they're hit, and of course, there are release temperatures, which are basically the lower hysterisis limit I think. The temperature values look like 44000 or 43000 by default, which means 44C and 33C (celcius)and I changed mine to 97000 (97 C)
Here you can find the content of the file. Type in the pastebin website, then put slash QYhi05rE.
I didnt keep my old file.... sorry about that... Perhaps someone can post it if they have it.
With stuff set to 97 C, the device heats up a lot more, obviously, but it's manageable. If you have something like Cinema 4K open for a long time, of course it will get to like 50C on the surface (That is quite unconfortable to put your hand on, but I'm okay with it). Hangouts video calling seems to be the worst and sometimes the battery will get higher than 50C and then stop charging. Given the design of the phone, by the time the battery gets too hot to be safe, the system will probably shutdown or restart, and you'll notice it LONG before anything becomes a problem.
Thanks for looking!
***Do this at your own risk, as with all root mods and tricks. Obviously this has the risk of breaking things or causing hardware to fail. High temperatures on BGA soldered chips have been observed to increase the failure rates, even in stuff like routers and TVs and other stuff that you don't generally think of as having thermal issues. My last phone (Note 5) kinda broke after a little while, although I'm not sure if me doing this caused it. (Appears to be display panel issue, but have not tested). All I know is that earlier that day I was outside filming on it and processing video, and that the area above the SoC got rather warm to the touch. Which should be read as "painfully hot" to most.
file removed? add disclaimer pls
LarryChendragon2099 said:
Hey, this is my first post here! **Edited for... uh... clarity and to add some information. Hopefully it's more readable now.
I found a way to control and manage the thermal throttling of the device.***
Modern smartphones create a lot of heat, and usually the casing of the device or the aluminum midframe chassis is used as a heatsink. Unlike a laptop, it does not have a cooling fan, so it must rely on the passive dissipation of heat through the casing of the device and the display panel to keep the CPU temperature down. On the Nexus 6P, there is decent thermal contact between the processor IC and the midframe. However, due to both the fact that the RAM is layered over top of the CPU and because the thermal contact is still not ideal, it is difficult to keep the CPU as cool as a computer implementation.
In order to reduce heat production and control the temperature of the device, the OEM implements thermal engine for Qualcomm MSM chipset in order to slow the frequency of the CPU and GPU cores down when the temperature is high.
Right now it is set to 50C throttling temperature, presumably so that the heat production does not cause the display panel to heat up to the touch, as at lower powers, the thermal mass of the aluminum frame plus passive dissipation will make case temperature increases not very noticeable. However, at 50C, the CPU will often throttle even at medium load, because the hardware does not make it easy to keep the temperature under that. This has been true for every phone I have worked with in the past and some are even worse at this.
Personally, I find that having a high (>45C) surface temperature is not a huge problem (You can decide that for yourself. if it is a problem for you, this won't help you. You can't change the power efficiency limit of the processor). In my use case, when I have a lot of applications open, especially Firefox in desktop mode, or 4-way Android M multitasking or something like that (or just typing to a lot of people in Facebook Messenger or something similar). I kinda use the thing like a computer so obviously it has extended periods of high CPU workload and the device starts to throttle back to something like 1344 or 960MHz or even lower.
Given this, what I want to do is change the CPU throttle temperature to a higher one. Generally, we don't need to worry about protecting the processor hardware because it has built in thermal shutdown/reset functions should something go wrong. It's at something like 110C, which sounds high, but as someone who uses a MacBook Pro, it is normal to see the CPU temperature that high! Intel generally throttles at a much higher temperature because they don't care about the actual temp of the heat sink, only that of the processor die.
In the past kernel I tried, there was an option to set up the thermal throttling temperature (God's Kernel). However, I switched to the AK kernel recently, due to its High Performance Audio feature. This kernel did not include support for this configuration.
I am running MH19Q Marshmallow stock.
I used File Explorer with root access to go to system/etc I think and there is a file called thermal_engine.conf or similar. If you edit it, you see there are a lot of values. Actually basically if you look around, there are a lot of temperature values in there seperated by the things they control. I would like to explain more, but I think it is better if you can open up your file and my file side by side and see for yourself what's different. The gist is that there's a table of values and a bunch of actions to take when they're hit, and of course, there are release temperatures, which are basically the lower hysterisis limit I think. The temperature values look like 44000 or 43000 by default, which means 44C and 33C (celcius)and I changed mine to 97000 (97 C)
Here you can find the content of the file. Type in the pastebin website, then put slash QYhi05rE.
I didnt keep my old file.... sorry about that... Perhaps someone can post it if they have it.
With stuff set to 97 C, the device heats up a lot more, obviously, but it's manageable. If you have something like Cinema 4K open for a long time, of course it will get to like 50C on the surface (That is quite unconfortable to put your hand on, but I'm okay with it). Hangouts video calling seems to be the worst and sometimes the battery will get higher than 50C and then stop charging. Given the design of the phone, by the time the battery gets too hot to be safe, the system will probably shutdown or restart, and you'll notice it LONG before anything becomes a problem.
Thanks for looking!
***Do this at your own risk, as with all root mods and tricks. Obviously this has the risk of breaking things or causing hardware to fail. High temperatures on BGA soldered chips have been observed to increase the failure rates, even in stuff like routers and TVs and other stuff that you don't generally think of as having thermal issues. My last phone (Note 5) kinda broke after a little while, although I'm not sure if me doing this caused it. (Appears to be display panel issue, but have not tested). All I know is that earlier that day I was outside filming on it and processing video, and that the area above the SoC got rather warm to the touch. Which should be read as "painfully hot" to most.
Click to expand...
Click to collapse
Not new.
This has been around and discussed for a while.
I have been running a modified thermal-engine.conf since day one.
Hello Axon 7 users, I just picked up one a couple of days ago. After finally figuring out the bootloader, bootstack and general stock experience I tested a little bit of gaming. I found that a basic game like Clash Royale heats the battery up to around 42°C already with low brightness and slow charging. A more intensive game like the new Knives Out runs only slightly hotter but it becomes apparent that CPU gets throttled soon after loading to 1036MHz across all cores causing lag.
It's disappointing so I tried to find how to modify the throttling. Using ZTE's Power Manager setting on performance or balanced doesn't seem to have a noticeable difference.I tried the only stock custom kernel AX7 but it's outdated on B32 and I find it randomly reboots regularly. The stock kernel itself allows some configuration, but the thermal settings in Kernel Adiutor don't reflect any charge.
A quick Google search brings up how LG V20 Snapdragon 820 users edit /system/etc/thermal-engine.conf to tweak the throttling levels. Their config is quite different but they mod big to 1824Mhz and let little scale itself.
I couldn't get thermal-engine.conf to use the thermal-engine-8996-perf.conf values by copying the values to it as it suggests inside. I tried renaming it with the -zte.conf ending as it suggests as well but that didn't work. After just renaming both the normal and perf conf files with a .bak ending, I've found better throttling performance. Big now throttles to 1632Mhz and little to 1324Mhz. As far as I can understand the files don't have charging rates inside, just GPU and CPU throttling.
However as expected the device heats up a few degrees more now. This now puts my battery up to 47°C in Knives Out under the same conditions. Charging is stopped at 45°C by the system so as previously mentioned it's unmodified.
I just wanted to check since I couldn't find it mentioned. Is everyone ok with gaming performance limited to 1036Mhz with the normal throttle? Also are my temperatures normal? I guess CPU doesn't seem that high reaching around 65°C, it's just that the battery has less than 20°C difference in intensive performance. I suppose it's a quirk of the heat pipe to battery as heatsink design. I just expected more from a metal unibody chassis and at least normal CPU gaming performance. I thought my Sony Z3 Compact design was bad for battery thermals, with the battery stacked behind the CPU board, sandwiched in insulating glass. But I didn't expect to see a phone to route a heatpipe directly to it's battery.
Anyway it is what it is. Follow this information if you want some better gaming performance at the cost of your battery cycle life. In my case I bought the Axon7 just as a separate media consumption device rather than a phone so I can live with the tradeoff. If battery gets bad enough before 2 years I'll consider using warranty at the loss of receiving their refurbished replacement. Manufacturer warranty's in fact cover batteries for 80% depletion.
I recommend the app DevCheck Pro for being able to monitor CPU, GPU, temperatures and other things overlayed. I think some others may do similar but they may not be updated for Big Little and are more instrusively overlayed.
Infy_AsiX said:
A quick Google search brings up how LG V20 Snapdragon 820 users edit /system/etc/thermal-engine.conf to tweak the throttling levels. Their config is quite different but they mod big to 1824Mhz and let little scale itself.
I couldn't get thermal-engine.conf to use the thermal-engine-8996-perf.conf values by copying the values to it as it suggests inside. I tried renaming it with the -zte.conf ending as it suggests as well but that didn't work. After just renaming both the normal and perf conf files with a .bak ending, I've found better throttling performance. Big now throttles to 1632Mhz and little to 1324Mhz. As far as I can understand the files don't have charging rates inside, just GPU and CPU throttling.
Click to expand...
Click to collapse
I read half of that to be honest, but just one thing: To make things harder, ZTE added added a write protection on the system. To disable it you have to use a computer and connect your phone with ADB, then issue "adb reboot disemmcwp" (like DISable EMMC Write Protection). Otherwise all the changes that you made get undone after a reboot, and obviously you'd have to reboot after modifying that file
On LOS you can use BeastMode (even if your phone isn't an A2017U) which for me is the best friggin kernel I've used in performance terms. There you can change thermal limits
Infy_AsiX said:
Hello Axon 7 users, I just picked up one a couple of days ago. After finally figuring out the bootloader, bootstack and general stock experience I tested a little bit of gaming. I found that a basic game like Clash Royale heats the battery up to around 42°C already with low brightness and slow charging. A more intensive game like the new Knives Out runs only slightly hotter but it becomes apparent that CPU gets throttled soon after loading to 1036MHz across all cores causing lag.
It's disappointing so I tried to find how to modify the throttling. Using ZTE's Power Manager setting on performance or balanced doesn't seem to have a noticeable difference.I tried the only stock custom kernel AX7 but it's outdated on B32 and I find it randomly reboots regularly. The stock kernel itself allows some configuration, but the thermal settings in Kernel Adiutor don't reflect any charge.
A quick Google search brings up how LG V20 Snapdragon 820 users edit /system/etc/thermal-engine.conf to tweak the throttling levels. Their config is quite different but they mod big to 1824Mhz and let little scale itself.
I couldn't get thermal-engine.conf to use the thermal-engine-8996-perf.conf values by copying the values to it as it suggests inside. I tried renaming it with the -zte.conf ending as it suggests as well but that didn't work. After just renaming both the normal and perf conf files with a .bak ending, I've found better throttling performance. Big now throttles to 1632Mhz and little to 1324Mhz. As far as I can understand the files don't have charging rates inside, just GPU and CPU throttling.
However as expected the device heats up a few degrees more now. This now puts my battery up to 47°C in Knives Out under the same conditions. Charging is stopped at 45°C by the system so as previously mentioned it's unmodified.
I just wanted to check since I couldn't find it mentioned. Is everyone ok with gaming performance limited to 1036Mhz with the normal throttle? Also are my temperatures normal? I guess CPU doesn't seem that high reaching around 65°C, it's just that the battery has less than 20°C difference in intensive performance. I suppose it's a quirk of the heat pipe to battery as heatsink design. I just expected more from a metal unibody chassis and at least normal CPU gaming performance. I thought my Sony Z3 Compact design was bad for battery thermals, with the battery stacked behind the CPU board, sandwiched in insulating glass. But I didn't expect to see a phone to route a heatpipe directly to it's battery.
Anyway it is what it is. Follow this information if you want some better gaming performance at the cost of your battery cycle life. In my case I bought the Axon7 just as a separate media consumption device rather than a phone so I can live with the tradeoff. If battery gets bad enough before 2 years I'll consider using warranty at the loss of receiving their refurbished replacement. Manufacturer warranty's in fact cover batteries for 80% depletion.
I recommend the app DevCheck Pro for being able to monitor CPU, GPU, temperatures and other things overlayed. I think some others may do similar but they may not be updated for Big Little and are more instrusively overlayed.
Click to expand...
Click to collapse
I have noticed the same performance many months ago.
I tried changing the thermal values with both ways through the conf file or a custom kernel but all implementations seem to be faulty as nothing changed.
In the end I gave up because I couldn't find a solution for this.
But I figured because my games clash of clans, ppsspp, gba emulators don't lag I din't care much.
If you find a solution let me/us know.
Or post the modded confs you're using as well if you can.
That's all from me.
I just renamed both the thermal-engine files with a .bak extension. I've also got ZTE's Power Manager frozen as the performance profiles there don't seem to do anything and I don't use it's other features. There's some kind of CPU GPU throttle still in place but it's much higher as previously mentioned,. After searching further I saw your discussion about /vendor/bin related throttle, maybe that's the fallback it's now on.
The device does get uncomfortably hot with a new demanding game at maximum settings. I wouldn't recommend doing this if you want to maintain your battery. However if you're interested I discovered the Ax7 allows defining a lower maximum battery voltage in another TL/DR post https://forum.xda-developers.com/showpost.php?p=74746734&postcount=1353. To explain simply, it's possible to limit the voltage low for health and safety while keeping the device almost primarily powered by mains. Effectively the battery is at an optimum low voltage, practically idle but very hot. A little complicated sure, but worth it. Getting a Daydream V1 tomorrow to play with, this stuff will help with heat and performance a lot. If anyone wants my long winded explanation, give me a shout.
The CPU temp does jump around higher than 70. I'm tending to think that current powerful mobile processors aren't efficient enough for the physical body constraints of phones. Let alone poorly designed ones. The 820 is meant to be an improvement over the 810, wouldn't believe it by the throttle required and performance lost. The 835 is efficient enough apparently. From experience though I have my doubts on reviews and benchmarks to reflect real usage stress.
edit: Oh and disable VDD restriction in your kernel setting if you've set it to auto enable. That seems to be a switch for the aggressive throttle still available after mod.
Sent from my ZTE Axon 7 using XDA Labs
Infy_AsiX said:
I just renamed both the thermal-engine files with a .bak extension. I've also got ZTE's Power Manager frozen as the performance profiles there don't seem to do anything and I don't use it's other features. There's some kind of CPU GPU throttle still in place but it's much higher as previously mentioned,. After searching further I saw your discussion about /vendor/bin related throttle, maybe that's the fallback it's now on.
The device does get uncomfortably hot with a new demanding game at maximum settings. I wouldn't recommend doing this if you want to maintain your battery. However if you're interested I discovered the Ax7 allows defining a lower maximum battery voltage in another TL/DR post https://forum.xda-developers.com/showpost.php?p=74746734&postcount=1353. To explain simply, it's possible to limit the voltage low for health and safety while keeping the device almost primarily powered by mains. Effectively the battery is at an optimum low voltage, practically idle but very hot. A little complicated sure, but worth it. Getting a Daydream V1 tomorrow to play with, this stuff will help with heat and performance a lot. If anyone wants my long winded explanation, give me a shout.
The CPU temp does jump around higher than 70. I'm tending to think that current powerful mobile processors aren't efficient enough for the physical body constraints of phones. Let alone poorly designed ones. The 820 is meant to be an improvement over the 810, wouldn't believe it by the throttle required and performance lost. The 835 is efficient enough apparently. From experience though I have my doubts on reviews and benchmarks to reflect real usage stress.
edit: Oh and disable VDD restriction in your kernel setting if you've set it to auto enable. That seems to be a switch for the aggressive throttle still available after mod.
Click to expand...
Click to collapse
That's weird... what are the ambient temps where you live? Here it's anything between 20 and 30 degrees and mine never gets that hot, and it barely throttles. Of course you shouldn't game while charging, that WILL throttle the phone.
I have a big old CPU heatsink without a fan, and when I charge the phone at night I just put it upon the heatsink. It keeps the battery around the ambient temp, which I guess helps with battery degradation.
A nice app for monitoring the CPU is Trepn profiler, you can program it to show you anything like frequencies and temps on 2 separate graphs for example
MOD EDIT: No placeholder allowed and the major content of this post saying "S7"?
OP, please take some time to edit your forwarded post in a proper format. Thanks.
The T800 travels from the FUTURE to bring YOU the POWER AND BATTERY of a Galaxy S10+ to your beloved S7, while fighting obsolescence...
Version III features:
° 14 hours of battery life sustained with OneUI 5.1 (STOCK kernel)
+ 14 hours of SOT
° About twice or more the speed with no Lag por shutter
° Vídeo about how to apply UV properly and recommended ROM and kernel and many extras (Such as GPU Turbo and FPS screen uncap) ( In s23U don't needed! All of that in only 14 hours! And for free!!
This revolutionary CREATION of mine will give you the SAME (not shame) optimization as Apple do with it's phones (Tremendous battery life and smoothness) But with two or three times the amount of ram, better screens twice the cores, battery ,etc. So:
HERE IS THE AWESOME SPEED YOU CAN SPECT Before/After:
AND HERE IS A BENCHMARK WHERE YOU CAN SEE TEMPERATURES OF 20 OR MORE DEGREES LESS THAN STOCK ROM, WHILE SAVING BATTERY Classic s7 results.
"65% of charge in 30 minutes full charge achieved in less than a hour..." With Aosp only
Q: Why does the manufactures do this bad on stock on purpose?
Two things, MARKETING and PROGRAMMED OBSOLESCENCE which lead them to even put 10 core when a Apple device with two high power cores (Iphone 7 plus) eats it (Mediatek 10 core setup)
Q: What kind of results will i experiment?
With LATEST LINEAGE 16 + Morokernel + this AWESOME PROFILE and with a non-degraded battery you will experience the performance of a Samsung Galaxy S10 with the battery life (and also charging speed, if you have a QC 3.0 charger... of the Latest huawei/honor phones (8 hours SOT, 65% in 30 min) feeling the ui completely lag free, the apps opens right at the moment, and scrolling is like butter. Also runs very very well like a SD 855
IN S23U and, from that, ALL S23 LINE YOU CAN SPECT MUCH BETTER RESULTS!
So i upload you the profile, you will need the following: *Updated S23*
1: Root and follow the guide as close as the video on S7, disable two cores (7/8) and put the freqs as close as the video, you can even CUSTOMIZE it If you want. B throut the best results, following the Guide. You can use Mtweaks or Kernel auditor.
And If you want throw some benchmarks for cpu/gpu temp and SOT feel free to TEST.
Morokernel installed
Mtweaks latest
Download the latest LAG_TERMINATOR™
Open Mtweaks menu and select "profiles" then import the latest "LAG_TERMINATOR™" profile of mine.
APPLY THIS SETTINGS ON BOOT AND YOU ARE DONE. Vídeo settings:
You have to apply this settings on Mtweaks to Morokernel and you are Done. You can also flash the attached zip's to uncap 60fps in all the system animations and GPU turbo for more gaming/phone normal use performance.
1Morokernel and mtweaks download (all in 1 flashable zip) (Works on aosp and TW roms) https://androidfilehost.com/?w=files&flid=295574
2DOWNLOAD NOW THIS AWESOMENESS:
https://www.mediafire.com/file/k964wlh4c4qz5ol/LAG_TERMINATOR™.json ***SEE THE ABOVE YOUTUBE VIDEO AND APPLY THE SAME SETTINGS AND LATTER YOU WILL ENJOY THIS.[/COLOR]
Disclaimer: You don't have the right to post my content in any site without my explicit permission[/U].
Note: If you want me to buy some toys/good sweets to my dear cat you can always donate some money to my paypal: MOD EDIT: donation link removed. Thank you
Hi! touching my phone and having common sense let me know that the Exynos GPU and the low power cores/high power cores have a little nonsense regarding to STOCK thermal and CPU/GPU freq/usage, so, i change between low power cores to high power cores at 50% it's minimum frequences and let the system to use ONLY the high power cores, heavy underclocked, since our phone have thermal copper plate to avoid high temperatures there should be no problem.
But the MORE INTERESTING part of it, it's that this Exynos allows to underclock a LOT among other things, except the GPU which doesn't go really well with underclocking so, when i do this mod, i was able to boost the overall system performance (daily use) like our S7 Exynos is like two or three generations after it regarding to performance! While turning on only hardcore CPU's and not the EIGHT OF THEM the phone not only runs wayyy better, but also runs VERY stable and cold, even better than stock.
Regarding battery life, the overall pack which you only have to import through "Morotweaks" you not only have a lot more benefits regarding low power consumption, but, when you use the powerfull cores ONLY at higher frequency, the Exynos is able to deep sleep more often than before... Regarding additional benefits into the battery life/heat area.
This looks amazing, but where are the download links? Also, will I void my warranty if I use this kernel?
Uhm this look sus
does anyone know how to install? I don't quite understand how to do it
ULTRA90 said:
does anyone know how to install? I don't quite understand how to do it
All the descriptions are claimed for the S7 exynos, so look very sus
Click to expand...
Click to collapse
@Therazorsedge OP, please take some time to edit your forwarded post in a proper format.
Contact me to unlock this thread after all is done. Thanks.