Related
Hello everyone.
I used to be very disappointed on the battery performance of our stock roms. Our customs roms solved many problems but this battery problem stayed for some people like me.! So i started experimenting on various categories and now i finally have a sufficient battery backup of around 40 hours that keeps me and my android going!!
So here is how to save your damn precious battery!!
It has worked for some people i know and i hope it do work for you too!!
I am using fugumod ultra kernal and it gives me absolutely no lags at all + a super duper battery!!
-Battery Calibration [ROOT]
Whenever you flash any new custom rom, you should always calibrate your battery! Here is an app that does that!!
<Appbrain Link>
{
"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"
}
-Flash Fugumod ultra kernel (Strictly for Fugumod Ultra) )<link>
Flash this kernel and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance
CONFUSED Yes this thing sounds crazy!! But you can always try. I have written this after experiencing it myself!!
-For G3Mod Kernels & Other Versions Of fugumod [OverClocked]
Follow these steps:
Install Setcpu/ Any other cpu controll app
Set Max value to the highest frequency. Minimum between 300-400.
Now using the profiles option set POWERSAVE governor to those times when you wont be using your phone much (ex:while sleeping).
Then for other times use ONDEMAND governor.
While charging profile is set then make sure that governor is set as PERFORMANCE.
You may also try other governors. Haven't tried... (suggestions welcome)
-Install Auto Memory Manager app[ROOT]
Auto memory app automatically kills apps that runs in background based on the profile u set!! After installing the app, use the aggressive profile and the lower the Hidden Application slider to in between 30-40 mb, so that your important background apps are not killed unless the ram is very low..!!
<Appbrain Link>
----------------Alternative For Auto Memory Manager-------------------------
- Supercharger script
Supercharger script is also a great alternative.. You need to run the script from your rooted rom using terminal emulator. See this <link>
This script is included in most of the recent custom roms. See their respective version changelog for info.
Now your phone will be lag free..!! It has been tested and working!! My android phone runs the way it should!!
Lets jump to battery problems
-Battery Calibration has to be done.!!
-After that I recommend you to use your resources a bit cleverly!! Data connection takes a lot of battery for me.! Now fine you need internet when you are on the move. But you don't need it while sleeping do you??
android apps requiring data connection to retrieve data keep on retrieving it even while you sleep but you only see that data after waking up and getting out of our bed. So you should shut off internet while sleeping!!
-Now display.
display consumes battery!! best is to keep display to 10 when its dark!! And around 40 during the day!
I keep it to zero all the time and use keep toggling it to max only when i need it using dimmer!!
<appbrain link>
-3d Gallery. (thanks rai_tushar)
Consumes a lot of battery!! Use quickpic. Better and faster alternative
<appbrain link>
More tips by rudolf895
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
So i think that should be it.!!
One last trick.
If you use tasker or any other automation app try this.
(With respect to tasker)
Make a new context>state>plugged in
Then make a new task for the context>app>load app>Fast reboot <link>
So whenever you will plug in your phone the app be will run automatically and then your phone will be free from any lags.
Data Connection uses lots of battery and will result in battery drain. Most of the time many data is retrieved when you wont be viewing it/using it. But it will result in wastage of data. So u need to make sure you use your data connection wisely
i would highly recommend you all to use tasker app for automation of your android phone. Automatically toggle display, mobile data etc depending upon various contexts (application, time, location). Read THIS thread for more information on tasker.
Conclusion
If you want a rock solid battery and an android phone that should be proud of its speed, and you are not getting any solution, go ahead and try the above..!!
Battery setting may or may not suit you!! This was just a sharing of my experiences which i had en-route to getting a lag-free/rock-battery.
Happy Androiding!!
Thank you for it, but your "this" does not link to any thread. However, I'm assuming you mean for it to be the link that the "here" for the 'ultimate android app' links to. Might want to change that. Thanks for the tips, though.
Mohit12 said:
Thank you for it, but your "this" does not link to any thread. However, I'm assuming you mean for it to be the link that the "here" for the 'ultimate android app' links to. Might want to change that. Thanks for the tips, though.
Click to expand...
Click to collapse
Thanks a lot for that!! Fixed the link!!
Yes its the ultimate app!!
Idk why keep higher minimum CPU frequency your battery should have drained faster even when your phone would be idle..
For me this worked :
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
Hope this helps some one. ;-)
Tapatalked from my super smooth, ultra fast samsung galaxy s2.
neo1691 said:
-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance
Click to expand...
Click to collapse
this doesn't make sense, if you set governor to performance your phone will be running at 1366 mhz at all times regardless of minimum frequency and that will murder your battery. Make a profile for screen off and set it to 83 or166min and 222 or 333 max and ondemand governor, that will save you some battery. When you use the phone set the max frequency to 667 or 800 with conservative or ondemand. Use high freq only when needed - for playing heavy games
rudolf895 said:
Idk why keep higher minimum CPU frequency your battery should have drained faster even when your phone would be idle..
For me this worked :
*Not using set CPU for short time profiles.(not using different frequency while phone is on standby)
*Exiting apps using the back key, home key put the apps to background task.
*using 2g when needed..
*use wifi for bigger than 10mb download as it woudl be fast n easy.
*least brightness
Hope this helps some one. ;-)
Tapatalked from my super smooth, ultra fast samsung galaxy s2.
Click to expand...
Click to collapse
this doesn't make sense, if you set governor to performance your phone will be running at 1366 mhz at all times regardless of minimum frequency and that will murder your battery. Make a profile for screen off and set it to 83 or166min and 222 or 333 max and ondemand governor, that will save you some battery. When you use the phone set the max frequency to 667 or 800 with conservative or ondemand. Use high freq only when needed - for playing heavy games
Click to expand...
Click to collapse
I was excepting this post from someone.. Yes you might say why keep governor to performance with 1366 max.. well thats how we tackle lag!!!
@rudolf!
Surprisingly battery drain is very less for me (and some others too) with these tweaks.. otherwise why would i share them!!
1 more solution:-gallery 3d uses more battery
u can use quickpic as a replacement
rai_tushar said:
1 more solution:-gallery 3d uses more battery
u can use quickpic as a replacement
Click to expand...
Click to collapse
exactly.. Thank you. will update the op as soon as I find a laptop., I always use quick pic but never really considered it a battery saver..
Disabling SNS is also a good way to save battery.
Not applying the RAM optimization script provided in the Dev section will also save battery 'cus I have faced increased battery drain with it.
And does reducing the voltage save battery? If so.. can you please provide some info about it..??
Enviado desde mi Galaxy 3
thanks for the info as i was just about to install the ram optimization tool but considering that it sucks more battery, i wont do it
danveer said:
thanks for the info as i was just about to install the ram optimization tool but considering that it sucks more battery, i wont do it
Click to expand...
Click to collapse
Try the above . Of that still don't help you, then you are can try ram optimization
"-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance"
with this, the battery will last a full day maximum (with normal-low usage)!
kyrillos13 said:
"-Flash Fugumod ultra kernal (this worked for me, havent tried G3mod kernals)<link>
Flash this kernal and use set minimum frequency for 780 hz and Maximum frequency to 1366 hz.
Set the governor to Performance"
with this, the battery will last a full day maximum (with normal-low usage)!
Click to expand...
Click to collapse
agreed.. theoretically it should last not more than one day!! but seriously i have tried that and my phone practically lasts for more than 35 hours..
And that's y i am sharing the info!!
EDIT: setcpu v 2.1.3
ron_gangte said:
Disabling SNS is also a good way to save battery.
Not applying the RAM optimization script provided in the Dev section will also save battery 'cus I have faced increased battery drain with it.
And does reducing the voltage save battery? If so.. can you please provide some info about it..??
Enviado desde mi Galaxy 3
Click to expand...
Click to collapse
Reducing the voltage to the CPU may cause problems and will not save any battery. You can think of it like a simple circuit, with the CPU effective being a "resistor". so you have just a battery, voltage regulator, and CPU, as you reduce voltage, amperage will increase (and battery drain will actually increase!!!) Amperage is what drains your battery, not voltage.
My recommendations (I have tertiary electrical engineer qualifications to back me up)
- Stick with the stock voltages for the different frequencies you use.
- To save battery, turn off wifi & bluetooth when you are not using them.
- Install APNDroid, to easily switch 3G/EDGE data off when not needed (still allows you to receive MMS messages when data is off, and has a widget)
- Set your screen to the minimum brightness that you can (but so that the display is still bright enough to use)
- Turn of "Power Saving" in display settings (actually uses more power than it saves 9 times out of 10)
- Use task manager, or a ram management tool to kill apps that don't need to be running in the background, and always use the back button to go out of apps, the home button will leave the app running in the background (sucking battery and slowing the phone down)
- If using a CPU management tool set minimum to 83MHz (or lowest your phone is happy with, or that you are happy with to kill lag), set maximum to whatever you like (that phone can handle) and use a governor like "on demand". Set up profiles to lower maximum frequency when screen is off, or temp is high (higher temperatures will result in faster discharge off battery)
I do all of this, and I can get up to 3 days use without charging (depending on usage)
Things that will drain your battery the most (highest power usage):
- Wifi
- Bluetooth
- 3G/EDGE
- Screen
- Phone calls
nrk_2k said:
Reducing the voltage to the CPU may cause problems and will not save any battery. You can think of it like a simple circuit, with the CPU effective being a "resistor". so you have just a battery, voltage regulator, and CPU, as you reduce voltage, amperage will increase (and battery drain will actually increase!!!) Amperage is what drains your battery, not voltage.
Click to expand...
Click to collapse
sry, but this is completely wrong.
if it was true what you said increasing the voltage would save power...
decreasing the voltage DOES save power, but unless the CPU isn't running at maximum load the whole time you won't see a big difference.
the frequency of the CPU raises the consumed wattage linearly while voltage goes into the calculation by square. so decreasing the voltage is the best option to lower the consumed power of the CPU as the speed isn't affected. problem is of course that the CPU won't run below a certain limit. the CPU in my G3 is running 800MHz @ 1.125V which is 75mV below stock (667MHz).
the amperage does not change while undervolting.
sharukins said:
sry, but this is completely wrong.
if it was true what you said increasing the voltage would save power...
decreasing the voltage DOES save power, but unless the CPU isn't running at maximum load the whole time you won't see a big difference.
the frequency of the CPU raises the consumed wattage linearly while voltage goes into the calculation by square. so decreasing the voltage is the best option to lower the consumed power of the CPU as the speed isn't affected. problem is of course that the CPU won't run below a certain limit. the CPU in my G3 is running 800MHz @ 1.125V which is 75mV below stock (667MHz).
the amperage does not change while undervolting.
Click to expand...
Click to collapse
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
nrk_2k said:
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
Click to expand...
Click to collapse
well i am having just perfect battery without undervoltage..!! :
but ya definitely learned many new things from the above discussions
nrk_2k said:
First off, I never said anything about saving power, as power is the resulting work of voltage vs. amps, I was talking about battery drain, not power (they are totally different things). The voltage of a battery will not change greatly until it is nearly empty (if it did, it would be pointless rating a battery to a certain voltage), where as the amperage will lower as the battery gets drained. The amount of time a battery lasts is determined by its amperage, not voltage (hence why a 2100mAh battery will last longer, doing the same amount of work as an 1800mAh battery). So if what you claim (amperage not changing while undervolting) were true, then you would see NO change in battery drain due to undervolting. Voltage NEVER drains a battery, it's the amount of amps being drawn that drain the battery. P=IV is the power equation for a closed DC circuit. If we assume P is a constant (which it has to be, to be getting the same output from a CPU) then when you lower V, I must therefore increase. and Likewise, if you raise V, I will decrease.
Click to expand...
Click to collapse
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
sharukins said:
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
Click to expand...
Click to collapse
now thats what i call some serious battery saver
sharukins said:
I didn't want to start a discussion about this...
the wattage isn't constant as you calculate it.
calculation power is not equal to electrical power.
voltage itself of course does not drain battery, but what drains battery is wattage, and wattage is reduced due to lower voltage.
the problem is that the unit mAh isn't really the capacity of the battery. the right unit would be Wh or mWh.
so you have to multiply the mAh with the voltage of the batter to get the real capacity.
so decreasing voltage in fact does save you some battery life, but as I said, you wouldn't notice it unless the CPU is under full load the whole time as in smartphones biggest power consumption comes from display and other parts (at least with the slow CPU in the G3).
Click to expand...
Click to collapse
Would have to disagree about a true measure of battery capacity being the Wh, or mWh, as wattage depends on load, and since you never run a battery with 0 load, you cannot represent its capacity using Wh or mWh. I have studied batteries intimately at university level, and know exactly how & why they work. the mAh (Ah) is the industry wide accepted unit for battery capacity, as no matter what the load it is always constant. I am happy to agree that wattage is not always constant for a set frequency on a CPU (as it is possible to over-voltage for that frequency), but for processors such as those which are used in our phones, you very rarely find any substantial over-voltage as due to modern manufacturing techniques there is a much tighter range of voltage acceptance for the core. Hence why most people get only a minute (completely stable) undervoltage. And anyone who would actually gain from undervoltage, would be able to tell that their CPU is using excess energy as ALL this energy would be dispersed as heat. Any extra wattage drawn over what is actually required by the components inside the CPU will be converted to heat as it is not required by the components to run. So unless you see excess heat from your CPU, undervolting will only achieve degraded performance, or CPU stalls. And it is at this point that it will drain the battery more, as there is a minimum wattage that a set frequency requires, if you drop the voltage below what it should be, the amperage will increase to mantain the minimum wattage required (or the CPU will stall and the phone will freeze/switch off). The only real world point to undervolting a CPU is for cooling purposes, the energy savings from doing so are minuscule, to none, and can to a point end up consuming more battery. You would save far more battery by lowering your screen brightness by a few percent.
I wanted to know what the different governors do, rather than filling dev's threads up with questions I thought i would have a look around and do this for others who like me wanted to know what they do:
1: Interactive
The CPUfreq governor "interactive" is designed for low latency, interactive workloads. This governor sets the CPU speed depending on usage, similar to "ondemand" and "conservative" governors. However there is no polling, or 'sample_rate' required to scale the CPU up. Sampling CPU load every X ms can lead to under powering the CPU for X ms, leading to dropped framerate, stuttering UI etc..Scaling the CPU up is done when coming out of idle, and like "ondemand" scaling up will always go to MAX, then step down based off of cpu load.
There is only one tuneable value for this governor: min_sample_time: The ammount of time the CPU must spend (in uS) at the current frequency before scaling DOWN. This is done to
more accurately determine the cpu workload and the best speed for that workload. The default is 50ms.
2:Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
3:Smartass
(Quoted from another author http://www.ziggy471.com/2010/11/07/s...-governor-info ) - "is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
4:Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
I assume performance, conservative, powersave and ondemand are self explanatory,
Userspace - finding conflicting info, so if a dev wants to help me out ??
All this info was found on the web in various places, where possible I have quoted where from. If people would like me to link back to them please let me know I will add.
This is purely to help people understand the governors a little without filling dev threads
Can people also leave user feedback on the governors they have been using to give us a reference point to help us all
if it helped hit thanks
Dooms Kernel : http://forum.xda-developers.com/showthread.php?t=1226826
Schedulers post 3
Nice one Chiefy, good to know we have a thread for quick reference when needing it.
Schedulers
NOOP scheduler
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent
HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a
switched Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Deadline
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.
Anticipatory
Anticipatory scheduling is an algorithm for scheduling hard disk input/output. It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.
"Deceptive idleness" is a situation where a process appears to be finished reading from the disk when it is actually processing data in preparation of the next read operation. This will cause a normal work-conserving I/O scheduler to switch to servicing I/O from an unrelated process. This situation is detrimental to the throughput of synchronous reads, as it degenerates into a seeking workload.[1] Anticipatory scheduling overcomes deceptive idleness by pausing for a short time (a few milliseconds) after a read operation in anticipation of another close-by read requests.[2]
Anticipatory scheduling yields significant improvements in disk utilization for some workloads.[3] In some situations the Apache web server may achieve up to 71% more throughput from using anticipatory scheduling.[4]
The Linux anticipatory scheduler may reduce performance on disks using TCQ, high performance disks, and hardware RAID arrays.[5] An anticipatory scheduler (AS) was the default Linux kernel scheduler between 2.6.0 and 2.6.18, by which time it was replaced by the CFQ scheduler.
BFQ
The Brain **** Scheduler (or BFS) is a task scheduler designed for the Linux kernel in August of 2009 as an alternative to the Completely Fair Scheduler and the O(1) scheduler.[2] BFS was created by veteran kernel programmer Con Kolivas[3].
The objective of BFS, compared to other schedulers, was to provide a scheduler with a simpler algorithm, that did not require adjustment of heuristics or tuning parameters to tailor performance to a specific type of computation workload. The BFS author asserted that these tunable parameters were difficult for the average user to understand, especially in terms of interactions of multiple parameters with each other, and claimed that the use of such tuning parameters could often result in improved performance in a specific targeted type of computation, at the cost of worse performance in the general case.[4] BFS has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.
CFQ
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority. While CFQ does not do explicit anticipatory IO scheduling, it achieves the same effect of having good aggregate throughput for the system as a whole, by allowing a process queue to idle at the end of synchronous IO thereby "anticipating" further close IO from that process. It can be considered a natural extension of granting IO time slices to a process.
I am testing scary at the mo on stock gb so will edit my post tomorrow bro.
over the next week I will use scary, smartass, ondemand, conservative and interactive and report my findings back here
please all get involved and report back your findings
Can people also post their voltage findings with Dooms new kernel
Scary Report
Phone been on 9h 39m, medium usage, clocking set 128-1113, voltages changed as above post,phone very responsive and no lags, battery remaining 39%, AnTuTu benchmark 2755 linpack 39.
Interactive Report
128-1132 up time 6h 25mins, phone responsive no lag, medium usage 36% left, AnTuTu benchmark 2502 linpack 36 this governor doesnt seem to help battery level very much
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Neo said:
6h 25mins and only 36% left? OMG! that's a battery drain!
Well, Quite frankly I went through the governors, Which do you think is better? Can you describe each governor in one word?
I'm on wolf rom with fps uncapped (3.x if i remember well) i haven't upgraded due to the issues pertaining to the users.
Can you just suggest me a good governor based on your experience? Can I get 24 hours of uptime with custom kernels or i still have to wait? ( I know I love OC that we had on 2.2 but looking at the battery drain I'm cautious whether or not to flash the custom kernels )
Thanks for your guide. It's epic!
Click to expand...
Click to collapse
so far the best governors that i have used have been Smartass and Scary but i will continue testing the governors and reporting back. Smartass was working great with no o/c for me, i will add this to this test. tomorrow i will test Scary with no o/c
Ok, my conclusions of using the scary gov on my modded stock gb is probally the best my phone has been, nearly all frequencies are being used, had to use min 192 and max 1190 as had a few screen off reboots but once using those settings my no more reboots. Battery life is the best i have had on custom kernel with flat line overnight, 3% loss, with wifi off and hourly updates of email, deep sleep working perfect as it should.
Overall, this is my personal favorite so far, just to add also this is using...
http://doomlord.sylvester20007.com/x10/x10_gb/dk/v02/dk-v02-X-modfxp_xrec.zip
I have not started using v03 of Dooms new kernel because of the good results with v02x.
Samrtass Report
Running Smartass governor uptime 5hours 1minute 128-1132cpu, medium usage, twitter, facebook two calls, brightness and 50%, AnTuTu Benchmark 1569 linpack 31 ( second linpac got WLOD ) battery 69%
Edit 10hours up time 42% battery left
As you can see smartass is a battery friend but performance suffers, although for my usage i find that this is the best governor for me at the minute
further governor tests continue
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
keep going!!
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
om23 said:
I know this is missing topic but how would I overclock my x10. If it is, how safe is it?
Sent from my x10 Platinum
Click to expand...
Click to collapse
From what I have encountered it depends on the age of your phone, it is safe and won't blow you phone up but some models can handle far greater stress. the newer phones tend to be able to overclock higher, all that will happen if you phone cant handle the overclock is you will get the dreaded WLOD and your phone will reboot, then if you have set the speed from boot you may get stuck at boot image, but if that is the case then you use flash tool and reflash
chiefy009 said:
MIN/MAX Report
I tried to use this governor but it kept causing random reboots so gave up
Click to expand...
Click to collapse
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
MinMax Governor (Battery Saver)
This governor will try to minimize the frequency jumps/changes which cause voltage spikes/changes and supposedly drain more battery life
Click to expand...
Click to collapse
Just my 2 cents!
My_Immortal said:
Thanks for this thread chiefy009!
I have tried all governors too (on Doom's kernel) and I have different experience to yours, so I thought I'd share.
For me, interactive/ondemand/smartass make the phone VERY choppy, especially while scrolling lists!
On the other hand, minmax gives me the smoothest and fastest results.
And I thought that jumping from Deep Sleep/MIN frequency to MAX frequency, without intermediate steps, would kill my battery but, to my amazement, battery life is very very good, I might say better than any other governor.
When I was using minmax as a module to the stock kernel, I got reboots too,
but since Doom integrated it into his kernel, it's stable as rock!
This is the info I found about this governor:
Just my 2 cents!
Click to expand...
Click to collapse
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
chiefy009 said:
Thank you for getting involved, if you have time could you post all your findings on your usage of the governors ?
Click to expand...
Click to collapse
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Scary Governor
Description coming from the author:
A new governor I wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
Click to expand...
Click to collapse
Performance suffers, in my opinion.
It scales the CPU conservatively, so it is very annoying when playing games
or even syncing to get your Gmails.
Also, and this applies to all governors, speed is decreased when the sampling rate is high. Which means that if the CPU constantly checks for load in order to increase/decrease frequency, that will take its toll both to performance and battery life.
Smartass - Interactive - Ondemand
I am putting those 3 governors in the same category, because at least for me, they functioned very similarly.
What I noticed is that indeed the phone used almost all available frequencies before going to MAX, but the phone was laggy. Especially when scrolling in big lists, interactive and smartass gave me unacceptable performance. Ondemand was a tad better, but still, the phone seemed to "resist" scrolling for a few seconds and then go ahead and finally do it!
Battery life was pretty much the same as stock
(since ondemand is the default governor for stock kernel).
MinMax
As I stated in my previous post, minmax gave me the smoothest and fastest results.
This governor doesn't take intermittent load samples, when it first detects CPU load, aka you start using your phone, it jumps to the max frequency and stays there until you stop using it.
At this point, I want to express my opinion on the subject of "High Freq When Screen On", because many users complain about it, but I beg to differ.
In theory, CPU running at max frequency all the time, is heat generating and/thus battery consuming. Alas, be careful: in theory...
Because practically, when you use your phone, you usually do CPU demanding tasks.
When the phone is in my pocket/bag/drawer/whenever doing nothing, I want to be in Deep Sleep.
When I turn it on to look at the time of if there's any new notification, that lasts 30 secs - 1 minute. What frequency will be used then, is not that important.
When I turn it on to actually do something, I want it to be FAST.
If I can scroll a list faster, if I can open an app faster, then I will be using the phone for less time.
If the CPU is sampling and scaling up conservatively, the phone will be laggy
and I will need more time to accomplish my tasks.
All in all, I am not intimitaded by high frequencies while using the phone.
I would start worrying if I got no Deep Sleep -which isn't the case fortunately.
And my battery life is amazing, I get about 1 day and a few hours more,
with pretty heavy use.
Just my 2 cents on the matter.
Powersave
If you are ever really mad at your X10 and you want to see it struggle and suffer, then this is the governor for you! Enough said!
Performance
Pretty snappy, good for gaming and benchmarking, as it uses only MAX frequency. Not for prolonged use though, because it will ONLY use the max frequency (and Deep Sleep of course).
I'll make sure to make more tests in the future and post more thorough reviews!
Again, thanks for this thread chiefy009!!
My_Immortal said:
Sure thing!
I am on Doom's kernel, which I believe includes all the available governors so far.
Click to expand...
Click to collapse
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
chiefy009 said:
Are you playing with the voltages at all ? if so could you record your findings for everyone ?
I am currently working through the governor list and then plan on trying to level out some voltages which work well
Click to expand...
Click to collapse
I have undervolted my phone using these values:
128000 Hz - 875 V
192000 Hz - 900 V
245760 Hz - 925 V
384000 Hz - 950 V
460800 Hz - 975 V
576000 Hz - 1000 V
652800 Hz - 1050 V
768000 Hz - 1100 V
844800 Hz - 1150 V
921600 Hz - 1200 V
998400 Hz - 1250 V
The phone runs pretty stable, didn't have a single reboot or WLOD so far (3 days).
Xperia X10i via Tapatalk
I will try those settings for undervolting
Smartass Update
This governor is working wonders for me at the minute, phone been online for 6hours, medium/light usage 128-1132mhz few calls, connected to bluetooth speaker in car, little web usage and twitter and the battery is still on 88%
That is impressive
(If you own a Nexus 5X or 6P and you are too lazy to read the philosophy of this technique, head on down to the 2nd post and pop those values into your kernel manager and be happy. If you own a different device, please read this post in full.)
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor. :good:
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*At least on the Nexus 5X, you shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
After a bit of tweaking and experimenting, I developed some settings that provide absolutely incredible battery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even a Nexus 5X. This will work on any ROOTed phone with the Interactive governor!
So, after writing a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Nexus 5X you can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
(Note: If your device supports per-core hotplugging, you might be better off using the old guide to determine your nominal clock rates. The Nexus 5X and all current kernels only support hotplugging entire CPUs, so your results may vary if you use any other device.)
For example, on my Nexus 5X, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 460Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Nexus 5X is 460Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Because I cannot find the stock voltages of the Nexus 5X clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the 5X's Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz
Video - 787Mhz
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 1 ("little"–the one with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000 460000:60000 600000:20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 600000
min_sample_time - 30000
target_loads - 98 460000:19 600000:80 672000:12 787000:81 864000:9 960000:69 1248000:95 1440000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels (including stock on Nexus 5X) that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the 2nd CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable. On the Nexus 5X, touchboost adds no perceptual performance gain and only hurts efficiency and battery life. If your kernel doesn't allow you to turn off touchboost, try another one, like the excellent ElementalX.
Your battery life will thank you!
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
I will be happy to answer any questions, or provide any guidance I can. However:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.
I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.
I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized Nexus 5X running ElementalX Kernel, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
In the "CPU" section, turn off "Touchboost". (This is crucial!! YOU MUST TURN OFF TOUCHBOOST OR ELSE YOU WILL NOT SEE ANY BATTERY SAVINGS!!!) Make sure the "Max CPU Frequency" is set to the maximum possible value for each CPU. Make sure the "Min CPU Frequency" is set to the minimum possible value for each CPU. Then set the following values for each CPU under "Governor options" for each CPU respectively:
CURRENT STABLE – Version 2.0
Nexus 5X - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "has 4 cores", aka "maxes out at 1440Mhz")
target_loads - 75 460000:69 600000:80 672000:76 787000:81 864000:81 960000:69 1248000:78
timer_slack - -1
hispeed_freq - 460Mhz
timer_rate - 20000
above_hispeed_delay - 30000 600000:20000 672000:10000
go_hispeed_load - 75
min_sample_time - 60000
CPU #2 (aka "big", aka "has 2 cores", aka "maxes out at 1824Mhz")
target_loads - 72 480000:68 633000:74 768000:80 864000:81 960000:69 1248000:83 1344000:84 1440000:84 1536000:84 1632000:86 1689000:83
timer_slack - 80000
hispeed_freq - 633Mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 72
min_sample_time - 100000
Under "CPU Boost", set "input boost milliseconds" to "0".
Nexus 6P - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "low", aka "maxes out at 1555Mhz")
target_loads - 75 460000:69 600000:80 672000:79 768000:80 864000:81 960000:69 1248000:84 1344000:82 1478000:86
timer_slack - -1
hispeed_freq - 460Mhz
timer_rate - 20000
above_hispeed_delay - 30000 600000:20000 672000:10000
go_hispeed_load - 75
min_sample_time - 60000
CPU #2 (aka "big", aka "fast", aka "maxes out at 1948Mhz")
target_loads - 72 480000:68 633000:74 768000:80 864000:81 960000:69 1248000:84 1344000:84 1440000:84 1536000:85 1632000:85 1728000:85 1824000:84
timer_slack - 80000
hispeed_freq - 768mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 72
min_sample_time - 100000
Under "CPU Boost", set "input boost milliseconds" to "0".
(Having trouble applying these? Check out these great scripts from @Alcolawl PLEASE NOTE THAT THESE ARE OFFICIALLY UNSUPPORTED–direct your queries to Alcolawl so he might provide assistance.)
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
NEW! GlassFish (For most devices!) - High battery savings with buttery smooth interface!
NEW! HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
ARCHIVE
v1.0
Nexus 5X - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "has 4 cores", aka "maxes out at 1440Mhz")
target_loads - 98 600000:80 787000:81 960000:69 1248000:85 1440000:90
timer_slack - 80000
hispeed_freq - 600Mhz
timer_rate - 20000
above_hispeed_delay - 10000
go_hispeed_load - 64
min_sample_time - 80000
CPU #2 (aka "big", aka "has 2 cores", aka "maxes out at 1824Mhz")
target_loads - 90 633000:74 768000:80 960000:69 1248000:83 1536000:84 1689000:90
timer_slack - 80000
hispeed_freq - 1248Mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 80000
Under "CPU Boost", set "input boost milliseconds" to "0".
Nexus 6P - The "Easy Way" Setup - For ElementalX Kernel
CPU #1 (aka "little", aka "low", aka "maxes out at 1555Mhz")
target_loads - 98 600000:80 768000:80 960000:69 1248000:84 1478000:85 1555000:90
timer_slack - 80000
hispeed_freq - 600Mhz
timer_rate - 20000
above_hispeed_delay - 10000
go_hispeed_load - 64
min_sample_time - 80000
CPU #2 (aka "big", aka "fast", aka "maxes out at 1948Mhz")
target_loads - 90 633000:74 768000:80 960000:69 1248000:83 1536000:84 1632000:85 1824000:90
timer_slack - 80000
hispeed_freq - 633mhz
timer_rate - 10000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 80000
Under "CPU Boost", set "input boost milliseconds" to "0".
Changelog:
8/23/16 - Added GlassFish profile
8/16/16 - Added HawkTail profile
1/24/16 - Added instructions to use EXKM's native profiles
1/4/16 - Archived v1.0; elevated "crazy alpha 2" to v2.0 and posted; added links to other alpha settings
12/27/15 - Updated for better performance on 5X and 6P
12/25/15 - Updated to improve battery use on 6P and somewhat on 5X
12/23/15 - Made the beta #2 settings the default; added settings for 6P
FAQ
In this guide, I am using the ElementalX Kernel on the Nexus 5X. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that isn't ElementalX on Nexus 5X, for which this guide was written. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!
been waiting for this since I saw a few posts saying it would be released on r/nexus5x
Thanks!
What program to use to set all these tweaks?
Smultie said:
What program to use to set all these tweaks?
Click to expand...
Click to collapse
I recommend using the ElementalX kernel with the ElementalX Kernel Manager, because it supports all of the features necessary to get the most out of this guide. (Especially turning off touch boost.)
That said, you can try any kernel manager to make these changes. Just search Google Play!
How important is io_is_busy? Can't find that string in the elemental X app.
What are your thoughts, if any, on zram and swappiness values?
soniCron said:
I recommend using the ElementalX kernel with the ElementalX Kernel Manager, because it supports all of the features necessary to get the most out of this guide. (Especially turning off touch boost.)
That said, you can try any kernel manager to make these changes. Just search Google Play!
Click to expand...
Click to collapse
I tried it with Kernel Adiutor, but I noticed that I can't set "hispeed_freq - 600000" on CPU1. Closest options are 480000 and 633600. Which one to choose?
Smultie said:
I tried it with Kernel Adiutor, but I noticed that I can't set "hispeed_freq - 600000" on CPU1. Closest options are 480000 and 633600. Which one to choose?
Click to expand...
Click to collapse
What kernel are you using?
soniCron said:
What kernel are you using?
Click to expand...
Click to collapse
Stock
dg4prez said:
How important is io_is_busy? Can't find that string in the elemental X app.
What are your thoughts, if any, on zram and swappiness values?
Click to expand...
Click to collapse
Sorry, that was inadvertently copied from the old guide. I'll remove it from the post. You can ignore that setting.
Far as zram, I'm not sure, yet. I haven't spent time exploring it on this device. That said, I'm not sure disabling it will improve performance in any noticeable way on this device. With these governor settings, things are screamingly fast, and my concern would be with more apps unloading because of the smaller RAM.
I'll make additional posts as I discover the most reasonable tweaks for this device, but not before I test each methodically and thoroughly...
soniCron said:
Sorry, that was inadvertently copied from the old guide. I'll remove it from the post. You can ignore that setting.
Click to expand...
Click to collapse
I already set it at 0. Should I put it back at 1?
Smultie said:
Stock
Click to expand...
Click to collapse
Would you mind posting all the frequencies available for both CPUs? I'll update the guide to reflect the proper values.
I'm using ElementalX because of its ability to turn off touch boost, so I haven't worked much with the stock kernel.
Thanks!
Smultie said:
I already set it at 0. Should I put it back at 1?
Click to expand...
Click to collapse
Leave it at 0 until I can investigate the stock kernel options.
soniCron said:
Would you mind posting all the frequencies available for both CPUs? I'll update the guide to reflect the proper values.
I'm using ElementalX because of its ability to turn off touch boost, so I haven't worked much with the stock kernel.
Thanks!
Click to expand...
Click to collapse
Big:
Deep Sleep, 384, 480, 633, 768, 864, 960, 1248, 1344, 1440, 1536, 1632, 1689, 1824
Little:
Deep Sleep, 384, 460, 600, 672, 787, 864, 960, 1248, 1440
Also: Stock kernel in combination with Kernel Adiutor allowed me to disable 'Input Boost Frequency Core 1' which I assumed is the same as touch boost. It's described as 'CPU frequency to be boosted to this frequency upon input detection'.
Thanks for your quick replies.
Smultie said:
Big:
Deep Sleep, 384, 480, 633, 768, 864, 960, 1248, 1344, 1440, 1536, 1632, 1689, 1824
Little:
Deep Sleep, 384, 460, 600, 672, 787, 864, 960, 1248, 1440
Also: Stock kernel in combination with Kernel Adiutor allowed me to disable 'Input Boost Frequency Core 1' which I assumed is the same as touch boost. It's described as 'CPU frequency to be boosted to this frequency upon input detection'.
Thanks for your quick replies.
Click to expand...
Click to collapse
Ohhhhh! Okay, I see what's going on! The little CPU is #1 and the big CPU is #2. Reverse your assignments and it should all be fine.
I'll update the post to clarify. (I thought it was a little strange that there would be different clock rates for different kernels. Didn't even think that was possible since it's a hardware feature, not a kernel feature. You had me thinking I missed some major technological advancement! )
soniCron said:
Ohhhhh! Okay, I see what's going on! The little CPU is #1 and the big CPU is #2. Reverse your assignments and it should all be fine.
I'll update the post to clarify. (I thought it was a little strange that there would be different clock rates for different kernels. Didn't even think that was possible since it's a hardware feature, not a kernel feature. You had me thinking I missed some major technological advancement! )
Click to expand...
Click to collapse
Might be a bug in Kernel Adiutor cause I can select the same hispeed_freq for both CPU's (big/little or 1/2).
Also, you state that you want the big CPU to only run at 384, 1248 and 1824 MHz, but I notice it never reaching lower than 633MHz. Are you sure your settings are correct?
Smultie said:
Might be a bug in Kernel Adiutor cause I can select the same hispeed_freq for both CPU's (big/little or 1/2).
Click to expand...
Click to collapse
I made a simplified guide for you (and others):
http://forum.xda-developers.com/showpost.php?p=64279960&postcount=2
I haven't used a kernel manager besides EX Kernel Manager that supports 2 CPUs reliably, so if you're having problems, I suggest you try EX.
If you find one that will modify the stock kernel reliably, please let me know and I'll update the simplified version of the guide to reflect that.
Thanks for your feedback! (And warnings! And concerns!)
Smultie said:
Also, you state that you want the big CPU to only run at 384, 1248 and 1824 MHz, but I notice it never reaching lower than 633MHz. Are you sure your settings are correct?
Click to expand...
Click to collapse
Can you set the minimum clock rate for the big CPU? If that's not possible to set at 384 in stock, I'll update the guide. If it is, then that needs to be done as well.
soniCron said:
Can you set the minimum clock rate for the big CPU? If that's not possible to set at 384 in stock, I'll update the guide. If it is, then that needs to be done as well.
Click to expand...
Click to collapse
In your main guide you state for CPU1:
above_highspeed_delay - 20000 460000:60000 600000:20000
In the "learn to read" guid you state:
above_highspeed_delay - 20000
Which is the correct one?
Also, can't find "Touchboost" under "CPU". Can you be a bit more specific maybe?
Hey guys,
I noticed when my Galaxy S5 is not on charger, it constantly discharges at a rate of -450mA. That seems to be a bit weird, as when I measured the discharge rate on other phones, the value used to change, based on the actual usage (i.e. diplay brightnesss, cpu freq etc.). Do you guys have any information/recommendation regarding that issue?
Kind regards,
Kenny
First of all read orginal thread for Nexus 5
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557i
Please read this post in full
also read this document:
https://android.googlesource.com/ke...7aebe08b/Documentation/cpu-freq/governors.txt
For now the tweak is only for ARDE overclocked kernel,Underclocked kernel from @Unjustified Dev
If you are too lazy to read the post and configure what suites best for your device I made a template kernel with already integrated tweaks working on all Cm based roms and ill upoload it asap
or simply use Kernel Aduitor to input theese settings
updated Mar.29.2016
Setting for little CPU :
above_highspeed_delay - 25000 800000:50000 998400:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 89
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 80 523400:60 800000:77 998400:81 1113600:77 1309000:81 1448000:81 1601000:10
timer_rate - 20000
timer_slack - 60000
Setting for BIG CPU:
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:24 960000:16 1113600:20 1334000:81 1497600:7 1612800:6 1651200:96
timer_rate - 20000
timer_slack - 80000
NOTE:If the big cpu minimum frequencie keeps reverting to 960mhz change governeur to smartmax, liitle cpu max frequencie to 1334000
settings for underclocked kernel (200mhz-1.4ghz) in post 54
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*You shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
So, after reading a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Idol 3
In this guide, I am using the ARDE overclocked and underclocked kernel by @Unjustified Dev Kernel on moded stock rom by @DallasCZ AICP rom and latest CM 12.1 by @The Marionette. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that mpdecision driver. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!u can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the little CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the BIG CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allow
For example, on my Idol 3, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 800Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Idol3 is 800Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
Because I cannot find the stock voltages of the Idol 3 clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Idols Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 533Mhz
Page Scrolling - 800Mhz -
Video -960Mhz-
App Loading - 960Mhz-
High Load Processing - 144800Mhz-
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Idol 3 If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 533Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 960Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1656Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 533333:60000 800000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 533Mhz. Once it has exceeded 533Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Idol 3, use the following Interactive governor settings for little CPU 1 (with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Idol 3, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (533Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "30000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 800Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Idol 3.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
Max. Eff. Load:
Clock rate/next highest clockrate * 90%
533MHz/800MHZ * 90%
Min. Eff. Load:
(Next highest clock rate / clock rate - 1) * 100%
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(Next highest clock rate / clock rate - 1) * 100%
(800Mhz/533Mhz-1)*100
For the Idol 3, the maximal efficient loads of little CPU are:
533333:60
800000:72
998400:80
1113600:76
1303000:81
1448000:81
1601000:95
For the Idol 3, the minimal efficient loads of little CPU are:
533333:5
800000:24
998400:11
1113600:17
1303000:10
1448000:10
1601000:0
For the Idol 3, the maximal efficient loads BIG CPU are:
533333:60
800000:75
960000:77
1113600:74
1344000:80
1497600:83
1612800:87
1651200:95
For the Idol 3, the minimal efficient loads BIG CPU are:
533333:5
800000:24
960000:16
1113600:20
1344000:11
1497600:7
1612800:2
1651200:2
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That BIG CPU?!
So we've all but ignored the BIG CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Idol, the system is pretty smart about when to employ the power of this inefficient BIG CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
533Mhz
1344Mhz
1651Mhz
In this case, we configure it just as we did with little CPU , but only worry about keeping it idle as much as possible, allow it to jump to 1651Mhz immediately when needed, and encourage it to fall back to 1344Mhz if a sustained load is needed.
These values are ideal for the Idol, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
The Money Shot: Part Deux
If you are using a Idol 3, use the following Interactive governor settings for BIG CPU 2. (the one with 2 cores)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the little CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
i am currently using it for two days...will report how it goes
DallasCZ said:
i am currently using it for two days...will report how it goes
Click to expand...
Click to collapse
this is still not finished only copy paste thread .i have frequencies and loads on paper ,after i finish trhead i few minutes its for everyone ill upload two kernels with implemeted setting one with min 200 mhz and one with 533 min on your rom,and i was wondering is it posible to disable mpdecision on your stock rom since i have buttiful battery life for some thime but as just as i lock or go to deepsleep min frequencies are revertet to 960 instead of 533
nero curin said:
this is still not finished only copy paste thread .i have frequencies and loads on paper ,after i finish trhead i few minutes its for everyone ill upload two kernels with implemeted setting one with min 200 mhz and one with 533 min on your rom,and i was wondering is it posible to disable mpdecision on your stock rom since i have buttiful battery life for some thime but as just as i lock or go to deepsleep min frequencies are revertet to 960 instead of 533
Click to expand...
Click to collapse
I cant help you with the mpdecision, I am only modder not a dev.
the hernel would be awsome. Please correct the title * [GUIDE] [PERDORMANCE] [BATTERY] Idol 3 (6045x) advanced Interactive gouv settings* is wrong, it should be * [GUIDE] [PERFORMANCE] [BATTERY] Idol 3 (6045x) advanced Interactive gov settings* ..but if you will implement those settings to ARDE DEV kernel, please ask them for permission, or rename this thread to something like this *[KERNEL] 6045x ARDE DEV KERNEL MOD*
I'm using this governors and the battery and perfomance are greater on my personal build flyme os 4.5.4
---------- Post added at 04:19 PM ---------- Previous post was at 04:11 PM ----------
And in Which Rom the governors works best ?
i use Arde OC on Flyme my personal build
Here's mine Screenshoots with this governors on Flyme
charged to 92 %
and the Screentime is 31 min
and the mm-pp-daemon doesn't drains battey
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
DallasCZ said:
i am currently using it for two days...will report how it goes
Click to expand...
Click to collapse
are you using these setting wich I updated just now or you have done your calculations
i am using the calculations you wrote in the cm12. 1 thread.
Odesláno z mého 6045X pomocí Tapatalk
so far it looks great. 3 hours of SoT and 40% battery left.
Odesláno z mého 6045X pomocí Tapatalk
DallasCZ said:
so far it looks great. 3 hours of SoT and 40% battery left.
Odesláno z mého 6045X pomocí Tapatalk
Click to expand...
Click to collapse
Those were rough calculations,these are more precise,I got like 7 hrs sot time it can get more also I got 34750 score on antutu only problem is mpdesicion which raises min CPU freq to 960 and that drains more battery
nero curin said:
Those were rough calculations,these are more precise,I got like 7 hrs sot time it can get more also I got 34750 score on antutu only problem is mpdesicion which raises min CPU freq to 960 and that drains more battery
Click to expand...
Click to collapse
if oyu look on my screens from the LITLLE cluster it is almost all the time on 533 MHz
DallasCZ said:
if oyu look on my screens from the LITLLE cluster it is almost all the time on 533 MHz
Click to expand...
Click to collapse
can you upload screenshot of BIG cluster
Did somebody stock rom for TWRP recovery? ...6045Y
This is a very interesting thread but very in depth, I'm not sure where to start I'd like to tweak interactive for my m8 would you be able to give me some guidance of its not too much trouble thank you in advance.
Sent from my HTC One_M8 using Tapatalk
smeejaytee said:
This is a very interesting thread but very in depth, I'm not sure where to start I'd like to tweak interactive for my m8 would you be able to give me some guidance of its not too much trouble thank you in advance.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
this is the guide,take a pice of paper wright your frequencies and use the formula above to calculate wich frequencies to use more and wich less,its acttualy real simple
Sent from my 6045X using Tapatalk
nero curin said:
this is the guide,take a pice of paper wright your frequencies and use the formula above to calculate wich frequencies to use more and wich less,its acttualy real simple
Sent from my 6045X using Tapatalk
Click to expand...
Click to collapse
I've been reading for an hour or so mate, what's throwing me is the big CPU and little CPU bit I'm guessing this is referring to octocore but I have a quad core, I've set up according to your template which is quite similar to the interactive settings i had set anyway, but there are parameters missing are they not needed like sync frequency and up threshold. I'll try and do some more reading but it is a lot to take in lol thanks for the reply.
Sent from my HTC One_M8 using Tapatalk
smeejaytee said:
I've been reading for an hour or so mate, what's throwing me is the big CPU and little CPU bit I'm guessing this is referring to octocore but I have a quad core, I've set up according to your template which is quite similar to the interactive settings i had set anyway, but there are parameters missing are they not needed like sync frequency and up threshold. I'll try and do some more reading but it is a lot to take in lol thanks for the reply.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
then read orginal thread,theere is a guide for dual core wich can be aplyed to quad core,or simply use setting based based my little cores with applyng your frequencies becouse they are doing al the work and big cores only burst.cheers
Sent from my 6045X using Tapatalk
nero curin said:
First of all read orginal thread for Nexus 5
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557i
Please read this post in full
For now the tweak is only for ARDE overclocked kernel,Underclocked kernel from @Unjustified Dev in a few days
If you are too lazy to read the post and configure what suites best for your device I made a template kernel with already integrated tweaks working on all Cm based roms and ill upoload it asap
or simply use Kernel Aduitor to input theese settings
Setting for little CPU :
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
Setting for BIG CPU:
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*You shouldn't be turning your screen brightness above about 60%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
So, after reading a (nearly identical) guide for the EvoLTE folks over a year ago, I'm now back to update this information to provide strategies for multi-CPU devices, as well as specific settings for the Idol 3
In this guide, I am using the ARDE overclocked and underclocked kernel by @Unjustified Dev Kernel on moded stock rom by @DallasCZ AICP rom by @The Marionette. If you are using a different kernel or device, your available features may vary, so you must determine the appropriate values to use based on the instructions in this guide! If you are too lazy to do this, I will try to keep a running list of compatible settings you can just plug-and-go. But the purpose of this guide is to assist you in discovering the best values to use with your device, so if something doesn't work, it's because you're probably not following the guide and coming up with your own values! specific to your kernel and device combo! You've been warned!
My settings don't show up after I reboot! What am I doing wrong??
If you are using EX Kernel Manager, tap the power icon to the right of the setting after you set it. If you are using a different kernel manager, check with that developer to see how it's implemented. Also, give the kernel manager a few minutes after the device boots. The settings aren't applied immediately, so check back after 3 minutes and you should see the correct values.
Why is one of my CPUs not letting me change a setting or set a certain frequency?
The device may be thermally throttling and had turned off that CPU or limited it. Turn off your device and let it cool for 5 minutes, then try again. (Keep it unplugged and make sure you don't have any apps running that might be trying to use a lot of CPU while the device is off.)
These settings don't work/I'm not getting great screen on time!
You probably haven't disabled touch boost. YOU MUST DISABLE TOUCHBOOST, OR THIS WON'T SAVE YOU JACK SQUAT!!
How do I change governor/kernel settings?
If you're not comfortable or don't know how to do this, search the XDA forums. There are plenty of guides that explain this in great detail.
My kernel editor won't let me set [whatever]Mhz for a value you showed!
Either you have done something wrong, or you're using a kernel/device combo that mpdecision driver. Follow the instructions in the first post to determine the appropriate settings for your own device!
Do I have to be rooted?
Yes. See the fourth question and learn more about your device before trying to change things like governor settings!u can use right away.
Enough long winded preamble! Let's get down to...
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the little CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the BIG CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allow
For example, on my Idol 3, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the first CPU clock rates are no less than 800Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Idol3 is 800Mhz.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
Because I cannot find the stock voltages of the Idol 3 clock speeds, this section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Idols Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 533Mhz
Page Scrolling - 800Mhz -
Video -960Mhz-
App Loading - 960Mhz-
High Load Processing - 144800Mhz-
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Idol 3 If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 533Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 960Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1656Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 533333:60000 800000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 533Mhz. Once it has exceeded 533Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
The Money Shot
If you've made it this far, you're ready to put these strategies into play! If you have not read the previous sections, DO NOT COMPLAIN IF THE DEFAULT SETTINGS DON'T PROVIDE WHAT YOU'RE LOOKING FOR!! These settings are templates only and these need to be adjusted for each case based on your system and usage patterns! IF YOU ARE NOT GETTING THE PERFORMANCE OR BATTERY LIFE PROMISED, ***READ THE SECTIONS ABOVE!!!***
With that out of the way... let's rock!
If you are using a Idol 3, use the following Interactive governor settings for little CPU 1 (with 4 cores) and then tweak with the instructions below:
(If you are using a phone other than a Idol 3, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 30000 533333:50000 800000:30000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 800000
min_sample_time - 30000
target_loads - 98 533333:5 800000:72 998400:80 1113600:17 1309000:11 1448000:81 1601000:95
timer_rate - 20000
timer_slack - 80000
These defaults work fine for me, but I have otherwise optimized my system fully, so they are at the minimal adequate values. If you have background tasks that consume any somewhat significant amount of CPU on a constant basis, you will most likely see awful, stuttery performance and poor battery life! So you must adjust them to suit your system before you see results!!! Anything more than about 15-20% idle CPU use at any given time will negatively affect the results you see without further tweaking!
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (533Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "30000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 800Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Idol 3.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Idol 3, the maximal efficient loads of little CPU are:
533333:60
800000:72
998400:80
1113600:76
1303000:81
1448000:81
1601000:95
For the Idol 3, the minimal efficient loads of little CPU are:
533333:5
800000:24
998400:11
1113600:17
1303000:10
1448000:10
1601000:0
For the Idol 3, the maximal efficient loads BIG CPU are:
533333:60
800000:75
960000:77
1113600:74
1344000:80
1497600:83
1612800:87
1651200:95
For the Idol 3, the minimal efficient loads BIG CPU are:
533333:5
800000:24
960000:16
1113600:20
1344000:11
1497600:7
1612800:2
1651200:2
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That BIG CPU?!
So we've all but ignored the BIG CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Idol, the system is pretty smart about when to employ the power of this inefficient BIG CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
533Mhz
1344Mhz
1651Mhz
In this case, we configure it just as we did with little CPU , but only worry about keeping it idle as much as possible, allow it to jump to 1651Mhz immediately when needed, and encourage it to fall back to 1344Mhz if a sustained load is needed.
These values are ideal for the Idol, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
The Money Shot: Part Deux
If you are using a Idol 3, use the following Interactive governor settings for BIG CPU 2. (the one with 2 cores)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1651200
min_sample_time - 20000
target_loads - 98 533333:60 800000:20 960000:16 1113600:20 1344000:80 1497600:7 1612800:2 1651200:95
timer_rate - 20000
timer_slack - 80000
What About Bob Touchboost?
Touchboost is a nifty feature in a lot of kernels that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the little CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
Click to expand...
Click to collapse
Whick Rom did you USE,and Which kernel ?
Alek Dev said:
Whick Rom did you USE,and Which kernel ?
Click to expand...
Click to collapse
moded stock from @DallasCZ currently with oc kernel already in rom
Sent from my 6045X using Tapatalk
nero curin said:
moded stock from @DallasCZ currently with oc kernel already in rom
Sent from my 6045X using Tapatalk
Click to expand...
Click to collapse
okay,when you will upload new kernel you maded with governors,in the rom made by dallascz i get reboots with this kernel
Alek Dev said:
okay,when you will upload new kernel you maded with governors,in the rom made by dallascz i get reboots with this kernel
Click to expand...
Click to collapse
there is alternative kernel for versions with reboots on his thread also OC kernel,im experimenting with difrent frquencies.when im sure i got the right thing ill upload until then everyone can calculate frequencies for kernel they are using ore use the themplate settings
Sent from my 6045X using Tapatalk