Undervolting, ABB, and more - All you need to know...

Undervolting, ABB, and more - All you need to know... - Galaxy Note II General

KNIGHT97 said:
And fir the advanced users (with text reading that, in red color) some ABB settings would be good too
Click to expand...
Click to collapse
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.
Miscellaneous points:
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.

Yes, thanks for clearing this out. This is going to help many advanced users understand the gate and body voltage related settings and body bias related stuff.
While I read and read all the time, some of the points, I admist to have missed and you explained them thoroughly, so a big thanks to you for that.
And yes, like you said, starting from the basics, this is always good since it'll help some users get acquainted to this advanced tuning.
I ha e experimented and bencmarked carefully to get my best UV/ABB combo and I can easily manage 2 days with 6-7 hours SOT without any static leakage, plus I have quite a high UV (-90) so my device hovers around 28-33 degress in normal usage and 36-37 during heavy HD games. Stability checks, benchmarking, I/O scheduling and VM/Kernel tweaks have provided a super smooth experience.
I'll include a link to this in my signature, in case someone wants to learn about ABB basics and begin with advanced stuff
Have a good day
Regards,
KNIGHT97

KNIGHT97 said:
Yes, thanks for clearing this out. This is going to help many advanced users understand the gate and body voltage related settings and body bias related stuff.
While I read and read all the time, some of the points, I admist to have missed and you explained them thoroughly, so a big thanks to you for that.
And yes, like you said, starting from the basics, this is always good since it'll help some users get acquainted to this advanced tuning.
I ha e experimented and bencmarked carefully to get my best UV/ABB combo and I can easily manage 2 days with 6-7 hours SOT without any static leakage, plus I have quite a high UV (-90) so my device hovers around 28-33 degress in normal usage and 36-37 during heavy HD games. Stability checks, benchmarking, I/O scheduling and VM/Kernel tweaks have provided a super smooth experience.
I'll include a link to this in my signature, in case someone wants to learn about ABB basics and begin with advanced stuff
Have a good day
Regards,
KNIGHT97
Click to expand...
Click to collapse
Ah! I missed mentioning the lower device temperature point - will add that

Related

[Q] Undervolting vs. Battery life

Hi, I spend last few days optimizing voltage table on my Desire and it left me wondering.
I bumped into several situations where 2 or 3 frequencies would be stable on the same voltage level. My question is, theoretically, if 300MHz would use the same voltage as 800MHz, would the power consumption increase proportionally or would it remain fairly similar?
Seeing that 300MHz would need more burn time at the same voltage to complete a task that 800 MHz would do in fraction of that time and then idle, this leaves me puzzled. Is it better to always use highest frequency of the group with same voltage for better efficiency? Or does the slower frequency actually consume less power even though it has to work longer and uses the same voltage?
Please enlighten me or discuss

I would also like to be enlightened on this.

AFAIK your assumption is on the right track, get the job done as quick as possible & get back to idling...
Slightly off topic, but somewhat relevant
byrong did a great write up on the effects of cpu speed vs screen brightness power consumption here that may be be of interest...

Interesting but still doesn't answer one question:
If my 245, 368 and 768MHz would be stable at the same voltage, does it matter if I set 768MHz as my minimum/idle frequency instead of 245MHz? Would is consume more power in the long run say on conservative governor?
And what about the screen-off profile? Consider a scenario when I'm playing an MP3 while screen is off and the player will still take a lot of CPU power to pre-buffer the song, apply equalizer, post-processing etc. Now would that nearly constant burn theoretically consume more power on the 245MHz or 768MHz? It still has to do the same work and 245MHz should just have higher constant load, right?
And how about complete idle. Does it really matter if I idle on 245 or 768 MHz if the voltage and actual work done is identical?
This is I'm sure something everybody is asking but nobody knows the real answer. Unless I'm speaking utter rubbish it's perhaps time to run some tests.

Even if the voltages are the same for different frequencies, I'm sure higher frequencies draw higher amounts of current (as shown in byrong's research, although his voltage tables were not stated). If you change your min cpu freq from 245 to 768 MHz I'd almost guarantee more power consumption, even when idle. I could be wrong though. If you're so curious, why don't you try and post back?

I might be wrong but my $0.02
From what I can remember in class, Power = voltage x current
To do the same amount of work, supplying lesser voltage would mean more current is consumed. That said, if less work is being done at the same voltage, less current would be consumed.
So running the CPU at a slower clock cycle means less work is being done, so less current consumption, compared to running it at full 768MHz.
I think ... ;p

Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Even if your $0.02 are right, you're still talking about drawing less current over longer time or more current in a short burst. Of course there are apps like games that will probably take as much horsepower as they can get for redrawing the screen - in that case lower constant frequency is better, because higher frequency would actually have to do more work - drawing more FPS just because it can. For minimum frequency the situation is completely different as the apps only require bursts of workload.

nik3r said:
Well I think I will make some empiric testing as soon as I find a way to log current current (yea funny ) to a file.
Click to expand...
Click to collapse
I thought you read waydownsouth's link?
In the methodology section byrong states he used CurrentWidget to log current over time. You can also use Battery Monitor Widget.
By the way, his methodology is pretty excellent as it minimizes as many variables as possible, and he wrote his own script to keep the cpu working at a controlled rate. I think at a minimum, you should put the phone in airplane mode while conducting the tests.

Undervolting a Xoom - battery results included

I haven't been able to find any info on undervolting the Xoom, so have started this thread in the hope that some may find it beneficial.
What is undervolting?
It basically involves reducing the amount of electrical voltage running through the CPU. It does not affect the speed of the CPU at all, just the amount of power that it uses. The stock configuration of CPUs usually has a fairly high voltage, to cater for the fact that CPUs are not exactly identical.
Why undervolt?
Reduce power consumption, and therefore increase battery life.
Why not undervolt?
Can affect stability, and there is a small risk of damage to your device.
Disclaimer: Undervolting, like overclocking, does have the potential to damage your device. It's very rare, but not unheard of. I've never had a problem, but you may. Good luck, and don't blame me.
My config:
Model: MZ601 Xoom
Kernel: Tiamat Xoom v2.1.0
Undervolting software: SetCPU 2.2.4
My voltages before UV:
MHz mV
216 770
312 770
456 825
608 900
760 975
816 1000
912 1050
1000 1100
1200 1150
1408 1250
1504 1325
1600 1400
1704 1400
So after doing a bit of testing, I've found that I can lower my voltages noticeably throughout the range, reducing the amount of power my Xoom uses, and prolonging my battery.
My UV voltages:
MHz mV
216 770
312 770
456 775
608 825
760 875
816 925
912 975
1000 1000
1200 1075
1408 1125
1504 1175
1600 1250
1704 1325
Notes:
It is not possible to UV any less than 770 mV (with the kernel I'm using anyway).
Given that the mV for the 456 CPU frequency is so similar to 216, I set my minimum clock frequency to 456, which makes the device more responsive.
So, you may want to try these voltages, and see how they work for you.
To test: (Instructions for SetCPU)
Set your min & max speeds to the same frequency, for example 456.
Set the voltage of the 456 frequency to an amount lower that the current amount, for example 775. (It's generally best to adjust your voltage down only 25mv at a time.)
Perform a "Stress Test", for at least about 5 seconds.
If the device locks up or reboots, the mV is too low - try a higher mV.
Once you've found the optimal voltage for that frequency, move onto the next one, for example 608, then 760, etc.
If your device locks up or freezes during testing, you can force a reboot by holding down the Volume Up button, and the Power button.
The voltages I've used above may work for you, or you may have to increase them a little on your device. You may also get better voltages than me - if so, please post your results.

Battery test results
Performed some battery performance testing by doing the following steps:
1. Set the screen to not turn off, and brightness to 10% (screen needs to be on to keep the stress test running, and brightness low to minimise the battery drain of the screen, as that's not what we're testing).
2. Disabled all network connections (WiFi, Bluetooth, Data, GPS) to minimise battery drain by other factors.
3. Closed all other apps, and did not use the Xoom at all during the tests.
4. Charged Xoom to 100%.
5. Set CPU speed to 1504mhz using SetCPU (both min & max frequencies the same for accurate testing).
6. Unplugged the Xoom.
7. Ran "Stress Test" for 2 hours (give or take 20 seconds).
I performed the above steps for both stock voltage, and undervolted voltage. Results as follows:
1. For stock voltage (1325mV on Tiamit Tachi kernel), battery life went down to 62%.
2. For undervolted voltage (1175mV, which is nice & stable for me), battery life went down to 72%.
Findings:
I was expecting battery savings, but not quite this much.
Standard voltage (at 1504mhz) at this CPU load, drains at about 19% per hour.
UV voltage at this CPU load, drains at about 14% per hour.
Standard voltage at this CPU load, the Xoom would drain battery entirely after about 5.26 hours.
UV voltage at this CPU load, the Xoom would drain battery entirely after about 7.14 hours.
In addition to the battery savings, the Xoom was only slightly warm after the UV tests, but very warm after the standard voltage tests. (Standard voltage test was performed first.)
Note: For general usage (email, browsing, basic apps & widgets), the CPU is not as heavily used. But in situations where the CPU is heavily used (such as intensive games), these results show there is significant potential for battery savings.

super nice tips. Tq very much

126-608 -175
Others -150
This is my settings... no prob at all.

Would I use setcpu app or just use the Moray(in settings) or does it matter

rayhodge02 said:
Would I use setcpu app or just use the Moray(in settings) or does it matter
Click to expand...
Click to collapse
Not sure what the "Moray" is, but any tool capable of undervolting should be ok. I like and use SetCPU, but I've tried other tools on other devices in the past, and they did similar things.

nobody wants to share their result after trying?

Very good job, I try
Sent from my Xoom using xda premium

pls share ur best result

I try your results and they're unstable in function off the useful task, exemple impossible to play simple games.
That's all right just for basic tasks like navigation, music ...
Sent from my Xoom using xda premium

Hmm, your stress testing seems inaccurate.
I used your values and did a stress test at each frequency for around 10 seconds. No problem. But my xoom restarted just 5 mins later while I was surfing the net.
So I increased each frequency by 25-50 and it stayed stable since then.

for me i just underclock my xoom to 912mhz. it is almost as fast as 1ghz. and i save battery alot.

Gregus59 said:
I try your results and they're unstable in function off the useful task, exemple impossible to play simple games.
That's all right just for basic tasks like navigation, music ...
Sent from my Xoom using xda premium
Click to expand...
Click to collapse
Try bumping up the voltages a little bit at a time, until you find a stable setting. The settings I listed are what are stable for my Xoom (even intensive 3D games), but CPUs vary. What I get, others may not, and others may get better than me.

musashiken said:
Hmm, your stress testing seems inaccurate.
I used your values and did a stress test at each frequency for around 10 seconds. No problem. But my xoom restarted just 5 mins later while I was surfing the net.
So I increased each frequency by 25-50 and it stayed stable since then.
Click to expand...
Click to collapse
They're not 100%. The longer you stress test, the more likely the CPU is stable, but 10 seconds gives a general idea. If unstable, just do as you did, and increase by 25mv or so.

omnia1994 said:
126-608 -175
Others -150
This is my settings... no prob at all.
Click to expand...
Click to collapse
Can you confirm your mV values? -175 sounds like a big saving. Surely your mV is not less than the minimum 770?
What kernel are you using?

do some proper tests to establish how much extra time you will get from a fully charged batt.
i would think its perhaps a tiny bit at most...
the screen would take a huge amount of the batt, the processor would use only a small percentage, so surely cutting a small fraction off a couple of steppings is fairly pointless?

baron von bubba said:
do some proper tests to establish how much extra time you will get from a fully charged batt.
i would think its perhaps a tiny bit at most...
the screen would take a huge amount of the batt, the processor would use only a small percentage, so surely cutting a small fraction off a couple of steppings is fairly pointless?
Click to expand...
Click to collapse
1. It depends what you're using the device for. Games, for example, can use a lot of CPU, so undervolting in this instance, will definitely use noticeably less battery.
2. If CPU voltage throughput didn't make any difference, we'd all just run our devices at 1700mhz all the time.
3. With undervolting, I can run my Xoom at the same voltage at 456mhz, as it run at 216mhz. This means I set my minimum frequency to 456 instead, and for the same minimum battery consumption, my device is noticeably smoother.
If you want to know how much extra time you will get from a fully charged battery, YOU do some tests.

lindsaytheflint said:
Can you confirm your mV values? -175 sounds like a big saving. Surely your mV is not less than the minimum 770?
What kernel are you using?
Click to expand...
Click to collapse
Yes i m sure. Has been using these settings till now.. no prob at all. Using tiamat stock gpu kernal with moray rom

i agree that during low intensity operation the power savings are probably nearly negligible, but during CPU-intense usage it could save a bit.
I myself am not willing to leave my Xoom on full bore for a series of tests lasting 7-10 hours each just to quantify how much power undervolting can save under super extraordinary circumstances.
But even if the energy savings is an arguable benefit, the reduction in CPU temperature is not. That alone makes this worth doing, IMO.

Agree.. after setting it my xoom now has lower temp when playing it

[REF] Battery Drain Benchmarks

Spreadsheet of the Battery Drain Data
BATTERY DRAIN BENCHMARKS
VIDEO of how it's done! (Do NOT try it yourself!)
NEW: Lab study done by nathanson666 see here and featured on the XDA's portal and twitter here.
Summary of Results
#1 - With screen on, if the processor is Idle, 100MHz saves the most power.
#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)
For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.
#3 - The most power saving governor is Ondemand. If you need a high performance governor, use smartassV2, which offers some battery savings.
#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.
#5 - The matr1x kernel by mathkid95 mainly saves power through UV of the INT voltages. You may need to raise these if you have freezes/reboots with your phone (in addition to raising the ARM voltages). I found that a maximum of 1 mA can be saved through INT UV, regardless of whether the CPU becomes idle (or with screen off in deep idle), so this is a constant saving. However, it is a very small saving, and doesn't apply if the phone is asleep. Remember, reboots cost more juice than UV can ever save.
#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!
#7 - If you are determined to UV, I found that my phone would become unstable with UV settings that were fine when the battery was fully charged. So check what UV your phone can handle when your battery is nearly empty. Again I say: Because of the high likelyhood and massive battery drain that comes with a reboot, I highly recommend you DO NOT USE EXCESSIVE UV. Also remember, even with extreme UV, you will not increase battery life more than 2%
#8 - I found that with bluetooth or GPS preventing the TOP=OFF state, there was no additional power saving from Deep Idle, i.e. the TOP=ON state does not save power.
#9 - Kernels with the 65 fps hack will cause the screen to drain about 10% more power compared to the usual 56 fps.
#10 - Conservative does not save power! For further details and exceptions, refer to my new thread: here.
#11 - This is just general advice: if you are having very poor battery life, have you tried turning auto brightness off? And if you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.
#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.
ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Babhjhag.html
In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors. From my spreadsheet:
At 100Mhz
mV 1500 4.92mA
mV 950 2.83mA (default mV)
mV 800 2.58mA (UV saves some power)
mV 750 2.96mA (Extreme UV uses MORE power)
Same test but with Deep Idle enabled:
mV 1500 1.91mA
mV 950 1.49mA
mV 800 1.29mA
mV 750 1.49mA (Same result again but with DI enabled)
Referenced from my spreadsheet starting row 41.
Recommended reading: http://everything2.com/title/wafer+yield
Stock voltages for reference:
ARM
1000MHz @1250mV
800 MHz @1200
400 MHz @1050
200 MHz @950
100 MHz @950
INT
1000MHz @1100
800 MHz @1100
400 MHz @1100
200 MHz @1100
100 MHz @1000
Summary of Power States by tchaari (thanks!)
After research, and some explanation from Steve Garon, it is clear that Deep Idle & CPU Idle are two completely different things:
1) Three main CPU states are implemented in the standard android kernel: NORMAL, IDLE and SLEEP
2) Ezekeel added an intermediate 4th state: Deep IDLE. This saves more power but only when the processor has a background task to run while screen is off. Bedalus proved here that it really saves a considerable amount of power in particular cases (e.g. music playing when screen is off). A minority of users are reporting some slight instabilities with it, but they may in fact be caused by things other than deep idle.
3) The CPU IDLE backport is a replacement of the standard android kernel drivers used to put the CPU in idle/sleep states by the new ARM methods integrated in the linux 3.2 kernel. This backport is theoretically supposed to improve battery life (with just the basic 3 CPU states). It is 100% stable but no power saving has been shown either in bedalus' amp meter measurements, or Harbb's overnight drain tests.
Where did the other benchmarks go?
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
Power Saving Governors: this thread
Thanks to all the developers, and a big shout out to: Harbb for his dedicated testing; tchaari for his motivation, great ideas and inspiration; jcolinzheng for the idea to test Deep Idle at fixed frequencies (genius); aLNG for links to interesting and useful articles; Steve Garon for demystifying esoteric kernel technicalities and his excellent kernel itself; everybody else who helped; and of course Ezekeel for making Deep Idle work, and for a stimulating debate!

Harbb joined in doing specific battery tests, using the phone's battery graph. This is based on the phone's own readings (State of Charge or SoC for short). It's not very accurate for an instant reading, but over time, it does become more and more accurate. Therefore, Harbb conducted some very long (10 hour) tests. To improve accuracy further, he waited for the level of charge to drop to around 80% before each test. This eliminates the another source of inaccuracy, that the first 10% of the battery tends to deplete rather quickly (due to normal wear and tear over its lifetime). In fact, I use Ezekeel's Battery Life eXtender (BLX) to stop the phone charging early (at a user defined level: I prefer 90%) to help slow the deterioration of the battery's maximum capacity by preventing heat damage caused as the battery tries to absorb the final dose of charge above 90%.
Harbb's Data
Harbb's spreadsheet
Here's a summary of Harbb's 10 hour test findings, in order of best battery drain:
- 15% - SmartassV2 with DI
- 16% - Conservative with DI
- 21% - Lazy with DI and SOMF
- 23% - Lazy with DI
- 36% - Conservative
- 39% - Lazy
- 39% - Lazy with CPU IDLE
- 44% - Lazy with Eugene's DIDLE
- 48% - Lazy with Eugene's DIDLE and SOMF
[where DI means Ezekeel's Deep Idle, and SOMF indicates that Screen Off Max Freq was enabled]
Power Misconceptions
1st Misconception:
There is a misconception about about 200MHz using the same power as 100MHz because the voltage is the same. There is an approximate formula for CPU power consumption:
CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)
Capacitance is a constant, so we can ignore it. Let's fill in the values for the lowest and highest frequencies:
100 MHz V=0.95 so V^2=0.9025
1000 MHz V=1.25 so V^2=1.5625
So this shows we have roughly an extra 70% power drain due to the voltage increase. However, the maximum frequency is 10 times the minimum, i.e. a 900% increase. So the dominant factor in CPU power drain is in fact the frequency. Roughly speaking, the frequency has 13 times more influence over the power drain than the voltage.
Therefore, the governor that keeps the frequency as low as possible for as long as possible will save the most power. This appears to be consistent with Harbb's finding that conservative saves the most power.
2nd Misconception:
Some people say that if they UV they can play a game on their phone for an extra hour. The most you can get from UV is 2% extra battery life (and it is not worth the reboot risk).
See post #4 for calculations based on the actual measurements taken from the phone.
Here is a more academic proof using the same formula from the 1st misconception:
CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared)
Capacitance is a constant, so we can ignore it. Let's fill in the values for just the highest frequency with the stock voltages and then an extreme undervolt:
1000 MHz V=1.25 so V^2=1.5625 (stock volts)
1000 MHz V=1.2 so V^2=1.44 (the most UV my phone can handle with a fully charged battery)
This is an 8% saving. Happily, this exactly matches what I measured in the real test (see cell F62 in the spreadsheet).
Remember, only the CPU is saving 8%, the screen being on uses about 4 times as much power as the CPU even at its highest frequency. This reduces the power saving to at most 2%.
I am of course assuming the screen is on. For most users, this is correct, as their processor will not be under a heavy load unless the device is in use, and this almost always means the screen is on. If anyone can think of any circumstances where the CPU is under a heavy load, but the screen is off, and show that this happens to all users a high enough proportion of the time to be relevant to this calculation, please let me know. [/far fetched caveat]

Testing Methodology
Two videos are available, and note, a circuit diagram of test now linked within the battery benchmark spreadsheet. I've decided to share it publicly as I've now set up and run this test three separate times, with no major problems. So I've reclassified it from utterly reckless, to merely dangerously stupid. Do not under any circumstances try this with your own phone! You have been warned!
You cannot trust battery monitor widget. (More on that in the 4th post)
Here's a way to test Deep Idle without rewiring your phone:
Note - SOMF means Screen Off Max Frequency
Setup must be identical (apart from SOMF). Install battery monitor widget, set history update rate to 10 minutes (not particularly to monitor the battery, but just to act as a timer). Set to run without widget. Turn off all radios, turn off sync, turn off location services, put in airplane mode. Turn off any of Ezekeel's mods excepting (Deep Idle of course). Set up your music app to play the same song on a loop. Make sure all volumes are down. Phone must be in mute. Turn of auto-brightness just in case. Morfic told me that to avoid the problem of the battery not reporting itself properly you can begin both tests with the same charging procedure: charge while off overnight. In the morning bump charge for exactly one hour. Disconnect, boot, start music immediately. Power button to screen off. Leave phone for 48 hours (should be enough time to auto power off).
After the first test, check the history from battery monitor widget to see how long the phone was on for.
Repeat again but with SOMF set to on.
***
Here's more on metering the amps:
REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
If you're thinking this is something you'd like to try, you'll need:
1) An analogue multimeter or pure ammeter because a digital one will be difficult to read with constantly changing amps.
2) Two battery caddies with space for 3 AA batteries each.
3) Six rechargeable batteries. Use rechargable ones because the volts are a bit less, 3*1.35=4.05 - close enough to the spec 3.7
4) Lots of cables with crocodile clip ends
5) Some fine copper wire
If you're thinking of soldering something onto your battery, DON'T - you may accidentally make a short circuit that will be difficult to undo, and cause the battery to explode. Plus the heat of the soldering iron certainly won't do it any good. And don't solder anything onto your phone contacts, just carefully twist a few strands of copper wire around them, so they can be easily removed. REMEMBER I ADVISE THAT NO ONE SHOULD ATTEMPT THIS.
[Q] Why do I need 6 AA batteries when 3 would provide enough volts?
[A] My multimeter inserts a 600 ohm resistor into the circuit (yours may be less, and if so you will need different calculations to convert to amps). This resistor allows the multimeter to evaluate the amps by measuring the voltage drop across it. But the resistance will cause your phone to starve of power. Running a parallel battery to the phone will prevent it crashing when the voltage supply isn't sufficient for things like screen on+cpu max frequency+sdcard IO... This parallel supply should run directly to the phone, not through the multimeter. It can be disconnected when the screen is off, and will not harm the phone. Remember to reattach it before powering on your screen, or it is likely your phone will crash. I would advise to start with fully recharged batteries, and not connect the USB charger.
[Q] Won't the amps read half of what is actually being drawn?
[A] Yes, but you'll get the correct reading if you unhook the parallel battery.
[Q] Might I also be able to do that when the screen is on?
[A] Yes, but I recommend that you do that with everything possible powered off, wifi, 3G... etc... screen brightness minimum. Set your screen timeout to never, so that you have control over it with the power button. Always reconnect your parallel battery before changing from screen on to screen off, and visa versa. (Due to large power spike)
[Q] I want to try this. Should I?
[A] No, no-one should try this.

Miscellaneous
[Q] You claim you cannot increase battery life using UV beyond 2%. Justify yourself!
[A] When the processor is in use (i.e. not asleep or idle) UV does save a tiny amount of power. I tested with the most extreme UV my phone could handle. With a high performance governor, e.g. smartassv2, extreme UV would reduce CPU drain by 13%, or about 7 mA. With a governor that keeps the CPU frequency low, CPU drain would be reduced by about 18%, or 4.6 mA (weighted - see the spreadsheet starting cell H88).
Remember, these savings are limited to the processor, and only when it is active. For most users, this will mean the screen is on. For comparison, the screen on minimum brightness displaying black uses 9mA. On max brightness, displaying white, it uses 690mA. Let us assume some median value, ~350 mA.
A saving of 4.6 mA out of at least 350 mA (screen) plus 20 mA (CPU)
= 1.2%
A saving of 7 mA out of at least 350 mA (screen) plus 50 mA (CPU)
= 1.8%
So, regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%.
Articles and Documents
Diane Hackborn's article on the formula that produces the dodgy Android OS usage statistic in the battery menu:
https://plus.google.com/105051985738280261832/posts/FV3LVtdVxPT
(note, this bug is fixed as of Android 4.0.4)
Data sheet for the fuel gauge chip:
http://www.maxim-ic.com/datasheet/index.mvp/id/6621
Link to great article on SOC (State of Charge) http://www.mpoweruk.com/soc.htm >>> explains all the reasons why I don't trust battery monitor widget and the phone's own battery stats.
Great article on the difficulties of accurate metering (thanks aLNG):
http://low-powerwireless.com/blog/d...t-schemes-for-battery-powered-devices-part-1/
In the article DUT stands for Device Under Test
The implication is that DMM [Digital Multi Meter] voltage drop readings (to measure amps) take hundreds of milliseconds, a will miss instantaneous battery savings above this time window. However, I am using an analogue meter, the the needle responds to all current. Due to the mass of the needle, there is inertia to overcome, which provides a form of averaging.
Quote from the article:
"a GSM cell phone can have current pulses of 2 amperes that last approximately 500μs while the power amplifier is on and transmitting, and then drop back down to the milliampere level for the remainder of the 4.5 ms GSM cycle."
500μs is 0.5ms, so is 1 tenth of the 5ms GSM cycle. 2 amps at 1/10th of 5ms = average of 200 mA
When I ran the test with my equipment, GSM broadcasting uses at least 170 mA - see row 36. I think this is a nice proof that the analogue multimeter beats the digital multimeter hands down for dynamic amps (i.e. changes happening below the millisecond level.) I'm also very satisfied that my result is close to the result stipulated by the article. It improves faith that my readings are accurate.
[Q] What could add inaccuracy to the readings?
[A] The dBm scale assumes a resistance of 600 ohms, but the resistor has 3% accuracy which means it could be as high as 618 ohms, or as low as 584 ohms.
[A] Also, the scale is very small, so I've read the needle to the nearest fifth of a dB
Other articles (thanks aLNG)
A study of the mA drain of various components of a smartphone
http://www.usenix.org/event/atc10/te...rs/Carroll.pdf
An ARM presentation on unifying power management procedures in the kernel
http://elinux.org/images/0/09/Elce11_pieralisi.pdf

UPDATE: Undervolting the CPU tested (using nstools ARM+INT)
UPDATE: impact of different screen colours tested (amoled)
UPDATE: Running apps tested.
Please note, the running apps draw power for lots of different reasons, access RAM, CPU, I/O, Graphics, all use power, what's being displayed also uses power, eg a brighter 3D scene vs a darker 3D scene. But it does give an overall idea of what Amps might be pulled when you are using the phone normally.

Thanks for your hard works I'm impressed with the systematic research.
Many things just the theoretical possibility? just something we created in our minds...

mobile_pc said:
Thanks for your hard works I'm impressed with the systematic research.
Many things just the theoretical possibility? just something we created in our minds...
Click to expand...
Click to collapse
Indeed, i agree. Now, with no benefit to under volting, perhaps we can all suffer less reboots.
For kernel benchmarks and more, see here: http://goo.gl/mpeHI

I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers

polobunny said:
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers
Click to expand...
Click to collapse
The frequency information is there in the first column, eg 400/400 means the min and max settings were both 400. If you're not changing frequencies you can get it down very low.
Yes, perhaps nstools is defective. However, i did get an instant reboot with the lowest setting. Want me to do a repeat in GB?
For kernel benchmarks and more, see here: http://goo.gl/mpeHI

So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?

italia0101 said:
So undervolting does nothing? That seems strange ...
Also what about using juice defender? Worth it ?
Click to expand...
Click to collapse
Yeah, does nothing to save battery. I don't know what juice defender is?
Sent from my SNES

polobunny said:
I have undervolted and overvolted in GB with direct impact on the battery life. The fact your undervolting tests show absolutely no difference in battery drain make me think the settings aren't even applied.
Also this part of your spreadsheet seems to be a bit lacking. What frequency voltages were changed? 100MHz? 200Mhz? All?
The smallest voltage I've seen stable for 100MHz ARM seems to be 825mv, for example.
Cheers
Click to expand...
Click to collapse
Okay, I went ahead and tested Gingerbread (carbon, ICS themed Oxygen 2.3.1, android 2.3.7) using franco's last kernel for GB. Starts at row 329.
Neither extreme undervolting nor overvolting had any impact on the battery drain.

Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync

italia0101 said:
Juice defender is a battery saving app that basically d/cs the data and wifi when screen is off and reconnects when screen is on... also when screen is off it uses schedules to turn wifi/data on to receive stuff and sync
Click to expand...
Click to collapse
Sounds sensible enough to me!
Sent from my SNES

Some reserves
bedalus said:
2 - If you use NStools to undervolt, don't bother. No gain to be had from undervolting either ARM or INT voltages. I tested this to the extreme. Check the spreadsheet, near the bottom. (Tested in both ICS and GB).
Click to expand...
Click to collapse
First, I want to thank you for all your efforts in the benchmarks especially for the battery drain. However, I kindly have some reserves on this. Maybe undervolting does not save so much power at idle but at higher loads, energy can be surely saved. Besides, maybe the energy saved is too minimal for your analog multimeter and it can't be noticed on it.
This is the theory :
The switching power dissipated by a chip using static CMOS gates is C·V2·f, where C is the capacitance being switched per clock cycle, V is voltage, and f is the switching frequency,[1] so this part of the power consumption decreases quadratically with voltage.
Click to expand...
Click to collapse
source : http://en.wikipedia.org/wiki/Dynamic_voltage_scaling
And this a more practical reference about a study made by tom's hardware on AMD Athlon clock, voltage and power consumption. I think it can be generalized (at a smaller scale) for our ARM processor in the nexus S:
It’s only when we change the voltage that we're able to significantly save more power--about 13 watts lower consumption, or a total of 20 watts compared to running without power management. That's a savings of 25%.
Click to expand...
Click to collapse
source (you may also read the entire article. It is very significant):
http://www.tomshardware.com/reviews/processor-power-management,2453-9.html
Other scientific papers and studies can be also found stating that undervolting saves power.
Kind regards.

I also appreciate all the hard work you have done for testing, on both kernels and everything, but im going to "gingerly" throw my hat in with tchaari here...
The only way to actually test battery drain would be to attach a multimeter and let it drain all the way on every test, using every kernel, and every setting - multiple times to omit false positives. Obviously this is beyond the acceptable timeframe it would actually take to accomplish. anyone would go insane sitting there waiting.
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice, your kernel/gov choice affects how the program runs too...also the status of your battery makes a difference. is it past it's half cycle life? etc..then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
so it's nice to see a massive sheet like you did, as it does give a good start point reference - but it should be used not as chipped into stone law either.
Thanks for taking the time to give a great, no excellent base line to work off of though and preform more intense testing if people would like to go that far.

t3xboar said:
there are nuances here that will affect results regardless how carefull one is. the program itself might suck juice... then the multimeter is another massive factor. there are many many different types not saying yours is bad, but over the years as an electrician ive played with some that are $20 as well as $2000 - and they are a far cry from each other even though they both do the exact same functions!
Click to expand...
Click to collapse
What program? I'm playing a loop of silence in the music app to keep the processor awake.
The multimeter I'm using isn't fancy, but even if it's reading 10% down, it's doing it for all readings, so it's a fair comparison.
t3xboar said:
The undervoltage is a prime example. there are so many factors that will affect the results it's unusual to see your sheet having barely any differences - when we know that undervolting does actually save you battery under loads.
Click to expand...
Click to collapse
What makes you say we know this? I want to get to the bottom of this, so i need to see a concrete source.
Tchaari posted the capacitance times volts squared times frequency formula. I know this, and when I adjust the ARM voltage by more than half a volt, i expect to see this:
0.8x0.8=0.64
1.5x1.5=2.25
That should be 3.5 times as much power use.
Now, double the power in the dB scale is a difference of ~3dB. 3.5 times ~5dB. And I can notice a change of 1/5th of a dB on my multimeter's scale. There was no change. Here is how i tested.
Start music. Go into nstools, set ondemand with min and max at the same frequency. Go to volt, select the lowest possible voltage for that freq and exit. Screen off, measure amps. Screen on, nstools, volts, highest volts this time, exit, screen off, measure amps. Result: identical.
Seriously, if you have a background in electronics, have a go yourself (NO ONE SHOULD TRY THIS THEMSELVES) and get back to me.
In theory, it should save power, but it isn't. I'd love to be able to say why. At this point i don't think it's a problem with nstools, because i got a crash the second i put the volts to minimum when i was testing on Steve's kernel in ICS.
Sent from my SNES

As contradictory as some of these results may (or may not) be, bedalus is in the right with his methodology as far as i can see. Though at this point nothing should be set in stone. Not yet at least.

A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Sent from my SNES

bedalus said:
A few people saying with UV that they get more screen on hours, up from 3 to 6 hours. I'll check amps pulled (with both UV and OV) with screen on next.
Click to expand...
Click to collapse
That is a good idea bedalus but it seems that undervolting gain is very minimal instantly. In a long period, it can make some difference in battery life...
I have also many doubts about how sensitive your amps-meter is? Since we are dealing with small values in our case, maybe a more sensitive device can measure some difference that yours can't...
Anyway, your work is very interesting and as Harbb said : At this point, nothing should be set in stone yet.

[REF][ABB][UV][OC] All you need to know about Adaptive Body Bias

I created this thread to share profiles discuss about ABB introduced by the recognized AndreiLux in his Kernel Perseus. And above all avoid users flooding both AndreiLux's and Temasek's thread with profiles and questions.
Link to Perseus Kernel:
http://forum.xda-developers.com/showthread.php?t=1691401
Or if you are using Temasek:
http://forum.xda-developers.com/showthread.php?t=1797109
A brief description about ABB by the developer itself:
AndreiLux said:
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"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"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
Click to expand...
Click to collapse
AndreiLux said:
No.
We need to clear up the terminologies here: RBB means negative body bias. FBB means positive body bias. (Again, body bias = gate voltage - body voltage)
- The higher the FBB, the more leakage and faster the transistor can potentially switch. You need less gate voltage than a lower FBB.
- The higher the RBB, the less leakage and slower the transistor can switch. You potentially need more gate voltage than a lower RBB.
If you guys find more easy, just ignore the FBB or RBB terms and just talk about + or - xxx body bias.
Click to expand...
Click to collapse
AndreiLux said:
No.
Body bias = gate voltage - body voltage.
Take 1800 gate voltage = 1350mV for exmple.
Your default body voltage is 1300mV (example).
Your body bias is 1350mV - 1300mV = 50mV. You have a FBB of 50mV by default.
If you wish to be able to potentially reduce gate voltage, you need to lower body voltage.
If you lower gate voltage: 1250mV gate - 1300mV body = -50mV body bias. You're now applying a RBB, meaning you have now raised the threshold voltage of the chip. Basically you make it more power efficient but it'll probably crash because you worked against high clocks in both aspects.
If you lower your body voltage: 1350mV gate - 1100mV body = 250mV FBB. You lowered the voltage threshold of the chip, however you also increased the leakage. If you were already stable at that gate voltage, you achieved nothing by doing this other than increasing your power consumption.
If you lower your gate and body voltage: 1250mV gate - 1100mV body = 150mV FBB. You're still doing an FBB, however the bias is now higher than what you've started with. You still lowered the voltage threshold of the chip, but because you also reduced the gate voltage, you took advantage of it.
Click to expand...
Click to collapse
Some important information:
amppen said:
Yes. But I think the problem it creates (higher Vth, threshold voltage) is a smaller one than the benefit (reduced leak). It's been studied (source) that -500mV RBB reduces frequency by 32%, energy per switching event by 4.4%, and leakage power by 90% and 500mV FBB increases frequency by 29%, energy per switching event by 5.6%, and leakage power by 1300% (edit: starting point being 0mV body bias) Mind that this was studied with a simple oscillator circuit who runs a frequency kind of by it's own mind, our CPU tries to run a frequency it's told to run by the clock, so FBB/RBB doesn't change the frequency on our CPUs, rather it can make a frequency impossible to run.
In my experience high RBB doesn't ruin your UV totally, it just makes the crazy low UV impossible. So there's much savings to be achieved with high RBB, possibly greater than the ones lost from not being able to UV crazy low. I get that there is a gut instinct to "get the voltages low" and it feels counter intuitive to change some voltages (body, that is) higher to save juice. But then again, body voltage is not a "working voltage" here, it's a static (even though frequency scaled with adaptive body bias) voltage used just to manipulate the field effect inside the transistor. Voltage itself doesn't tell how much power you use, power is measured in watts.
Click to expand...
Click to collapse
In this post @MiracleM4n posted a link with compilation of user's data regarding voltages and ABB values. Please contribute with him so in that way we can have a fine database for reference.
MiracleM4n said:
I was told I should post here. I have a compilation side of people's CPU / ABB values and was just wondering if anyone wanted to add their values to it (or modify the ones I have added already). I was also wondering if anyone wanted to provide some html/php/js/css code to make it run / look better. "link" is in my signature.
EDIT: The only thing I haven't gotten working yet is that the navbar on the left is not highlighting the correct person (changing class="active") when you click on them. Other than that it is only visual and code improvement.... As well as more data xD.
EDIT2: Was also wondering if anyone wanted me to open a new thread based on it or just leave it where it is.
Click to expand...
Click to collapse
Here it is Project Plumber by amppen which have very interesting data and experimentation about ABB.
I find this this post very interesting, please read if you have any doubt about ABB:
Erahgon said:
There is a measurable difference in energy consumption.
I've had issues with heat, esp while using HSDPA networks and sometimes while playing games.
Eventually, the CPU and GPU throttle themselves, which results in worse performance. After lowering the voltages, I've had few issues if any. Oh, and certainly better battery life as a result.
Every user's experience is different. A sample set of one isn't enough to confirm nor deny the affect of ABB.
Even for kernels without ABB tunables, ABB is calculated and set, based on device ASV. This is calculated based on the balance of stability and voltage thresholds, to satisfy operating conditions (also can be termed as the factor of safety). It is the factor of safety we're adjusting when we change the ABB.
As ominous as this sounds, by factor of safety, I don't mean that the device will be put in harm's way. It actually means, it has to qualify to certain operating conditions, for example: from temperatures of -20°C to 70°C or whatever. Now, after tweaking, it may only work from -5°C to 50°C instead (all numbers shown are examples, actual values will differ). Beyond these thresholds, the device will not function consistently.
Since these values are meant to cater to a vast sample of users, each user may adjust it to his/her needs, to achieve greater performance/battery life.
This is science.
On a personal note, I believe there are ideal values of ABB, for people who have the time and patients to tune it. However, it is too tough for most.
I have just lower the CPU voltages for my device, and have adjusted the ABB accordingly to increase stability at those voltages.
It's running cool and smooth most of the time, but much better than stock.
Sent from my GT-I9300
Click to expand...
Click to collapse
And Finally a proper guide to undervolt your phone:
http://forum.xda-developers.com/showthread.php?t=2072087
All the credits go to @AndreiLux for all his research and development.

I'll share the results of my latest experiment tonight. So far so good... Next thing I'll be testing is not to UV at all and getting crazy with the body voltage (maximum RBB) to see if eliminating static leak will be even more beneficial to battery life than the UV itself.
Meanwhile, here's some reading for the scientific minded
Texted with my Nokia 5110

amppen said:
I'll share the results of my latest experiment tonight. So far so good... Next thing I'll be testing is not to UV at all and getting crazy with the body voltage (maximum RBB) to see if eliminating static leak will be even more beneficial to battery life than the UV itself.
Meanwhile, here's some reading for the scientific minded
Texted with my Nokia 5110
Click to expand...
Click to collapse
I've finally managed to reach a stable *crosses fingers* configuration which mostly follows the default table's ABB values except for three steps. With an undervolt and and ABB value roughly the same as the default, theoretically I should be able to save some juice.
Edit: I wish I were more scientifically inclined. That paper made absolutely no sense to me

Thank you for this, will definitely post results here for my AVS2
So, these are my values, taken from someone in Perseus or Temasek's thread. I would credit if I knew who they were!
Sent from my Galaxy S3. Long live the original Galaxy S

amppen said:
I'll share the results of my latest experiment tonight. So far so good... Next thing I'll be testing is not to UV at all and getting crazy with the body voltage (maximum RBB) to see if eliminating static leak will be even more beneficial to battery life than the UV itself.
Meanwhile, here's some reading for the scientific minded
Texted with my Nokia 5110
Click to expand...
Click to collapse
Very good read indeed
Sent from my portable powerhouse

habylab said:
Thank you for this, will definitely post results here for my AVS2
Sent from my Galaxy S3. Long live the original Galaxy S
Click to expand...
Click to collapse
Yea habylab.. I'm eagerly waiting to check your settings out...
Sent from my GT-I9300 using xda premium

amppen said:
I'll share the results of my latest experiment tonight. So far so good... Next thing I'll be testing is not to UV at all and getting crazy with the body voltage (maximum RBB) to see if eliminating static leak will be even more beneficial to battery life than the UV itself.
Meanwhile, here's some reading for the scientific minded
Texted with my Nokia 5110
Click to expand...
Click to collapse
any updates on this so far?

davtse said:
any updates on this so far?
Click to expand...
Click to collapse
Not yet, I'll see my newest settings through (time&usage until 50%) before testing the "no UV - max RBB" -idea.

SO to sum up.
A RBB is more battery efficient, correct?
...But you should try lowering your gate voltage to minimum first, and then try lowering ABB?

habylab said:
SO to sum up.
A RBB is more battery efficient, correct?
...But you should try lowering your gate voltage to minimum first, and then try lowering ABB?
Click to expand...
Click to collapse
I'm just gonna quote myself (because I'm a douche):
amppen said:
Sure, if we're talking about RBB a.k.a. negative body bias. More RBB, less leak. But then again too much RBB will cause stability issues and prevent undervolting, which saves battery too.
In my opinion it's all about finding a balance between RBB and UV. If you try to save battery/prevent heat with UV, you'll get even some more benefit with RBB. Or if you'll FBB a little you could be able to UV some more with the higher frequencies.
Then again the benefit from the UV could be lost because of the increased leakage introduced by FBB/too little RBB. That is why this is all about testing and tweaking - to find the golden middle.
Click to expand...
Click to collapse
In other news: my latest test was compromised because I accidentally used stock voltages :laugh:
I was very surprised to see that my drain was increased with my latest and greatest setup, it nearly drove me crazy when I tried to think why. Then I saw that I had unticked the set on boot and had rebooted so everything went to default.
But now I'm going to experiment with stock voltages on purpose and go crazy with the body voltage. I'll report tomorrow what happend and that do I still have a working phone

Ideally you would try to lower the gate voltages while keeping RBB/FBB bias at the corresponding frequencies. This also depends on the frequency you're working on: higher frequencies might need FBB to be stable without crazy voltages while lower frequencies will happily take lower RBB values.
Lowering gate voltages while keeping or lowering FBB/RBB bias will net you improved battery life.
At least that's the theory.

amppen said:
I'm just gonna quote myself (because I'm a douche):
In other news: my latest test was compromised because I accidentally used stock voltages :laugh:
I was very surprised to see that my drain was increased with my latest and greatest setup, it nearly drove me crazy when I tried to think why. Then I saw that I had unticked the set on boot and had rebooted so everything went to default.
But now I'm going to experiment with stock voltages on purpose and go crazy with the body voltage. I'll report tomorrow what happend and that do I still have a working phone
Click to expand...
Click to collapse
On the brighter side, I'd say at least now we know that ABB does result in battery savings when done correctly. :good:

davtse said:
On the brighter side, I'd say at least now we know that ABB does result in battery savings when done correctly. :good:
Click to expand...
Click to collapse
Thanks, I feel better all ready I'll just think about my little botch as proof of concept and carry on.
...my stock voltage/max RBB setting just passed stress test on all frequencies, I'll do an overnight drain test next. We'll see how this minimum leak compares with UV.

my settings for ASV4, seems stable
slices: 1000, 1050, 1100, 1200

Tixaro said:
my settings for ASV4, seems stable
slices: 1000, 1050, 1100, 1200
Click to expand...
Click to collapse
trying now thanks!

Hehe nice thread! Hope to see many setups here (mine will come soon).
Was away for few days, and switched to a StockLike ROM for this time - but my ASV2 is reallay stable with -125mV U/V all frequencies, and ABB set to 850, 950, 1100 for the 3 first slices. Will drop my full details soon (with my current Ultima/Perseus combo and my Temasek update).

Tixaro said:
my settings for ASV4, seems stable
slices: 1000, 1050, 1100, 1200
Click to expand...
Click to collapse
Thanks! Is it possible that you share your profile ?
Gesendet von meinem GT-I9300 mit Tapatalk 2

plakers said:
Hehe nice thread! Hope to see many setups here (mine will come soon).
Was away for few days, and switched to a StockLike ROM for this time - but my ASV2 is reallay stable with -125mV U/V all frequencies, and ABB set to 850, 950, 1100 for the 3 first slices. Will drop my full details soon (with my current Ultima/Perseus combo and my Temasek update).
Click to expand...
Click to collapse
That was the idea. To create a thread specifically to share profiles and learn about ABB and not flood the kernel's thread.
I suggest to all the people who are playing with abb. That first find the lowest UV posiible with the stock ABB values. And then start tweaking ABB values.
Now i am doing some testing and so far the UV values that worked on 900 ABB are working on 950 ABB. Meaning that before was having extra leakage for no reason.
Also i found that higher frequencies[1600..900] are easier to UV that lower freq[800...200] perhaps because lower freq already have negative bias while higher freq have higher positive bias having more room to UV.
This thing require a lot of time, testing and fine tuning. For that reason i suggest to not apply others people profiles on their phones but using them as a base.

Any try with Asv7? ^^

cba1986 said:
That was the idea. To create a thread specifically to share profiles and learn about ABB and not flood the kernel's thread.
I suggest to all the people who are playing with abb. That first find the lowest UV posiible with the stock ABB values. And then start tweaking ABB values.
Now i am doing some testing and so far the UV values that worked on 900 ABB are working on 950 ABB. Meaning that before was having extra leakage for no reason.
Also i found that higher frequencies[1600..900] are easier to UV that lower freq[800...200] perhaps because lower freq already have negative bias while higher freq have higher positive bias having more room to UV.
This thing require a lot of time, testing and fine tuning. For that reason i suggest to not apply others people profiles on their phones but using them as a base.
Click to expand...
Click to collapse
I'm still confused haha. Anyway lowering ABB does it also means I have more ability to lower my gate voltage too? With lower gate voltage and lower/same leakage(ABB more negative/same) = better battery life?

Interactive governor tweaks

Hi everyone,
I've been reading this
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
and was wondering if anybody was interested and knew their way around to try and adapt these tweaks for our trusty htc ones?
Some n5x users (specifically those who tend to not game heavily or use the camera extensively) seem to reek performance boosts while also considerably extending SOT. The OP's tweaks got the attention (and as far as I know the support) of flar2 (elementalx kernel) considering he implemented the ability to apply profiles into his ex kernel manager specifically so the interactive governor settings could be applied more easily (unless I misunderstood something - correct me if I'm wrong on that). These tweaks can be made regardless of kernel or rom - the only prerequisite is the availability of the interactive governor. It may be something worth looking into and I'm willing to learn and test - I just kinda need someone to take me by the hand and help and explain because I feel a bit lost in regards to how to best proceed :silly:
What do you guys think?

over the next few days,im gonna be working on testing out some settings (of course following that guide)
if i get anywhere with them,i shall share them

That's great to hear, thank you :good: If I can be of any help please let me know!

These are my minimal settings for now based on my usage analysis . Will probably adjust them with battery performance this week.
Idle - 384000
Page Scrolling - 702000
Video - 918000
App Loading - 1134000
High Load Processing - 1728000 ( or 1566000 )

Sinistersky said:
These are my minimal settings for now based on my usage analysis . Will probably adjust them with battery performance this week.
Idle - 384000
Page Scrolling - 702000
Video - 918000
App Loading - 1134000
High Load Processing - 1728000 ( or 1566000 )
Click to expand...
Click to collapse
If this is a stupid question I apologise but how do you apply these in ex kernel manager (or equivalent app you use)?

antimatter.web said:
If this is a stupid question I apologise but how do you apply these in ex kernel manager (or equivalent app you use)?
Click to expand...
Click to collapse
This is my setup right now. Can someone who is working on this check if I did it correctly, I have some stuttering here and there so I think i'm missing something, since it should be buttery smooth and battery friendly.

Sinistersky said:
This is my setup right now. Can someone who is working on this check if I did it correctly, I have some stuttering here and there so I think i'm missing something, since it should be buttery smooth and battery friendly.
Click to expand...
Click to collapse
Thanks :good:
Again, I'm not sure about this, but I believe you shouldn't be needing to spend that much time at max. frequency. No idea how to get it down, but I feel like I did read something in the original thread. To me (as a fairly noob, layman forum user) that 32% seems high.
Have you seen any battery savings with your current setup?


antimatter.web said:
Thanks :good:
Again, I'm not sure about this, but I believe you shouldn't be needing to spend that much time at max. frequency. No idea how to get it down, but I feel like I did read something in the original thread. To me (as a fairly noob, layman forum user) that 32% seems high.
Have you seen any battery savings with your current setup?
Click to expand...
Click to collapse
Yea, I kinnda have. But Im still tweaking it. I just dont know how to bring down the frequency It's like I setup something wrong. I do have more battery life, but I think I can do even better. Just need the right values

Sinistersky said:
Yea, I kinnda have. But Im still tweaking it. I just dont know how to bring down the frequency It's like I setup something wrong. I do have more battery life, but I think I can do even better. Just need the right values
Click to expand...
Click to collapse
One follow up to my post on the N5X thread: (http://forum.xda-developers.com/showpost.php?p=66100620&postcount=2990)
set
highspeed freq to 810000 or 702000
go highspeed load to a value between 95 and 98
the first value on taget loads to 95 384... (90 or anything lower should be ok, too, doesn't matter much as this already is the lowest freq)
the target_load value for your highspeed freq (the value after the ":" ) to a value between 81 and 90
---Edit:
Oh, and: lower target_loads => earlier to the next freq => less laggy. You can tweak that behavior with the delays and timer rate, too
But: Many frequency changes / jumps => more lag

.hEiMDaLL. said:
One follow up to my post on the N5X thread: (http://forum.xda-developers.com/showpost.php?p=66100620&postcount=2990)
set
highspeed freq to 810000 or 702000
go highspeed load to a value between 95 and 98
the first value on taget loads to 95 384... (90 or anything lower should be ok, too, doesn't matter much as this already is the lowest freq)
the target_load value for your highspeed freq (the value after the ":" ) to a value between 81 and 90
---Edit:
Oh, and: lower target_loads => earlier to the next freq => less laggy. You can tweak that behavior with the delays and timer rate, too
But: Many frequency changes / jumps => more lag
Click to expand...
Click to collapse
Ok. So what happens if I don't set every frequency? I think I saw a EVO 4G thread with this and OP had only 3 freq set in the target_load ? Is that more efficient? So to make this have proper results, I need to change the numbers after ":" until i get the perfect results?
--Edit:
Ok. These are waaay better results than I ever had. Now the other frequencies are actually being used

Sinistersky said:
Ok. So what happens if I don't set every frequency? I think I saw a EVO 4G thread with this and OP had only 3 freq set in the target_load ? Is that more efficient? So to make this have proper results, I need to change the numbers after ":" until i get the perfect results?
Click to expand...
Click to collapse
It uses the target_loads you set for the lower freq. efficiency depends on the numbers it's less text to write if the loads are all the same for each freq...
The numbers behind the ":" (the target_loads) are only one part. the other settings like timer_rate and above_highspeed_delay have a huge impact on how fast the cpu reacts under load, too. sonicron described them very well in his guides.
---EDIT:
Seems you are on the right way with these values. Max freq still is used a bit to much, but I'm sure you'll find the best values after some tries. Took me hours, sometimes days to set up my profiles...

.hEiMDaLL. said:
It uses the target_loads you set for the lower freq. efficiency depends on the numbers it's less text to write if the loads are all the same for each freq...
The numbers behind the ":" (the target_loads) are only one part. the other settings like timer_rate and above_highspeed_delay have a huge impact on how fast the cpu reacts under load, too. sonicron described them very well in his guides.
---EDIT:
Seems you are on the right way with these values. Max freq still is used a bit to much, but I'm sure you'll find the best values after some tries. Took me hours, sometimes days to set up my profiles...
Click to expand...
Click to collapse
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them

Sinistersky said:
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them
Click to expand...
Click to collapse
I've read sonicrons first post a few times myself (as I'm very interested in the idea) but my technical knowhow stops at basic adb and recovery knowledge for flashing roms... May I bother you for the current values you are using? Sorry if I seem like I'm not trying - I am

antimatter.web said:
I've read sonicrons first post a few times myself (as I'm very interested in the idea) but my technical knowhow stops at basic adb and recovery knowledge for flashing roms... May I bother you for the current values you are using? Sorry if I seem like I'm not trying - I am
Click to expand...
Click to collapse
Yes, of course. You can have it, it's no bother. I'll attach my settings. However, these are not final. The phone jitters here and there, and I think the battery life is better by only a slight percent. I am hoping during hte next few days to find values that wil give more SoT and smooth performance. I will also need help with that

Sinistersky said:
Yes, of course. You can have it, it's no bother. I'll attach my settings. However, these are not final. The phone jitters here and there, and I think the battery life is better by only a slight percent. I am hoping during hte next few days to find values that wil give more SoT and smooth performance. I will also need help with that
Click to expand...
Click to collapse
Thanks for those I will apply those and see how they work for me. I'm currently using CM12.1 (Snapshot) and greenify for a few apps. What setup are you using?
If I can be of any help (I'm not going to pretend I will be of much) please let me know
Edit: I may have spotted an error: in the first line of target loads your second frequency should be 486000:60 not 48600:60, right? Could that be the reason for your jitters maybe?

antimatter.web said:
Thanks for those I will apply those and see how they work for me. I'm currently using CM12.1 (Snapshot) and greenify for a few apps. What setup are you using?
If I can be of any help (I'm not going to pretend I will be of much) please let me know
Edit: I may have spotted an error: in the first line of target loads your second frequency should be 486000:60 not 48600:60, right? Could that be the reason for your jitters maybe?
Click to expand...
Click to collapse
Yes, that is correct. I spotted it myself this morning. And the battery life has gotten insane. 8% in 1 hour of texting and screen on :highfive: So generally, this would mean about 8 hours of screen on time for sure.
--EDIT: Im using AICP with stock kernel and greenify and amplify

Sinistersky said:
Yes, I keep re-reading sonicron's first post due to not understanding it so well even though he explained it with so much detail, but the way I see it, if I'm correct, increasing timer_rate makes the cpu use the lower frequencies more, or the jumps between frequencies are faster? I set the timer_rate to 40000 now, just to see if it will prolong my battery. And why is the timer_slack in N5X set to -1? What's the purpose of that? If i understand correctly, it makes the switch between frequencies incredibly fast, almost instant??
Thank you for guiding me so far with this. I understand these might seem as annoying questions, but I'm trying to learn as much as I can through them
Click to expand...
Click to collapse
In short, the timer_rate is just the intervall after which the governor reevaluates the loads. So it doesn't affect which frequencies are used more, but how long it "waits" to check whether it should go up to the next freq. However, this is indirectly linked to the fact, that the device will stay at a lower freq for longer.
After the decision is made to change the freq, the next thing that keeps the cpu ramp up to the next freq instantly is the delay timer (above_highspeed_delay)
timer_slack defines the max additional time that can be added to timer_freq, thus the time to defer handling the governor sampling timer.
From kernel docs: [...] at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed.
For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed.
A value of -1 means defer timers indefinitely at all speeds. Default is 80000 uS.
here's the link to the document. Might come in handy https://android.googlesource.com/kernel/common/+/android-3.4/Documentation/cpu-freq/governors.txt
Questions are there to be asked and do not only help the one who asked the question, but the one who get's asked as well So asking and answering, both can be about learning something new, for both parties.

.hEiMDaLL. said:
In short, the timer_rate is just the intervall after which the governor reevaluates the loads. So it doesn't affect which frequencies are used more, but how long it "waits" to check whether it should go up to the next freq. However, this is indirectly linked to the fact, that the device will stay at a lower freq for longer.
After the decision is made to change the freq, the next thing that keeps the cpu ramp up to the next freq instantly is the delay timer (above_highspeed_delay)
timer_slack defines the max additional time that can be added to timer_freq, thus the time to defer handling the governor sampling timer.
From kernel docs: [...] at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed.
For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed.
A value of -1 means defer timers indefinitely at all speeds. Default is 80000 uS.
here's the link to the document. Might come in handy https://android.googlesource.com/kernel/common/+/android-3.4/Documentation/cpu-freq/governors.txt
Questions are there to be asked and do not only help the one who asked the question, but the one who get's asked as well So asking and answering, both can be about learning something new, for both parties.
Click to expand...
Click to collapse
Is there an app that I could use to determine instantly what load the CPU uses when I open chrome, or messenger or just scroll around?
I want to make it so I get a higher frequency on the app opening load, and a lower one on the idle and scrolling load. But if i for instance, set target_load 1566000:85, it uses the 1242000:89 for app opening I think, since it's kinnda laggier?
I can't get rid of these little jitters when switching screens, or apps I'm trying to learn what happens if I put higher numbers after ":" on certain mHz, does that make it so it stays longer on that mHz value or does it wait longer before it goes higher/lower to/from that mHz? And if so, would it be logical and less laggy to put something like 1242000:50 1350000:83 1458000:80 1566000:87 ( I'm guessing these frequencies are used the most when opening an app?)

Sinistersky said:
Is there an app that I could use to determine instantly what load the CPU uses when I open chrome, or messenger or just scroll around?
I want to make it so I get a higher frequency on the app opening load, and a lower one on the idle and scrolling load. But if i for instance, set target_load 1566000:85, it uses the 1242000:89 for app opening I think, since it's kinnda laggier?
I can't get rid of these little jitters when switching screens, or apps I'm trying to learn what happens if I put higher numbers after ":" on certain mHz, does that make it so it stays longer on that mHz value or does it wait longer before it goes higher/lower to/from that mHz? And if so, would it be logical and less laggy to put something like 1242000:50 1350000:83 1458000:80 1566000:87 ( I'm guessing these frequencies are used the most when opening an app?)
Click to expand...
Click to collapse
I use the overlays from DevCheck by flar2 and the process/cpu usage overlay one can enable in the developer options in settings. I guess there are plenty of tools/apps out there that do the same (I remember an app called "cool tool" which I had on my M7).
The jitters might get better when you change the delays (and/or timer rate to a lower value). setting the target_loads lower also helps, but you have to remember that the frequency might not be used at all (which is not a bad thing in general). When you set the load to eg. 40, the cpu will will go up to the next frequency as soon as the load under actual circumstances reaches 40%. As an example (with fantasy numbers): With a setting like 1000000:80 1100000:30 1200000:80, the 1100MHz might never be used at all when ramping up, cause the 80% at 1000MHz are already higher than 30% at 1100MHz. Of course, if the gap between those two frequencies would be higher (lets say 1000MHz and 2100MHz) the cpu might not be ulilized over 30% when coming from 80% at 1000MHz). Thats why you have to calculate the efficient loads, to find out what the most (power) efficient frequencies are, and give those a bit more "priority". You can do this by setting the target load higher on those (lower on the others)
I can't tell you what numbers (target_loads) you have to put in, I'd need the actual device to test how it performs under different loads with stock and tweaked settings.

.hEiMDaLL. said:
I use the overlays from DevCheck by flar2 and the process/cpu usage overlay one can enable in the developer options in settings. I guess there are plenty of tools/apps out there that do the same (I remember an app called "cool tool" which I had on my M7).
The jitters might get better when you change the delays (and/or timer rate to a lower value). setting the target_loads lower also helps, but you have to remember that the frequency might not be used at all (which is not a bad thing in general). When you set the load to eg. 40, the cpu will will go up to the next frequency as soon as the load under actual circumstances reaches 40%. As an example (with fantasy numbers): With a setting like 1000000:80 1100000:30 1200000:80, the 1100MHz might never be used at all when ramping up, cause the 80% at 1000MHz are already higher than 30% at 1100MHz. Of course, if the gap between those two frequencies would be higher (lets say 1000MHz and 2100MHz) the cpu might not be ulilized over 30% when coming from 80% at 1000MHz). Thats why you have to calculate the efficient loads, to find out what the most (power) efficient frequencies are, and give those a bit more "priority". You can do this by setting the target load higher on those (lower on the others)
I can't tell you what numbers (target_loads) you have to put in, I'd need the actual device to test how it performs under different loads with stock and tweaked settings.
Click to expand...
Click to collapse
Oh, so, if I understand this correctly, the number after ":" is like a roof. And when the CPU load hits that roof, it goes to a higher frequency, for example if i have 810000:81, as soon as the load goes to 81 it will switch to 918000, which is the next frequency ? And If i put 918000:90, it will stay on 918 mHz until the CPU load reaches 90? and then go to the next one? And the timer is just used to determine how long it takes to jump between the frequencies? So, what happens if I put 0 on the timers? Do they do it instantly? Does it take more battery life that way?

Database Users

welcome