Related
So this is a development idea...
I thought about this the other day and realized that under volting could be causing my battery to die quickly...
Here's why.
V = I * R
Where v = volts, I = amps, R = ohms.
P = V * I
Where P = (power)watts
I know some of you are going to think that this doesn't belong in development, but here me out here.
So if the processor uses 1.5 Watts and we decrease the voltage, this means that the processor needs to increase current to maintain that power. This equates to reduced battery life.
I'm just suggesting that undervolting may be causing the low battery life. If you know better feel free to tell me I'm wrong, but please explain the mechanics of what is going on not just your theory.
This question is over my head so I'll refrain from speculating directly on your theory. But real-world results with my undervolted Stupidfast 1.54 kernel gives me much better battery life than stock. Yes, this may be due also to the unbloated-ness as well so I'm not 100% certain the undervolting is the main help here
Well....I dunno how this applies to CPUs but.... I used to be a car audio installer/buff and when we noticed voltage sagging to an amplifier, the amplifier would compensate by pulling more amperage at the lower voltage. It never seemed to make much different to the batteries, but it did make the amps run much hotter...so....
Again, not sure if it would tie in, but....
Hmm I've never thought about that. From my RC knowledge the most efficient set ups are the ones that use high voltage but low amps.
I may have to try a OV kernel and see if I notice a difference...
Sent from my Samsung Fascinate running BH3.0, DL09, 125mv undervolt Voodoo5 using SwiftKey and Tapatalk
As a disclaimer, I have not performed any formal reading on this topic, these are just my idle ramblings.
My contention has been that you only enjoy the benefits of a UV kernel if you are a certain type of user.
If you are performing CPU intensive tasks, you reap the most benefit from the UV kernel because it needs less power to run at 1 GHz (or whatever the maximum clock speed is set to for that kernel).
If you spend alot of time idling, for instance reading interspersed by web requests, you are spending most of your time at the minimum clock speed. With the stock kernel, that is set to 0.1 GHz. With a UV kernel, the minimum clock needs to be set to something higher to keep the CPU running. You may be able to estimate what this speed needs to be based on the fundamental power calculations in the OP.
The governor quickly changes your clock speed based on your current usage & requirements. To make optimal use of the CPU governor, it should have access to the broadest possible range of speeds (without going higher than is useful/safe). Unfortunately, undervolting a kernel sacrifices some of the lower end of that range. Therefore, many users see much improved battery life, while others (like me) experience noticeably diminished overall performance from UV kernels.
Swyped w/ XDA App. When in doubt, mumble.
P=V*I
The processor does not draw a constant power, but it does have a minimum. The point of undervolting is bringing the power consumption to that minimum within the phones physical environment and user expectations of functionality.
So...
You are right.
However, processor frequency is dependant on current. Thus if you are undervolting to save battery life then you will need to keep your frequency the same or lower to notice a difference. If you are overclocking (increasing current) and undervolting then your P stays the same so the user ends up feeling the battery life to be the same or worse.
Facundo
Are there any standard or over volt kernels available so we can test this theory? It seems as though all the kernels available are UV.
Sent from my SCH-I500 using XDA App
would you like a standard voltage kernel to test?
Personally I see worse battery life on UV kernel. My usage mostly equals to dumb phone, with email sync and moderate web browsing.
I would change formula to I = V/R, which will read as current is directly proportional to voltage and inversely proportional to resistance. That makes obvious that reducing voltage we decrease current. However one point to note here is that this law is for PASSIVE conductor, which is obviously not our case. I would not speculate further, because we do not know what king of power conversion happens. It might simply turn out that conversion is not efficient at lower voltages. Google desktop power block certifications/efficiency to see whet I mean.
I compiled some kernels so you folks can play with it. I SERIOUSLY doubt you will get better life with my stock voltage vs. undervolt, but give her a shot.
Undervolted
Voodoo
http://adrynalyne.us/files/kernels/adryn_test2_0116_fascinate_voodoo5.zip
Nonvoodoo
http://adrynalyne.us/files/kernels/adryn_test2_0116_fascinate_novoodooo.zip
Standard voltage
Voodoo
http://adrynalyne.us/files/kernels/adryn_sv_0116_fascinate_voodoo5.zip
Nonvoodoo
http://adrynalyne.us/files/kernels/adryn_sv_0116_fascinate_novoodoo.zip
I'm giving the SV Voodoo kernel a try right now.
Sent from my Samsung Fascinate running BH3.0, DL09, and Voodoo5 using SwiftKey and Tapatalk
I thought about this as I thought about power lines. They use super high voltages to reduce the amount of power loss through the lines.
Anyways, sounds good, I'll test it out. I'd have to get a baseline. I guess I'll charge my phone right now and test out the regular voltage.
I'll let you guys know tomorrow the differences tomorrow.
In all honesty, I don't ever feel that I get more juice out of unvervolt kernels and I've been using all kinds of kernels since the release of MT3G.
Thanks for the standard voltage kernel!
I do appreciate you efforts in continually optimizing these, having a baseline to compare to just makes it all the more wonderful.
I will give the SV (standard voltage) a day or so of testing and then compare the UV against to make the test fair. With ten minutes of use ^^, it is already a great contender for my daily driver. I had gone back to 11/29 from 12/30. 11/29 was a terrible pairing with DL09; my GPS was unusable.
$ busybox md5sum ad*.zip
aea1047f3b2d33e759064d47cc8cac27 adryn_sv_0116_fascinate_novoodoo.zip
Works great!
Swyped w/ XDA App. When in doubt, mumble.
I wonder if android has battery test application, just to be put everything in the same play field? It's kind of pointless to compare subjectively.
Well, I tried to be objective with this test I just did.
Here were my conditions:
Charge to full, write down the time it was at full charge which wasn't 100%.
Let it sit for one hour.
Write down the charge.
SV Conditions
Starting charge 99%
Ending charge 97%
UV Conditions
Starting charge 98%
Ending charge 96%
The results...
SV - 3% discharge / hour
UV - 2% discharge / hour
Errors analysis:
There are several issues with this test because they were not even at the same charge at the start. Batteries have their maximum charge at 100%, and the rate of decrease is not a linear decrease. More testing is needed to compare the results.
Also the duration is not long and other factors have not been considered such as background applications refreshing on their own. I will have to test for 8-10 hours of each at idling tomorrow to get an accurate measurement.
Currently, I'm still on the UV kernel and I'll publish my results tomorrow of the UV over the 10 hour period.
Then I'll try to not use my phone throughout the day and test the SV.
It would be nice if someone could test the SV and UV with moderate usage and write down the initial charge, final charge, and the duration between the measurements. And another using heavy usage.
Thanks.
RacerXFD said:
SV Conditions
Starting charge 99%
Ending charge 97%
UV Conditions
Starting charge 98%
Ending charge 96%
The results...
SV - 3% discharge / hour
UV - 2% discharge / hour
Click to expand...
Click to collapse
Im confused with your math here...
Yeah, your math is off.....
Sent from my SCH-I500 using XDA App
RacerXFD said:
So this is a development idea...
I thought about this the other day and realized that under volting could be causing my battery to die quickly...
Here's why.
V = I * R
Where v = volts, I = amps, R = ohms.
P = V * I
Where P = (power)watts
I know some of you are going to think that this doesn't belong in development, but here me out here.
So if the processor uses 1.5 Watts and we decrease the voltage, this means that the processor needs to increase current to maintain that power. This equates to reduced battery life.
I'm just suggesting that undervolting may be causing the low battery life. If you know better feel free to tell me I'm wrong, but please explain the mechanics of what is going on not just your theory.
Click to expand...
Click to collapse
I'm an electrical engineer, and none of this makes any sense. V=IR is for current and voltage going through/across a constant resistor. Transistors are not constant resistors. The current through a Metal Oxide Semiconductor Field Effect Transistor (MOSFET), the type of transistor that is in basically all ICs, is always in positive relation to the voltage, at least for the purposes of this basic explanation. Decreasing the supply voltage, which is you can consider to be the VGS of a transistor for a simple analysis, is always going to decrease the current as well. Thus, depending on the range of operation of the MOSFET, decreasing the voltage will also decrease the current and thus power will decrease more than linearly. Less current means that the transistors will charge and discharge capacitances slower, and that's why you need voltages for higher clock speeds and overclocking IN GENERAL. Device physics is really weird.
Now, someone else was saying that maybe because you undervolt it less current goes through which means it needs to spend more time in a higher clock state. This is completely false, the current going through it has nothing to do directly with the amount of work done. Yes, you need more current for faster clock speeds, but at a given clock speed, it doesn't matter how much voltage or current there is and how fast the individual parts of the circuit work, as long as the longest delay in any part of the circuit is less than the clock rate. If it's longer than the clock period, then your circuit is no longer going to function and you'll have instability and crashes, but there is a bit of wiggle room designed into these circuits because each chip can be different. That's why you can overclock or undervolt a CPU, because obviously if it was designed to run at the fastest clock speed possible, any little variation in supply voltage, temperature, manufacturing process/lithography (which is very common) would cause your CPU to completely not function. You have to design your circuits to be tolerant of some amount of error from many sources (even cosmic radiation in some cases), otherwise it won't just be slow, it won't function at all. Logic circuits are clocked to synchronize data going through the circuit, and if the timing constraints aren't always obeyed you'll get wrong answers which would probably crash your OS. Undervolting will never cause the CPU to do less work in one clock cycle, unless you undervolt it too much, in which case things will likely blow up in your face.
Sorry for the wall of text, but hopefully this will clear up some stuff. And in the future, please stick to what you're good at and don't try to speculate things based on one formula that you heard sometime in physics while you were half asleep, or something some CSR told you to get you to shut up. Believe it or not, the people who are designing CPUs and writing/modifying kernels and operating systems actually know what they're doing and you're not going to suddenly realize that they're going about their business wrong because of something you learned in high school.
Edit: One other thing. The calculation of percentages of battery life is a bit of guesswork on the side of your phone, trying to determine via statistics what a voltage level means in terms of percentage of battery life. Battery voltages don't drop linearly as you use them, and can be affected by many things, such as whether it's plugged in to the charger in particular. That's why you see a drop immediately when you unplug your phone, and why looking at 2-3% differences is completely meaningless. The better way to test would be to actually see how long you can use it with an equal amount of work being done on each voltage, which is hard to do in real life. Too many variables are present in today's smartphones, what with background tasks and data coming and going and the like. And wireless radios are a huge battery drain, especially when you're receiving a weak signal. I would advise people to just carry a charger or usb cable with them and top up your battery when you need to rather than worry so much about small differences in battery life. You'll save on a lot of stressing .
Thanks for the explanation. I'm an aerospace engineer. I did have to take a few courses in EE, but nothing to your level. So please let me know if I'm completely off on my testing.
I am pretty sure that the Devs know what they're doing, but I was getting tired of my low battery life and I was willing to test this theory of mine out for them. Again, seriously if I am completely out of the park in terms of this testing, let me know. And I'm ok with being called stupid as long as you teach me what I did wrong...
Yea, I completely forgot how with transistors, the math regarding voltage is handled differently than through a resistor. Are you telling me that the battery life will not be different between standard voltages and under voltages?
EDIT: I understand what you're saying about lowering voltage lowers current because the current has a linear relationship with the voltage in a MOSFET chip. Thanks, I had to read that like 5 times to understand and remind myself.
This is a complete waste of my time at this point because I know what's going on, but I wish to share my results anyways...
Ok here's where I got with the testing since last night. I realize that battery life is nonlinear. But i figure this is better than nothing.
But I did complete 8 hour test of SV at idle.
Starting charge percentage 94%
Ending charge percentage 82%
Which results in 1.5%/hour discharge rate at idle.
Will do the undervolt today. I'll document that in roughly 8 hours.
Hi XDA'lers,
I think it would be interesting to collect some stats on the undervolting capabilities of our mantas. Hopefully it helps others who also intend to save some energy by doing this. If you want to participate, please post your lowest possible settings exactly like this:
CPU:
Code:
% MHz= [ 100, 200, 300, 400, 500, 600, 700, 800, 900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100];
BR
900, 900, 900, 900, 900, 912, 925, 950, 962, 987,1012,1037,1075,1100,1137,1187,1225,1250,1275,1300,1325; % [email protected]_kernel_name_and_version (hotplugging_state)
% BR
GPU:
Code:
% MHz= [ 100, 160, 266, 350, 400, 450, 533, 612, 667, 720];
BR
900, 900, 925,1000,1050,1100,1150,1200,1250,1300; % [email protected]_kernel_name_and_version
% BR
... and don't forget to replace the default mV values in the third line by your own ones. Please write your username, kernel, and hotplugging state where indicated.
You can find out whether hotplug is enabled or not, if you have a look at your governor adjustments, or watch the state of the second core when idle (for example in the KTweakerT app).
~ Rules ~
Each CPU value should run stable for at least 30 minutes under stress-testing conditions. (Use some tool like for example the "Classic Stability Test" within the app "StabilityTest", or "SetCPU".) Don't use HD videos or something like that for stress testing, they are a joke to our CPU. :laugh:
If you don't adjust certain values, like for example CPU frequencies above 1700 MHz: Do not write '0'. Please leave it at the default value.
Be honest. We love you for your personality, not your Android. (If you want to submit anonymously, you can write me a PM as well.)
Don't let your kernel config app set test values on boot. :silly:
Your settings should not impair the usability of your device at all. (Crashes upon governor scaling for example.)
GPU voltages can sometimes be set below device minimum, however, we want to collect values that allow an unimpaired experience with no graphical glitches at all.
If you want to copy values from others, be aware that their best settings are not the best for you. Every Nexus 10 is different, and there is the risk that some voltage is unstable on your system. If it works anyway, you save power by applying the settings, but chances are that you could find even more efficient values! To maintain statistical significance, please do not post settings that you copied from someone else.
~ CPU Release 2013-04-29 ~
~ GPU Release 2013-04-29 ~
Top: A graph that estimates the total amount of dissipated power. Beware of the horizontal line, as it is the highest value that Samsung and Google have designated. Here you can see, how undervolting and overclocking can combine to higher performance without higher heat emission (with Enigma's Crème de la Crème Preset up to 1900MHz CPU clock). This way you actually can safely overclock the CPU. (pingguo is not responsible for any damages on devices other than his own. They are in perfect condition, though. I'm just saying this because everyone does.)
On the left, you can see the differences between the default voltages and custom values.
The right side indicates the power consumption compared to default values. This might be the most important graph!
Source: http://en.wikipedia.org/wiki/CPU_power_dissipation
Matlab-Sourcecode, for the enthusiasts:
Code:
ping = [ 100, 200, 300, 400, 500, 600, 700, 800, 900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100];
guo = [ 900, 900, 900, 900, 900, 912, 925, 950, 962, 987,1012,1037,1075,1100,1137,1187,1225,1250,1275,1300,1325; % DEFAULT
800, 800, 825, 850, 875, 875, 900, 900, 925, 950, 975,1000,1025,1050,1075,1100,1125,1160,1200,1250,1290; % Butterlicious, Margarine 2013-04-24
750, 750, 775, 800, 825, 825, 850, 850, 875, 900, 925, 950, 975,1000,1025,1050,1075,1110,1150,1200,1240; % Crème de la crème 2013-04-24
785, 785, 785, 785, 785, 790, 795, 815, 835, 865, 890, 915, 955, 985,1015,1055,1095,1125,1165,1205,1325; % PINGGUO
% 760, 760, 760, 760, 760, 765, 770, 790, 810, 840, 865, 890, 930, 960, 990,1030,1070,1125,1165,1205,1325; % PINGGUO-AGGRESSIVE
];
ref = ones(length(guo(:,1)),1)*guo(1,:);
pingg= ones(length(guo(:,1)),1)*ping;
hvhf = ones(1,length(ping)) *1700*1225^2; % max. f*V^2 with default settings
subplot(2,1,1);
plot(ping,[pingg.*guo.^2;hvhf]);
axis([ping(1),ping(length(ping)),0,4E9]); % set Y limit so that it looks nice
xlabel('Frequency / MHz');
ylabel('f * V^2 ~ Power Consumption (Arbitrary Units)');
title('Total Power Consumption; Horizontal Line = Maximum with DEFAULTS');
subplot(2,2,3);
plot(ping,guo-ref);
axis([ping(1),ping(length(ping)),-200,20]); % adjust Y range if necessary
xlabel('Frequency / MHz');
ylabel('Voltage Offset (V - V_{DEFAULT}) / mV');
title('Nexus 10 CPU Undervolting: Voltages');
grid;
subplot(2,2,4);
plot(ping,(guo./ref).^2*100);
axis([ping(1),ping(length(ping)),0,110]);
legend('DEFAULTS (KTManta-04-19-2013)','PRESETS Butterlicious, Margarine (EniGmA1987)','PRESET Crème de la crème (EniGmA1987)','[email protected] (Hotplugging OFF)','Location','SouthEast');
xlabel('Frequency / MHz');
ylabel('(V / V_{DEFAULT}) ^2 ~ Power Consumption (Percentage)');
title('Relative Power Consumption');
grid;
Most of this ugly piece of code works automatically for everything, just write into the matrices and check the lines with commentaries. :silly:
Cheers,
苹果
Bus overclocking is not something the user controls, the kernel sets that. The previous 3 versions of the KTmanta kernel all have a 25% bus overclock, Trinity also has this same thing. But the latest version of KTManta does not have a bus overclock. So people need to specify which kernel version they are on so that everyone knows what features it has.
EniGmA1987 said:
Bus overclocking is not something the user controls, the kernel sets that. The previous 3 versions of the KTmanta kernel all have a 25% bus overclock, Trinity also has this same thing. But the latest version of KTManta does not have a bus overclock. So people need to specify which kernel version they are on so that everyone knows what features it has.
Click to expand...
Click to collapse
Thanks for the comment, I updated the code template.:good:
Preview online, just to let you know what I intended.
Currently I am trying to fix the sleep of death that my Nexus 10 is suffering from... Advice would be highly appreciated.
(It does not wake up when I press the power button after some screen off time. Only a hard reset brings it back to life.)
Edit: I am not yet sure about it, but seemingly, the problem does not occur when I use a governor which keeps both cores running at all times...
pingguo said:
Preview online, just to let you know what I intended.
Currently I am trying to fix the sleep of death that my Nexus 10 is suffering from... Advice would be highly appreciated.
(It does not wake up when I press the power button after some screen off time. Only a hard reset brings it back to life.)
Edit: I am not yet sure about it, but seemingly, the problem does not occur when I use a governor which keeps both cores running at all times...
Click to expand...
Click to collapse
Are you using the KTmanta kernel? If you have hotplugging enabled and you undervolt too much, sleep of death will occur.
For me, I have to raise my minimum voltage to 830 with hotplugging enabled to prevent sleep of death.
If I have hotplugging disabled, I could undervolt way low than that
c19932 said:
Are you using the KTmanta kernel? If you have hotplugging enabled and you undervolt too much, sleep of death will occur.
For me, I have to raise my minimum voltage to 830 with hotplugging enabled to prevent sleep of death.
If I have hotplugging disabled, I could undervolt way low than that
Click to expand...
Click to collapse
Yup, I'm on KTManta. Also, hotplugging seems to be exactly the reason for my SODs.
Now the big question is: What is more efficient - Hotplugging and thus saving 50% of the power, or stronger undervolting, saving 25%, and maybe more effective racing to idle with both cores?
BTW, are you implying that hotplugging is always performed at the lowest possible frequency?
Edit: There is still one thing that puzzles me: Hotplugging while the screen is on works perfectly fine at the voltages which cause the SOD...
pingguo said:
YWhat is more efficient - Hotplugging and thus saving 50% of the power, or stronger undervolting, saving 25%, and maybe more effective racing to idle with both cores?
Click to expand...
Click to collapse
Hotplugging doesn't save 50%. The theory of it does but actual execution that is not even close to possible. It saves 2-3% battery
This may seem like a very noob question, but I am running the nightly builds of CM10.1 and I just installed the KTmanta kernel but I don't see where to change any governor settings. Is it an app I need to install? Help?
EniGmA1987 said:
Hotplugging doesn't save 50%. The theory of it does but actual execution that is not even close to possible. It saves 2-3% battery
Click to expand...
Click to collapse
Well, then I feel very comfortable with undervolting only. :laugh:
parakalien said:
This may seem like a very noob question, but I am running the nightly builds of CM10.1 and I just installed the KTmanta kernel but I don't see where to change any governor settings. Is it an app I need to install? Help?
Click to expand...
Click to collapse
Install the KTweakerT app from the kernel forum thread.
Updated the CPU graph with some overclocking data. Please let me know whether or not it is true that OC with no increase in heat emission is safe.
Update:
Graphs should be more comprehensible and informative.
Added full source code for you source lovers.
Cheers!
pingguo said:
Updated the CPU graph with some overclocking data. Please let me know whether or not it is true that OC with no increase in heat emission is safe.
Click to expand...
Click to collapse
The three most damaging things to a processor are: amperage, voltage, and heat. Heat is tricky, because every processor has a maximum heat limit it is designed for. The more heat you have the less life your processor will have. However, if you stay within its maximum heat limitations then the processor will still last many many years, as soon as you get above that heat limit you start damaging the processor extensively, greatly lowering its lifetime and possibly causing irreparable damage in that you can no longer run at the higher core speeds stably anymore. So you always want to stay within heat limitations, preferably as cool as you can.
Amperage is also highly damaging to processor silicon, but thankfully we dont really control this up or down on most processors. One good example of this can be seen with RAM, which you can control amperage on. The best example here is RAS to RAS timings, which is when the RAM chips get pulsed with large amounts of amperage. It has been many many years since I looked into the technical details of this, but I *think* this happens when a row of addresses is pre-charged before access or something like that. Normally this happens every 4-6 cycles on average. Many people in order to increase stability of their RAM overclocks would lower this, I even did some stuff for a while with a setting of 1 for this timing. Because of low values on this timing the RAM is getting pulsed with large amounts of amperage quite frequently and this was causing massive degradation of the cell structure and creating micro-holes in the silicon. These holes then in turn require more amperage to remain stable at your MHz speed in order to overcome the damage, and with the higher amperage needed you continue to accelerate the damage. It is just a snowball effect of damage to the RAM chips that leads to complete death of the chip in a few months. This was why you saw large failure rates on DDR2 RAM at one point "back in the day" when D9GKX and GMH chips were all the rage. So all that to say, large amperage is bad for computer chips.
Next up is voltage, which we do control. More voltage is needed for high MHz speeds as we need to make the transistors switch faster and have more power to give in order to achieve higher speeds. Higher voltage leads to greatly increased heat output, greatly increased battery drain, and also if you are using voltage above the chip's specifications causes damage to the processor itself. Lowering voltage is the best thing we can do to keep our processors running at their best. A tiny decrease in voltage will often be 1-2 degrees cooler in temperature, and usually means a few less watts as well (depends on chip architecture). Just last week I was overclocking an Intel i7-3930K processor. I had fun playing around with it and observing the changes happening. I observed with 1.4v and 4.5GHz core speed than power draw was 198 watts under 100% load. Going to 4.6GHz raised power draw up to a nice even 200 watts (2 watts more for 100 MHz). I then went back down to 4.5GHz speed and increased the voltage from 1.4v to 1.42v, and saw a temperature increase of 4-5 degrees on all the cores and a 6-7 watt power consumption increase. Just from raising the voltage that little bit.
So the best thing we can do for our tablets is to undervolt. But when overclocking, as long as you stay within the chip's voltage limits and heat limits, the extra core speed doesnt really affect the chip's lifetime at all, until you get many MANY MHz ahead of its design. if you can overclock up an extra 300MHz while still dropping voltage a bit you will see both a reduction in power consumption (even with the extra speed) and a reduction in heat. Although these reductions will not be as much since we are also generating small bits more of power draw and heat from the higher speeds too.
TL;DR
overclocking is fine and wont damage your processor as long as you remain at the same or less voltage and heat output.
(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
{
"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"
}
Revamped Advanced Interactive Governor Tweaks
This thread was originally made by Corndude which for some apparent reason, decided to delete his account. The task to update this thread is then passed on to @The Flash but unfortunately because the purple person is busy atm, I stole it from him. So I will try to keep this up to date with informations and everything about the interactive governor. I will also add helpful descriptions on each parameters just to help people who are into tweaking and give them a little push to start tinkering.
The original thread made by SoniCron can be found here: Advanced Interactive Governor Tweaks for the 5X
Helpful Links
Linux Documentation - CpuFreq
Most Up-to-date guide on CPU Governors by @Saber
Table of Contents
Download Section
Applications that Allow Kernel Profiles Setup
Diving Deep into Interactive Governor
Interactive Tweaks Explained
timer_slack: The amount of time in miliseconds; that the cpu will stay in the highest frequency before it applies "interactive" tunings again. Basically, if there is a cpu intensive application and you have a high cpu load; timer_slack delays ramping down to lower frequencies in a given "X" time. Also, since timer_rate will be erratic, this should help to decrease stutters.
(higher value: higher battery drain, better performance)
timer_rate: The amount of time in miliseconds; that the cpu will check how heavy the cpu load is. E.g. if you have set this to 20000, it'll compute every 20ms to see if any changes on the cpu load is making and will therefore adjust the frequency based on target_loads.
(higher value: less battery drain, performance impact subjective)
target_loads: The amount of load, in theory on percentage; where the actual frequency should be used. Target_loads can be setup per frequency to provide certain "bias" on cpu clocks. An example "35 475600:88 600000:21 960000:98" means that anything before 475Mhz would have a target load of 35%. At 475Mhz before ramping up there should be at least 88% of cpu load, once this threshold is broken it'll ramp up to 960Mhz immediately since 600Mhz is set less than 475Mhz. Therefore the two "bias" created on the sample above is 475Mhz and 960Mhz. It is not recommended to provide any values higher than 98 as this will reduce performance on your cat greatly.
(higher value: less battery drain, worse performance)
min_sample_time: The minimum amount of time the governor must wait at a given frequency until it can decide to reduce the frequency.
(higher value: better performance, battery impact HIGHLY subjective)
hispeed_freq: This would be the frequency that the user "assumes" would be enough to handle a boost in cpu load. Too high value would greatly impact the user's UI performance but would definitely worsen the battery life.
(higher value: higher battery drain, better performance)
go_hispeed_load: The load assigned to the cpu where it is recommended to go to the hispeed_freq. Set this quite high as this bypass almost everything in the interactive tunables.
(higher value: less battery drain, performance impact subjective)
above_hispeed_delay: A delay setup in frequency:miliseconds to slow down and "delay" aggressive ramp ups. E.g. 19000 600000:24000; provides 19ms delay to cpu frequencies not specified after reaching hispeed_frequency, before ramping up to a higher frequency. If, for example you have your hispeed_frequency set up to 960Mhz, and your above hispeed_delay to 30000 1248000:22000 1354000:40000; the 30ms will only be used at 960Mhz up until 1248Mhz where the delay is 22000. Please note that 30000(30ms) from the example above will NOT BE APPLIED to all frequencies BELOW the set hispeed_frequency (anything below 960Mhz). Also, specified "frequency:delay" ratios should be written in ascending order according to cpufreq linux documentations.
(higher value: less battery drain, worse performance)
align_windows: With the value of "1" for On and "0" for Off. If "1" is designated, the cluster for cpu clocks (divided into big and little) will fire at short quick intervals, usually by 1ms to provide a reliable boost to what timer_rate has converted cpu loads/clocks into.
(If ON: better performance)
max_freq_hysteresis: Checks the cpu for "hysteresis" or previous cpu clock records and base the next ramp up on frequencies previously used. If your cpu tends to have a bias towards lower cpu clocks, with this on a high value; it should frequently stick to lower cpu frequencies.
(higher value: less battery drain, performance impact subjective)
powersave_bias: Value of "1" to turn ON and "0" for OFF. If your cpu decides to go for 960mhz, with powersave_bias ON it'll go to a frequency one step below 960mhz.
(turn ON: less battery drain, worse performance)
use_migration_notif: Value of "1" for ON and "0" for OFF. Reevaluate the cpu frequency if "notified" (unclear, we can assume this as either an unschedule app notification or a "timed" boost) to fire in 1ms. This aids timer_rate in quick changes with system loads.
(turn ON: better performance, battery impact subjective)
ignore_hispeed_on_notif: Value of "1" for ON and "0" for OFF. Ignores the hispeed_load, hispeed_frequency and above_hispeed_delay once a cpu is "notified". Therefore, if a cpu is "notified" if this is set to "1" the cpu can ramp up to frequencies computed by timer_rate without any delays coming from hispeed frequency logic.
(turn ON: heavy battery drain)
fast_ramp_down: Value of "1" for ON and "0" for OFF. Ignores min_sample_time which provides delay on cpu frequencies in miliseconds. This holds true ONLY if a cpu is "notified" and therefore avoids unreliable "bias" on certain clocks due to quick shift of cpu loads.
(turn ON: less battery drain, performance impact HIGHLY subjective)
I highly encourage people to tweak their interactive governors on their respective kernels as this highly amounts to bettery performance and battery life. With that said, this concludes a simple revamp of this thread and I hope more and more people within the angler community would be interested to tinker. Imagine the possibilities!
CREDITS TO:
@The Flash - for letting me steal his thread because he slow af.
@soniCron - the main contributor for all of this, I don't know if he still exists.
Corndude - dude
@shadowstep - for being a good friend though he "mistakenly" killed his angler *retarded screeching*
@Saber - for providing the Most-up-to-date CPU frequency guide
@frap129 - for being really awesome and providing the community fraps.
And to EVERYONE that has made all this possible, I give the sun to you!
Download Links
Profile Download Links
Profiles by Alcolawl from @Alcolawl[/b]
[*]Profiles by Xsilas43 from @Xsilas43[/b]
[*]Profiles by .hEimDaLL from @.hEimDaLL
[*]Wingoku Profile from @fapste
[*]GlassCannon from @phantom146
[*]EXkm Profiles from @xperator
[*]Project Zhana OP3 Port from @deani77
Apps that Allows Kernel Profile Setups
Apps that Allows Profile Setups
Exkernel Manager App by @flar2
Spectrum Kernel Manager by @frap129
Kernel Profiler by @frap129
Diving Deep into Interactive Governor
Diving Deep into the Interactive WorldUnderstanding how parameters co-exist and the OP's viewpoint regarding cpufreq.
The interactive governor has been around for years and is without a doubt the most popular cpugov present in the linux archives. The development of this linux-based core has been ongoing, patches and evolutions to interactivex has been widely appreciated by android enthusiasts and non-enthusiasts alike. Interactive governor is also without a doubt, the majority baseline for new governors being developed which goes to prove that it is one of the most efficient and optimal cpugov within the world of android fanboys.
Before we start, take a look at this graphic thingy:
There is no such thing as a "perfect" balance. I myself, live by a code to never ever let my phone slow down just for the sake of bragging that I got this SoT *autistic screeching*. If you have to choose between the two of those, I would wholeheartedly suggest to finish tasks first (yielding better performance) than just idle in despair looking at your battery percentage the whole day. Lastly, please do bring a powerbank with you.
Enough with this, let's talk facts:
I will be breaking down the parameters here, how they should co-exist with other parameters and what you should change in order to provide a smoother experience. We will also be digging deeper as to how each parameters should help you with your daily usage. Let's begin.
Hispeed_Frequency Logic:
The hispeed logic is what makes your angler boost, not gradually; but burst through the set optimal load you deemed necessary for task completion. We consider this very important as this provide the overall smoothness, task completion time and if used properly along with other parameters; may yield to better battery.
hispeed_frequency: This is the bread and butter of the interactive governor. What makes interactive unique to others is the user can set a specific frequency "bias", where he/she finds it optimal(according to usage). When paired with input_boost, this significantly increases responsiveness and smoothness to overall android feel. Personally, I would never recommend to set hispeed_frequency to the lowest cpu clock e.g. 384mhz because it will defeat its purpose of "burst" boosts. In the past, many users attempted to set hispeed_frequency to the lowest clock to prevent sudden scaling from cpu frequencies however, in turn, they have to sacrifice the responsiveness of the device A LOT. If you want to still try it, I'll bet my scrotums again that switching between apps and opening your angler coming from deep sleep/doze without a fingerprint_boost (featured in Flash kernel and Electron) would stutter and cause you to at least lag for a second.
From tests, my best recommendations for a hispeed_frequency are:
600/634mhz - If you are a typical light user, opens your device to read a lot of stuffs about growing back your pubes and ruining the timeline, like barry. Whenever you are switching from a light app (reddit, 9gag, fb) to a heavy app such as Youtube, you should experience a slight stutter but you could still live.
960mhz - Good enough to balance almost everything. From light users to heavy users, this should be optimal. Personally never experienced jitters coming from hispeed_frequenciy set to this (except with really low timer_rate).
1248mhz - Fast and extremely reliable but unfortunately should give you a little more drain. On the flipside tho, it is the default input_boost/hispeed_freq from interactive itself as well as other variations of the governor. If you use heavy apps a lot such as games and likes switching stuffs a lot, stick to this.
Anything above 1248mhz I would really not recommend. Coming from personal tests, It does run phenomenal but it is too much of a waste. That performance isn't worth the battery expended so with all due respect just stick to a lower frequency.
go_hispeed_load: Provides the desired load from 0-X depending on the user's preference. This bypasses your set target loads from below your hispeed frequency e.g. if your hispeed_freq is set to 960 mhz, anything under 960 mhz is bypassed whenever the "assigned" load threshold you input in this parameter is reached. Meaning, even if you set 302mhz as 999 on your target loads, whenever your timer_rate computes a load that has at least reached to your assigned go_hispeed_load it should automatically ramp up to your hispeed_frequency. However, this does not mean you can abuse the power of your target_load. Setting your target_load too high below your hispeed_freq would still give you lags especially if your timer_rate is above 50000. Just a tip: you can make this to 0 if your input_boost is set to your hispeed_freq.
input_boost: Technically not part of the interactive parameters but still worth the mention as this copies the hispeed_frequency logic and helps maintaining boosts. The input_boosts increases your frequency to the assigned value whenever a task is loaded in your device. This does not work like touchboost as touchboost is a nuclear waiting to explode. Input_boosts scales even if your screen is off (but rarely) and wouldn't increase your phone's clocks whenever you touch it (boop boop). Rather, it only boosts your device whenever necessary (e.g. IO overheads, task completion, downloads, alarms syncing).
If you really like the most optimal performance your cat can achieve, aim to put input_boost the same as your hispeed_frequency values'. It should not waste too much battery and should still be controlled by above_hispeed_delay.
Controlling your Hispeed_Frequency:
There are only two parameters that can actually control your hispeed_frequency scaling namely go_hispeed_load (mentioned above) and above_hispeed_delay. However, a third one which is quite special; ignore_hispeed_on_notif can also impact at how the governor performs, let's dig in to it:
above_hispeed_delay: Is a "delay" timer in miliseconds set by the user with the format "Initial delay, frequency:delay miliseconds". The intiial delay is applied to all frequencies EQUAL TO OR ABOVE the hispeed_frequency, whilst the frequency:delay ratio is applied per specific frequencies again EQUAL TO OR ABOVE the set hispeed_freq. E.g. if you set your hispeed_frequency to 960mhz, and you have set your above_hispeed_delay to (X 384000:Y 600000:Z 960000:M), Your X value would be aligned to all frequencies above 960mhz (since you specified a delay in 960mhz) whilst your Y and Z is IGNORED, because you're retarded short-sighted enough to not read what I and the linux archives just said.
I personally, do not recommend hispeed_delay to be above 35000 unless you're eager to "suspend" or provide "bias" on a specific frequency. This is because I find 35000 and anything above that to be too long for a delay and should provide you nothing but lags and would just piss you off instead of providing a better battery. If you do want to suspend a cpu clock make sure that it is efficient enough (e.g. 1248mhz or above) to handle heavy loads.
ignore_hispeed_on_notif: Turn on by input of "1" and must have use_migration_notif to "1" also otherwise it won't work. The ignore_hispeed_on_notif (damn that's long) as the name puts it; ignores the hispeed logic, meaning your above_hispeed_delay and go_hispeed_load is ignored whenever the hrtimer (a special timer) coming from use_migration_notif triggers. This usually yields better performance but at the cost of a huge battery drain, since hrtimers also trigger on deep sleep, therefore; most likely, your cpu would scale up even though you think there's no task happening in the background. I do not recommend turning this on, please do not, you kennot.
The Caviar of Target Loads:
The most sought to parameter in the interactive kernel is the target_loads. Along with hispeed_frequency, target_loads is another parameter that makes the interactive governor the most flexible, controllable and probably battery-friendly cpugov. You can adjust this to function as a performance-like governor, a powersave or even imitate how conservative governor gradualy boosts. Below, you will see tons of explanations and what criticisms I personally got about target_loads:
target_loads: Computes the load per frequency ratio, in the format of "X 600000:Y 960000:Z" and so on, depending on the users' perceptive usage. Where X, is the initial load given to all frequencies below the first specified frequency:ratio stated (therefore in the example, anything below 600mhz), and Y/Z are loads given to specific cpu clocks. The target_loads unlike above_hispeed_delay, isn't linear. You can start off with a high frequency ratio of 384000:88 then go down to 487600:22 and get back up to 90 at 600mhz. Because of the latter, you can provide "bias" on certain frequencies you deem to be fast enough to handle specific loads.
Just a heads-up. I do not believe in optimal and nominal frequencies. I think those were just bullshified terms that was made so people would have something to bias the loads to. The optimal frequency should be your "preferred" frequency. There is no 960mhz when watching youtube nor the specific frequency for just reading webpages at 600mhz. There are certain apps that are relies on heavy foreground (e.g. whatsapp and snapchat) or sometimes even fb, and if you're gonna stick to 600mhz because somebody told you its the optimal frequency for users that just reads, you can kiss my grandma. Everything differs, a good android enthusiast should and will explore what frequency they think their usage fits. It's just that simple.
Before trying to input random numbers on your target load, try to see what your perceptive usage is. If you would like your device to stay on lower frequencies as much as possible, put a value between 75-92 on clocks below your hispeed_frequency. Anything above that might lead to stutters depending on your min_sample_time and timer_rate.
Provide higher load thresholds on your hispeed_frequency and above. Since you have set your hispeed_freq to be the most optimal cpu clock all-around your dynamic loads, provide a higher threshold to it (e.g. 90 and above) so your kernel will bias to it more unless heavy loads are on play.
Put a value of 98-99 to frequencies you deem to be the most efficient on heavy loads. I personally like 1248mhz a lot and therefore use it as my cpufreq for heavy loads. Setting your load to 99, rarely makes your frequency go higher than the specified cpu clock, whilst setting it to 98 is decent enough to gradually let frequencies ramp up from it.
An important note. You can create certain "bias" towards cpu clocks as I have stated above, target_loads aren't linear and therefore, frequencies you deemed to be slow enough to handle cpu stressmay be given less priority. This is done by providing any loads below 50. E.g. 384000:75 487600:22 600000:88 672000:35 960000:95 by using the example given, your cpu clocks should bias towards 384mhz, 600mhz and 960mhz respectedly, eliminating the need for 487mhz and 672mhz. We do this to provide better responsiveness for our cats and I personally recommend trying this until you find your sweet spot.
Providing the Delays of Responsiveness:
Delays aren't only used to slow down the ramp up of your cpu clocks. They are also used to delay things such as the given time of each cpu frequencies before ramping down. Because of this control, the interactive governor provides a better all-around smoothness than any other governors out there, combined with your target_loads and hispeed_frequency; fluidity should never be an issue!
min_sample_time: If above_hispeed_delay provides a delay before the cpu scales up, min_sample_time is the other way around. Min_sample_time is a timer in miliseconds with X0000 format, used as a delay for all cpu clocks per cluster, before it ramps down, assisted by computations coming from timer_rate. As one of the core parameters in android to provide fluidity universally, this parameter could be swapped for input_boost delay and providing a higher timer for this with lower timer_rate, in my own experience; provides you the capability to totally negate input_boost.
Experiment on this one as this is very subjective. I do suggest that if you have a high timer_rate , provide a higher min_sample_time value or else your kernel won't be as responsive as you would like it to be.
timer_slack: to assist timer_rate to provide a stable and constant performance track, timer_slack in miliseconds, provides a delay on the highest frequency of the governor. Because timer_rate especially if below 40000, computes the frequency of the current load given to the cores, min_sample_time aids to slow down timer_rate's aggressive approach to either ramp up/ramp down the frequency. An example of this is moving to another app from one foreground to another, if timer_rate has been set low enough that it computes the switching to provide a higher frequency then within 20ms to ramp down because the load has settled down, timer_slack prevents this from happening, and thus should create responsiveness to our devices. This again is highly subjective. Play on its values depending on your needs, most developers or interactive enthusiasts use -1 to prevent timer_slack from delaying the high frequency which provides a better battery life.
Underrated Parameter; the Timer Rate:
timer_rate: is probably the most undervalued and underrated parameter there is in the interactive governor. Most governors have this parameter and is rarely, I mean rarely! appreciated. You have to change that notion starting now. Timer_rate provides things two ways. Lower value equates to faster response and performance while higher value provides longer battery life. Of course the latter means you'll be sacrificing your device's fluidity.
The default timer_rate is 20000. This means that every 20ms, your governor will compute the loads burdened to your kernel and timer_rate will provide the signals to target_loads to adjust depending on the values given.
An "efficient" timer_rate clocks in between 20000 and 40000. By my own tests, anything above 40000 slows down the "frequent" change of cpu clocks. As a proof, you can check your kernel manager's dashboard and set your timer_rate higher than 40000; you will notice that it won't be jumping from one frequency to another too much.
A high timer_rate could still be efficient given that you have a high min_sample_time and a reasonable timer_slack. This three holy trinity, when tweaked properly, should give you better performance without the significant drop of battery life for our angler.
The Special Parameters:
There's a (3)three parameters that I would like to call special. This is because they can be turned off and wouldn't cause any significant changes to the interactive governor and from the fact that they need use_migration_notif turned ON to function. Also, just a quick mention, during my long tests; I find some of these parameters intrusive so I wouldn't really recommend them turned ON unless you are willing to experiment on things.
use_migration_notif: can be turned on with the value of "1". This is the core switch for fast_ramp_down and ignore_hispeed_on_notif (please see hispeed logic for description) to work. With this on, migration timers also known as hrtimers (see Hrtimers - Linux Archive for spot-on description) are allowed to be computed as a "load". This can be comparable to ignore_nice_load from other governors however, unlike the latter, use_migration_notif needs to be turned on to work. To summarize, with hrtimers computed as loads, this should provide more gradual boosting than before, especially that hrtimers for linux kernels are made to "optimize timer-wheel" but the battery impact is highly subjective. Also, hrtimers may fire while on deepsleep, though it won't break doze, this would increase your cpu frequency as it is computed as a positive load from your kernel and should therefore drain a little more battery, especially when you have ignore_hispeed_on_notif set to 1.
fast_ramp_down: can be turned on by setting value to "1". This simply ignores min_sample_time for hrtimers and therefore should provide you better battery life. Whenever your cpu clocks ramps up due to hrtimer, min_sample_time would delay the cpu frequency before going down but with fast_ramp_down if the load computed by your kernel is indeed an hrtimer, it'll ignore min_sample_time value and proceed to ramp down the frequency in 1ms.
Turning the three: use_migration_notif, ignore_hispeed_on_notif and fast_ramp_down ON is something that I would never recommend, unless you're experimenting, doing your own tweaks or holding on to your dear life. There is no way we can accurately measure this three unlike the other parameters provided, also; hrtimers are being patched from one kernel to another and is being updated constantly, I am pretty sure in the future we would be taking advantage on that parameter soon.
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Second this. Been following on the 5x page as well and was using Ghostpepper until earlier today. For me ghostpepper got me the best SoT(5hrs)with average usage (mainly whatsapp, Facebook mobile site, instagram, Spotify and some GPS usage with it on high accuracy). Now using Butterfly and so far performance is outstanding, excited to see what the battery life will be. Huge thanks to @soniCron for the work!
moraytadroidz said:
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Click to expand...
Click to collapse
Any info on what is the best for battery life? Don't really care about performance, it's fine on stock imo. So far I have not noticed any difference in battery life between this and stock.
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Alcolawl said:
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Click to expand...
Click to collapse
Thank you. Glad to have you checking on this thread as well!
I'm not sure it's necessary to copy the text to each of the posts verbatim... I'd suggest linking to the original posts and then add on 6P-specific info (such as frequency ranges, voltage levels, etc) so as to not overwhelm your users. (I also recommend this because the OP guide on the 5X forum is going to get a full rewrite incorporating everything we've learned thus far, sooner than later.)
I have no problem with you duplicating the text, mind you. I just think it might be better for your users if you linked rather than duplicated. (Especially if it's not updated with the 6P in mind.)
I'll try to keep track of this thread for a while, but if anyone urgently wants my attention, PM me.
Great work, guys!
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Franco works just as well. It's only important that you can disable touchboost.
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
+1 on thread! Test it yourself.. I've had great success on GhostPepper.
Evolution101 said:
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Click to expand...
Click to collapse
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
nadiros said:
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
Click to expand...
Click to collapse
I think you might be thinking of the Redhawk alpha. Butterfly is for the interactive governor
Gytole said:
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
Click to expand...
Click to collapse
Really ? Gonna give that a go!
Thanks for starting this thread
I'm finding ghoststepper to be very smooth - butterfly was certainly a sipper but slightly less smooth for me I think.
@Corndude Glad to see this here, too - I've been following the OP on the N5X forum since soniCron posted it.
One suggestion: maybe put "[WIP]" or "Work In Progress" at the start of the thread title as I know the 6P is having less than desirable results in comparison to the huge benefits they're seeing on the 5X & it would be a shame if people were put off by bad reviews/comments of the tweaks before we (as a community) can stabilise the settings to give great battery life without affecting the performance at all.
I know GhostPepper is very close to getting there (6.5-7.25 hrs SOT for me), but I still think we can squeeze much more out of this theory - I mean, we have a much larger battery with the same software specs, so we should technically be able so squeeze at least another 1/2 hours SOT out of the 6P if 5X users can get 8/9hrs SOT.
ps. just a heads up - your "head on down to the 2nd post" in the OP links to the 5X OP & the OP also includes 5X frequencies - these should probably be swapped out of the 6P frequencies, otherwise people might try inputting them to their 6P's (which will result in target_loads not saving)
edit: 6P Maximal/Minimal loads for OP.
CPU #1 Maximal Efficient Loads
384000:75
460000:69
600000:80
672000:79
768000:80
864000:81
960000:69
1248000:84
1344000:82
1478000:86
1555000:0
CPU #1 Minimal Efficient Loads
460000:20
600000:30
672000:12
768000:14
864000:13
960000:11
1248000:30
1344000:8
1478000:10
1555000:5
CPU #2 Maximal Efficient Loads
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:84
1344000:84
1440000:84
1536000:85
1632000:85
1728000:85
1824000:84
CPU #2 Minimal Efficient Loads
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1728000:6
1824000:6
1958000:7
As the title says, is it really worth? I mean, should i decrease my phone maximum clock speed of the cpu by, like, 100-200 mhz in order to notice less battery consumption?
thanks
You can decrease the cpu clock speed for better battery life. But don't decrease to 100-200 mhz. It can cause constant random reboots and make your device very unstable.
Really? I'm using my s3 neo with a clockspeed of 1.3 ghz instead of 1.4, and i'm rarely noticing strange things