Undervolting, ABB, and more - All you need to know...
Originally Posted by KNIGHT97
And fir the advanced users (with text reading that, in red color) some ABB settings would be good too
Am sure Devs, others and I too have said this across various places, so I will skip the intro to ABB and go straight to tuning it for our benefit. The only things you need to know before getting the hands dirty are ( @KNIGHT97
I know you are no newbie, but this post will cover some basics too
- Do your homework - ABB is not for the faint hearted. If you are not ready to put in some time to test multiple combination of settings, have the phone freeze on you several times until you perfect it, this is not for you. Stay with the UVing that we are used to, or stick with the -25/ -50 - 75 mV undervolting.
- ABB will vary with device. You need to know the ASV of your device (/sys/devices/system/abb/abb_info - the last line in this file tells what your phone's ASV value is), and then go about changing the values keeping your ASV's values as baseline.
Anyone jumping in late, make sure you read the changelog dated 22nd April 2013 in this post
. All credits for whatever I know about this goes to @AndreiLux
and all that I say here are from the post I have linked and what I did from there. Another good read will be this thread
, where @cba1986
has collated a lot of inputs from AndreiLux and a few others.
Before you play with ABB, have your stock gate voltages and stock body voltages handy (these are also in the third sheet of the spreadsheet I have attached).
So here is how I went about this whole task - the prerequisite is you pick a stable (preferably stock ROM, and kernel that supports ABB (of course) and is deemed stable for everyday use). This is important because you do not want a freeze occurring due to a kernel or ROM anomaly to impede on your undervolting decisions
Undervolt the gate of the device (the usual voltage we all undervolt) step by step. When I say step by step, what I mean is
- Undervolting it based on a rough logic (say, -50 mV) and letting it run for a day
- Then undervolt ONE FREQUENCY STEP a bit more (say by 25 mV). Let in run one more day.
- If your phone didn't act weird (SoD, random freeze ups, etc.) then undervolt THE SAME STEP SOME MORE (by another 25 mV), let it run one day more
- Rinse and repeat until your phone freezes up during the course of the day. And when it does, reduce the undervolting by, say, 12.5 mV and see if all goes well for that frequency (else reduce the undervolting some more)
When doing all this, make sure you are putting your phone to full use - watching videos, playing audio through bluetooth, Wi-Fi, et all. Repeating this for every frequency step will give you the maximum undervolting your phone can tolerate, Congratulations
The Body voltage - the one that ABB-enabled kernels let us play with
By default, you will have 4 sets of body voltages - one for the 200 MHz step, one for 300 to 800 MHz steps, one for 900 to 1600 MHz steps, and the last one for anything higher. Using BetterBatteryStats (or any other tool that works for this cause), find the amount of time your phone spends in each frequency step while it is awake and
while on battery. Note that the voltages or their combinations I mention here on may be for a ASV 1 device, YMMV.
The frequency that almost everyone's device uses the most must be 200 MHz (we are not going to factor the Deep Sleep time here). The stock gate voltage for this step is 912.5 mV, and for an ASV 1 device, the stock body voltage is 750 mV. That is, the gate voltage is higher than the body voltage - what this means is that while the CPU will be able to clock easily, it will also have a higher static leakage (Forward Body Bias). So, for lower frequencies, we have to try and bridge the gap between these two voltages such that the gate voltage is lower than the body voltage
, thereby saving on static leakage. Let's assume that you were able to get the phone undervolted to 837.5 mV (-75mV undervolting) and find it stable. You will have to overvolt
the body to 850 mV so that you will have a -12.5 mV difference between the gate and the body, give you what is called a Reverse Body Bias - in this state, the CPU will find it difficult to ramp the clock, but it will not leak static current. With the same assumption of 837.5 mV at gate, and with 850 mV at body, you will have to go through the 24 hour observation cycle for freeze ups or SoDs - if they occur, it means your phone is finding it way too difficult to ramp the clock up at these voltages - in which case, you will raise the gate from 837.5 mV to 850 mV (while the body remains at 850 mV)
. When you do this, you are actually undervolting the gate by -67.5 mV and overvolting the body by 100 mV - while this may sound bad to achieve a 37.5 overvolting after going through too much trouble, you are actually overvolting a bit to arrest static leakage which is a higher cause of drain at lower frequencies.
For steps 300 to 800 MHz, you will follow a similar logic, and find a body voltage that, while might be a bit
higher than the stock, will give you a negative or zero difference between the gate and the body as much as possible. The same procedure of validating the value you choose by letting the phone run a day's course is imperative. A Word of Caution
: The 800 MHz step is a bi*ch. If you encounter a hang or a freeze, increase the gate voltage, or reduce the body voltage such that the 800 MHz step is at a low or zero RBB and keep it in observation. If this step is not the cause of the freeze up or SoD, then go through the usual cycle of manipulating the voltage of each step. Rule of the thumb from here on is to change the body voltage such that most or all of the frequencies between these steps will be in RBB (have a 0 mV difference between gate and body, or a lower positive value- like +12.5 mV). Depending on your phone's ASV, you may very well end up effectively overvolting your device here too by applying a higher than stock voltage at the body, but the same purpose as the 200 MHz step applies here - only a little less pertinent because the time your phone spends in these steps will be about 40% lower than the time it spends in the 200 MHz step.
For steps from 900 to 1600 MHz (and above), where a phone spends roughly 30% of it's time on, the more important factor is to ensure the CPU is able to scale. And, to increase the body voltage to match the gate voltage to create a reverse bias or a lower forward bias will be an overkill of an overvolt on the body. So my suggestion, at least for ASV 1 CPU is to leave the body voltage of these frequencies to stock, and be happy with whatever undervolting you achieve at the gate.
- Forward Bias will enable higher undervolting at the gate, but will have a higher static leakage. Reverse bias will arrest static leakage to a greater extent, but it will be difficult to undervolt as much as you could in a Forward Bias setup. This is why you may have to increase the gate's voltages a bit more than without ABB, to achieve a stable system (that will have a much lower static leakage)
- The most positive indication of a good ABB/ Voltage configuration is that your device will run relatively cooler because of the obvious reduction in static leakage
- In most kernels, you can change the body voltage by 50 mV steps (700, 750, 800, 850, etc.) - anything else will be rounded up
- You can change the thresholds for the Body voltage steps (example - change the 300 to 800 MHz step to, say, 300 MHz to 900 MHz, which will also change the next step to 1000 to 1600 MHz). But it my various, time consuming experiments, there is no perceptible gain. This is of course not true for all phones, so some of you may still benefit on a case to case basis
- The process for modifying the gate and body voltages for the GPU are similar to the above. And not all kernels allow modifying the gate voltages for MIF and INT, in which case, I recommend that you do not touch the body voltages either
- The BetterBatteryStats input on how much time is spent on each frequency step is useful to adjust the gate and voltage combinations such that you will create a reverse bias as much as possible in the lower frequency steps that your phone will dwell on for a longer time. The attached spreadsheet will tell you that I have configured it in such a way that I have reverse bias in the steps that my phone spends 70% of it's time on, and am achieving an average of 7% overall undervolting - yes, all this for just 7% To put that into perspective, a -50 mV undervolt across steps will give you an overall undervolt of about 3%. To find that out, find the time spent in each step, the overall undervolt/ overvolt of each step (with or without ABB), and do a SUMPRODUCT in Excel against the total time spent in all the frequencies combined. Also, while % numbers are good to say and nice to hear, what matters is how much of a difference they actually make - for me, I have a super low battery drain in screen-off and during sleep - provided that some weird app or setting does not kill my battery
- Before putting a script with all your UV and ABB values in that init.d folder and giving it executable rights, make sure you put it in a harmless location (like /data/tmp), give it executable permissions and execute it from there, so that if your phone goes thermonuclear, all you would need is a hard reboot and not look at how to remove that darned script from init.d to even get to the home screen
I don't know if I caused more confusion than clearing them
Ask your questions, I (and others too, who have dirtied their hands in this amazing power-tool) will try to answer them as much as possible.
An important note on the attachment
- DO NOT APPLY THE VOLTAGES THERE BLINDLY EVEN IF YOU HAVE AN ASV 1 DEVICE. NOT ALL DEVICES, EVEN WITH THE SAME ASV BINNING ARE MADE EQUAL
. Do your experiments, at least attempt some and apply your findings.