Related
Hi guys,
Please clarify on the following points:
1. Are there any major differences among the CPU governers??? I use Smartass because I see a major group of people using it.
2. What are the optimal values for Min and Max CPU speed? And are there any factors based on which we have to decide the values or we can keep anything we wish?
Thanks in advance
Frequencies and their effect on battery here
^Pretty much what you're looking for. Just analyze the chart and test it for yourself too. Also read, read
For governors:
smartass governor - 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.
ondemand
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed. - SetCPU website
conservative
Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery. - SetCPU website
performance
Available in most kernels. It will keep the CPU running at the "max" set value at all times. This is a bit more efficient than simply setting "max" and "min" to the same value and using ondemand because the system will not waste resources scanning for the CPU load. This governor is recommended for stable benchmarking. - SetCPU website
powersave
Available in some kernels. It will keep the CPU running at the "min" set value at all times. - SetCPU website
userspace
A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor. - SetCPU website
interactive
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a workqueue context, the 'interactive' governor does this in a timer context, which gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling up, giving the remaining tasks the cpu performance benefit, unlike existing governors which schedule rampup work to occur after your performance starved tasks have completed.
Click to expand...
Click to collapse
I hope that makes it clearer
Kira.Lawliet said:
Frequencies and their effect on battery here
^Pretty much what you're looking for. Just analyze the chart and test it for yourself too. Also read, read
I hope that makes it clearer
Click to expand...
Click to collapse
Wonderful post! Thank you.. even though the post was too technical for a n00b like me, I could grasp info out of it. Sure it helped me.
I was just wondering what people get for battery life with miui 1.7.8 and OTB .13 kernel.
Also, what does overclock actually mean? Does it mean that setting the min and max to 1400Mhz in Voltage Control or remain the min to 100 and max to 1400Mhz?
I'm currently on noop, ondemand and min=100Mhz, max=1400Mhz with nothing UV'ed.
Please help me to get better battery life!!!!!!!!
Your CPU by default can do, unmodified, a certain number of commands per second. These commands are measured in Hertz, thus a 1GHz processor does about 1 billionish commands per second. Overclocking means you allow your processor to do more commands in the same time frame. The downside to this, however, is that more electricity is flowing through the CPU, thus draining the battery more. Having a lower clock speed will save some battery life.
That being said, I have kept my CPU clocked at maximum of 1GHz, with the I/O Scheduler set to deadline and the CPU Governor set to smartass, and I'm getting about a day out of my battery, maybe a little less. I have no idea if that's the "optimal" battery saver setting, but it works for me.
I do have a question, though... What do those two settings mean, anyway?
1n73rn37_j3d1 said:
Your CPU by default can do, unmodified, a certain number of commands per second. These commands are measured in Hertz, thus a 1GHz processor does about 1 billionish commands per second. Overclocking means you allow your processor to do more commands in the same time frame. The downside to this, however, is that more electricity is flowing through the CPU, thus draining the battery more. Having a lower clock speed will save some battery life.
That being said, I have kept my CPU clocked at maximum of 1GHz, with the I/O Scheduler set to deadline and the CPU Governor set to smartass, and I'm getting about a day out of my battery, maybe a little less. I have no idea if that's the "optimal" battery saver setting, but it works for me.
I do have a question, though... What do those two settings mean, anyway?
Click to expand...
Click to collapse
What do you mean by two settings?
Like, what are I/O Schedulers and CPU Governors? That last question was me hijacking the thread.
Hey guys!
I was wondering if anyone can give me some info on the differences between the governors with doomkernel and the schedulers.
Thanks!
Cheers,
This was posted by DooMLoRD, i just copied the post not all governors are there:
2. Governors In the Linux Kernel ================================
2.1 Performance ------------------------------
The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.
2.2 Powersave ----------------------------
The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.
2.3 Userspace ----------------------------
The CPUfreq governor "userspace" allows the user, or any userspace program running with UID "root", to set the CPU to a specific frequency by making a sysfs file "scaling_setspeed" available in the CPU-device directory.
2.4 Ondemand ---------------------------
The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters:
sampling_rate: measured in uS (10^-6 seconds), this is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more.
show_sampling_rate_(min|max): the minimum and maximum sampling rates available that you may set 'sampling_rate' to.
up_threshold: defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.
ignore_nice_load: this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
2.5 Conservative -------------------------------
The CPUfreq governor "conservative", much like the "ondemand" governor, sets the CPU depending on the current usage. It differs in behaviour in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the "ondemand" governor through sysfs with the addition of:
freq_step: this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor.
down_threshold: same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
2.6 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.7 MinMax ------------------------------
The CPUfreq governor "maxmin" tries to minimize the frequency jumps by limiting the selected frequencies to only two frequencies: either the min or the max frequency of the current policy. The frequency is raised or lowered according to the current load and the 'up_threshold' and 'down_threshold'.
Its parameters and implementation are similar to that of conservative.
It does not have the freq_step parameter as it jumps right from min to max and vice-versa.
The sampling_down_factor, unlike conservative, will count the minimal number of samplings since the last time we saw the 'up_threshold' load on the CPU. Hence it is set to higher default and acts as a limiter not to do too many frequency jumps without hurting the performance.
Thanks sorry, didnt see it for some reason. Ignore my questions.
Cheers,
oppiee said:
Thanks sorry, didnt see it for some reason. Ignore my questions.
Cheers,
Click to expand...
Click to collapse
One thing to note pal. All chipsets have different tolerances so whereas interactive works best for me, it may not be good for u. Just test em and use CPU spy/ ur own judgement to c which suits ur phone best.
Sent from my X10i using XDA App
Yup I am currently fiddling around with the different settings. The main thing I want to accomplish is not to have lag when im scrolling and opening up basic apps such as dialer and browser. I dont really play games. I hate the fact that the phone lags up sometimes. So far Its ok, but getting some WLOD on super high freq.
Any suggestions?
oppiee said:
Yup I am currently fiddling around with the different settings. The main thing I want to accomplish is not to have lag when im scrolling and opening up basic apps such as dialer and browser. I dont really play games. I hate the fact that the phone lags up sometimes. So far Its ok, but getting some WLOD on super high freq.
Any suggestions?
Click to expand...
Click to collapse
Can u post a screenshot of CPU tuner or whatever u use of freqs u use? Also are u using doomkernel fs version as I think some handsets can't even boot up oc kernel.
Sent from my X10i using XDA App
Any good programs to take screen shots? I am using the highest OC kernel by DL, and using doomkernel wolfbreak V7b6.
Not mean to sound patronising pal but just type screen shot into android market theres plenty
Edit: ur phone prob can't handle the overclock. Read the kernel thread it says this pal.
Sent from my X10i using XDA App
Oh i think there might has been some misunderstanding. My phone is running fine, just doing some testing. at 1.229 Mhz I tend to get WLODs, using minmax with SIO.
At 1.114 and 245, using min max with SIO. everything is fine so far. I just thought you wanted to know for your own purposes.
Cheers
Sorry buddy I misunderstood
Sent from my X10i using XDA App
thers some missing from the top
lagfree
scary
brazilianwax
savaged zen
what do theese do
also whats the best settings from all of them from your opinion
I have:
Brazilianwax
Smoothass
Lagfree
Smartassv2
SavagedZen
Scary
Smartass
Minmax
Interactivex
Interactive
Conservative
Userspace
Powersave
OnDemand
Performance.
Not used them all but lagfree is (as suggested free from lag & smooth. Brazilianwax didnt work for me very laggy. Scary was quite good also, along with interactive. Not really tested the others enough to pass comment to be honest
I bought a new android phone which is the Live with Walkman(WT19i) here in the Philippines, and I'm loving it, except for the battery life
Live with Walkman is known for its poor battery life(which i found here in xda forums), probably because of the crapware software installed in stock ROM and battery which is the EP500 rated at 3.7v 1200mAh. Some users, like me, have a battery capacity of 1160mAh which really suck(probably country/region specific), especially when running with the stock ROM from Sony. So I unlocked my bootloader flashed my kernel to Rage kernel v2.6, wipe all data and cache partitions and installed HYBROM v15 from CWM, so far so good. I installed No frills CPU Control but I'm having a hard time which CPU governor and I/O scheduler to choose. Some people say that I should choose SmartAssv2 and Noop, some say I should choose Conservative and Noop or SIO.
Installed Applications:
Angry Birds(RIO, Seasons, Space)
ASTRO File manager
AdFree
MapDroyd
Facebook(auto sync is OFF)
YouTube
Skype(auto sync is OFF)
oh, and BTW, I integrate these two apps via WinRAR which does not exist in HYBROM v15.
Google Maps
Google Search Widget
-Screen Brightness = 40%(I only set it to max when outdoors)
-Mobile Data network = OFF (using GSM only, I'm using WiFi for browsing, downloading and updating apps)
-AutoSync is off
-I only turn on WiFi when needed
No Frills CPU (My configuration):
Min:122Mhz
Max:1.024Ghz
Governor:SmartAssv2
I/O Scheduler:Noop
Apply on boot: checked
So my question is whats the best CPU Governor and I/O Scheduler combination for the Live with Walkman(assuming your using Rage kernel ang hybrom ROM) providing a balanced cpu performance and battery life for any casual user?
For your CPU config, I suggest increasing the minimum frequency to 320-480ish; because around that frequency it consumes more or less the same voltage. If you set it too low, you may end up using more power because your phone may struggle to process services (caused by low frequency). Reference here -it may be on another device forum but that's applicable on other phones-
IIRC smartassv2 will be defaulting to a low frequency when the phone's screen is off so I think it's good to use it, for your brightness it's ok but I use around 20-30% brightness when outdoors
thanks bro!
sir,
android noob question...
when you installed hybrom on the wt19i,
does the walkman button still work? and does it still have loudspeaker functionality?
im really hesistant in rooting or installing custom rom on mine...
thanks!
use either scary governor or ondemand and about the i/o bfq or sio.
buy a system tuner pro then config your startups and auto kill. mine is -1% / 4 hours deepsleep. min. 122Mhz - max. 1.5Ghz..
melander said:
sir,
android noob question...
when you installed hybrom on the wt19i,
does the walkman button still work? and does it still have loudspeaker functionality?
im really hesistant in rooting or installing custom rom on mine...
thanks!
Click to expand...
Click to collapse
walkman, and walkman button still works, and speakers are still loud and in stereo
and the bonus part, you get DSP manager, which enhances your sound and music experience further
xachiel said:
use either scary governor or ondemand and about the i/o bfq or sio.
buy a system tuner pro then config your startups and auto kill. mine is -1% / 4 hours deepsleep. min. 122Mhz - max. 1.5Ghz..
Click to expand...
Click to collapse
autokill?? I thought killing apps and processes is bad and since killed apps will restart again and will consume more battery life
kevincaja said:
autokill?? I thought killing apps and processes is bad and since killed apps will restart again and will consume more battery life
Click to expand...
Click to collapse
its a memory auto killer. not a task killer. and use gemini app to config auto-run your apps so they dont run at the background
kevincaja said:
walkman, and walkman button still works, and speakers are still loud and in stereo
and the bonus part, you get DSP manager, which enhances your sound and music experience further
Click to expand...
Click to collapse
thanks for the reply sir,
can you please share the steps you did to install the kernel and rom???
im really interested in installing a custom rom on mine...
melander said:
thanks for the reply sir,
can you please share the steps you did to install the kernel and rom???
im really interested in installing a custom rom on mine...
Click to expand...
Click to collapse
First, download all the necessary files:
this thread contains all the necessary files to unlock your bootloader, at the same time flash a custom kernel that contains ClockWorkMod(CWM) and root.
they also include download for the stock kernel with CMW and root but no overclocking, extra cpu governors and I/O scheduler features:
http://forum.xda-developers.com/showthread.php?t=1560613
if you want to overclock your phone, or improve battery life, download rage kernel:
http://forum.xda-developers.com/showthread.php?t=1398910
then download hybrom v15:
http://forum.xda-developers.com/showthread.php?t=1373435
well that's about it, be careful when flashing as you can easily brick your phone.
follow the instruction in the threads I've given to you.
You install custom ROMs via the ClockWorkMod, the only thing you flash via your computer is the kernel. In case your stuck in bootloop, you can always reflash to the stock ROM of sony ericsson.
Stock ROM for WT19i:
http://dl.dropbox.com/u/17122099/Sony Tools/WT19i_4.0.2.A.0.62__1254-1889.ftf
then flash it with flashtool or using the sofware on this thread.
NOTE:
-Rage kernel has a different way of entering in ClockWorkMod, turn your phone on. As it boots up, as soon you see the LED indicator turns blue or as soon as the boot logo brightens up, immediately press the home key to enter ClockWorkMod.
-in the stock kernel with CMW and root, the LED indicator is always off. Turn your phone on. Press the on-off key once or twice as soon as the b logo gets brighter, to enter in ClockWorkMod.
kevincaja said:
thanks bro!
Click to expand...
Click to collapse
I kinda disagree.If i remember correctly your phone has minimum frequency of 245 with stock kernel so why increasing?I use my mini with rage kernel at 122-1024 smartassV2 governor never had any problem.I use profile for screen off settings are 122-368.Battery consumption is 0.4-0.5% over night not in flight mode and cpu spy shows 99% of that time cpu is sitting on 122 MHz.So unless your phone is heavy loaded with apps that constantly require cpu power i recommend trying my settings and test over night, you got nothing to loose after all
kevincaja said:
First, download all the necessary files:
this thread contains all the necessary files to unlock your bootloader, at the same time flash a custom kernel that contains ClockWorkMod(CWM) and root.
they also include download for the stock kernel with CMW and root but no overclocking, extra cpu governors and I/O scheduler features:
http://forum.xda-developers.com/showthread.php?t=1560613
if you want to overclock your phone, or improve battery life, download rage kernel:
http://forum.xda-developers.com/showthread.php?t=1398910
then download hybrom v15:
http://forum.xda-developers.com/showthread.php?t=1373435
well that's about it, be careful when flashing as you can easily brick your phone.
follow the instruction in the threads I've given to you.
You install custom ROMs via the ClockWorkMod, the only thing you flash via your computer is the kernel. In case your stuck in bootloop, you can always reflash to the stock ROM of sony ericsson.
Stock ROM for WT19i:
http://dl.dropbox.com/u/17122099/Sony Tools/WT19i_4.0.2.A.0.62__1254-1889.ftf
then flash it with flashtool or using the sofware on this thread.
NOTE:
-Rage kernel has a different way of entering in ClockWorkMod, turn your phone on. As it boots up, as soon you see the LED indicator turns blue or as soon as the boot logo brightens up, immediately press the home key to enter ClockWorkMod.
-in the stock kernel with CMW and root, the LED indicator is always off. Turn your phone on. Press the on-off key once or twice as soon as the b logo gets brighter, to enter in ClockWorkMod.
Click to expand...
Click to collapse
Wow, thanks so much for the very detailed guide!
Will try it out now!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running Hybrom V15 now with Rage Kernel.
So far so good.
Now, how do I set the CPU frequency?
Kira.Lawliet said:
For your CPU config, I suggest increasing the minimum frequency to 320-480ish; because around that frequency it consumes more or less the same voltage. If you set it too low, you may end up using more power because your phone may struggle to process services (caused by low frequency). Reference here -it may be on another device forum but that's applicable on other phones-
IIRC smartassv2 will be defaulting to a low frequency when the phone's screen is off so I think it's good to use it, for your brightness it's ok but I use around 20-30% brightness when outdoors
Click to expand...
Click to collapse
I have had my minimum CPU frequency on 122 MHz for months, no problem. Phone sets the CPU frequency itself higher, when it needs more power. Putting minimum too low doesn't affect it.
T3sla said:
I kinda disagree.If i remember correctly your phone has minimum frequency of 245 with stock kernel so why increasing?I use my mini with rage kernel at 122-1024 smartassV2 governor never had any problem.I use profile for screen off settings are 122-368.Battery consumption is 0.4-0.5% over night not in flight mode and cpu spy shows 99% of that time cpu is sitting on 122 MHz.So unless your phone is heavy loaded with apps that constantly require cpu power i recommend trying my settings and test over night, you got nothing to loose after all
Click to expand...
Click to collapse
I have exactly same settings.
---------- Post added at 01:31 PM ---------- Previous post was at 01:18 PM ----------
xachiel said:
its a memory auto killer. not a task killer. and use gemini app to config auto-run your apps so they dont run at the background
Click to expand...
Click to collapse
Taskkillers/memoryautokillers etc are useless, even not recommended for Android. These close apps, that need to be running and when they start again, consume more battery.
Android is built self to kill apps, which are no longer needed in memory. It kills some apps, when free RAM amount reaches minfree level, amount of RAM that has to be always free.
If you want to improve RAM, better try out V6 Supercharger, link in my signature. It changes the minfree amounts to higher of lower, which one you want. Either multitasking, lowers minfree amount to allow more apps to work at one time, so you can access these easily, without the need of reopening. Or higher minfree amount, to keep more free RAM.
I personally have chosen Balanced.
Someguyfromhell said:
I have had my minimum CPU frequency on 122 MHz for months, no problem. Phone sets the CPU frequency itself higher, when it needs more power. Putting minimum too low doesn't affect it.
I have exactly same settings.
---------- Post added at 01:31 PM ---------- Previous post was at 01:18 PM ----------
Taskkillers/memoryautokillers etc are not useless, even not recommended for Android. These close apps, that need to be running and when they start again, consume more battery.
Android is built self to kill apps, which are no longer needed in memory. It kills some apps, when free RAM amount reaches minfree level, amount of RAM that has to be always free.
If you want to improve RAM, better try out V6 Supercharger, link in my signature. It changes the minfree amounts to higher of lower, which one you want. Either multitasking, lowers minfree amount to allow more apps to work at one time, so you can access these easily, without the need of reopening. Or higher minfree amount, to keep more free RAM.
I personally have chosen Balanced.
Click to expand...
Click to collapse
And i use V6supercharger too among others scriptsNext project undervolting.
Phone sets the CPU frequency itself higher, when it needs more power. Putting minimum too low doesn't affect it.
Click to expand...
Click to collapse
It does affect it in a little way; putting it up on low frequency -> phone will scale frequency according to needed -> what does it use to scale? -> uses abit of power to scale according to needed; so it's logical to why not set it to a mid frequency when it consumes the same volt therefore not wasting a bit energy to scale up or down when needed; of course' the number of your apps/running services affects this so it depends; you might hardly notice any change at all. It just that it's optimal but I'll not argue with this since we don't ran out of battery anyway on travelling eh?
-reference #1, #2 read more have fun testing
Kira.Lawliet said:
It does affect it in a little way; putting it up on low frequency -> phone will scale frequency according to needed -> what does it use to scale? -> uses abit of power to scale according to needed; so it's logical to why not set it to a mid frequency when it consumes the same volt therefore not wasting a bit energy to scale up or down when needed; of course' the number of your apps/running services affects this so it depends; you might hardly notice any change at all. It just that it's optimal but I'll not argue with this since we don't ran out of battery anyway on travelling eh?
-reference #1, #2 read more have fun testing
Click to expand...
Click to collapse
Yes but cpu power from my poor knowledge depends from frequency, so when you set a 3 times higher minimum frequency even if voltage is the same you'll have 3 times more power consumption when idle.I don't think that scaling cpu consumes more than 3 times powerBTW very interesting threads you provide us, did some reading so far and definitely gonna read the whole thing
melander said:
Wow, thanks so much for the very detailed guide!
Will try it out now!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running Hybrom V15 now with Rage Kernel.
So far so good.
Now, how do I set the CPU frequency?
Click to expand...
Click to collapse
you can download No Frills CPU Control in the Google Play Store(Market) for beginners, i suggest using SmartAssv2 for the CPU governor and Noop or SIO for the I/O Scheduler. as i remember, Noop or SIO provides the fastest throughput and best suitable for flash storage
here's the list of the advantages and disadvantages of those I/O Schedulers:
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Q. "How do i change I/O schedulers?"
Voltage Control or No Frills from market.
And here's the list and explanations for all CPU Governors for a custom android kernel:
These are the 18 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Smartass
8) SmartassV2
9) Intellidemand
10) Lazy
11) Lagfree
12) Lionheart
13) LionheartX
14) Brazilianwax
15) SavagedZen
16) Userspacce
17) Powersave
18) Performance
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
8) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
9) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
10) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
11) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
12) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
17) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
You can read all of these form this thread.
T3sla said:
I kinda disagree.If i remember correctly your phone has minimum frequency of 245 with stock kernel so why increasing?I use my mini with rage kernel at 122-1024 smartassV2 governor never had any problem.I use profile for screen off settings are 122-368.Battery consumption is 0.4-0.5% over night not in flight mode and cpu spy shows 99% of that time cpu is sitting on 122 MHz.So unless your phone is heavy loaded with apps that constantly require cpu power i recommend trying my settings and test over night, you got nothing to loose after all
Click to expand...
Click to collapse
kindly read this thread:
Q. "I'm going to set scaling min freq as 100 mhz because my kernel supports it. Hope there's nothing wrong in doing that."
A. Wait! You may want to stay away from using 100mhz during screen-off or screen-on states for three reasons 1) It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online. 2) 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon. 3) 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Ex: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
Someguyfromhell said:
I have had my minimum CPU frequency on 122 MHz for months, no problem. Phone sets the CPU frequency itself higher, when it needs more power. Putting minimum too low doesn't affect it.
I have exactly same settings.
---------- Post added at 01:31 PM ---------- Previous post was at 01:18 PM ----------
Taskkillers/memoryautokillers etc are useless, even not recommended for Android. These close apps, that need to be running and when they start again, consume more battery.
Android is built self to kill apps, which are no longer needed in memory. It kills some apps, when free RAM amount reaches minfree level, amount of RAM that has to be always free.
If you want to improve RAM, better try out V6 Supercharger, link in my signature. It changes the minfree amounts to higher of lower, which one you want. Either multitasking, lowers minfree amount to allow more apps to work at one time, so you can access these easily, without the need of reopening. Or higher minfree amount, to keep more free RAM.
I personally have chosen Balanced.
Click to expand...
Click to collapse
thanks for the link to V6 Supercharger, now my phone is lag free
Thank you again for the very detailed explanation...
Currently trying out your recommendations...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Revamped Advanced Interactive Governor Tweaks
This thread was originally made by Corndude which for some apparent reason, decided to delete his account. The task to update this thread is then passed on to @The Flash but unfortunately because the purple person is busy atm, I stole it from him. So I will try to keep this up to date with informations and everything about the interactive governor. I will also add helpful descriptions on each parameters just to help people who are into tweaking and give them a little push to start tinkering.
The original thread made by SoniCron can be found here: Advanced Interactive Governor Tweaks for the 5X
Helpful Links
Linux Documentation - CpuFreq
Most Up-to-date guide on CPU Governors by @Saber
Table of Contents
Download Section
Applications that Allow Kernel Profiles Setup
Diving Deep into Interactive Governor
Interactive Tweaks Explained
timer_slack: The amount of time in miliseconds; that the cpu will stay in the highest frequency before it applies "interactive" tunings again. Basically, if there is a cpu intensive application and you have a high cpu load; timer_slack delays ramping down to lower frequencies in a given "X" time. Also, since timer_rate will be erratic, this should help to decrease stutters.
(higher value: higher battery drain, better performance)
timer_rate: The amount of time in miliseconds; that the cpu will check how heavy the cpu load is. E.g. if you have set this to 20000, it'll compute every 20ms to see if any changes on the cpu load is making and will therefore adjust the frequency based on target_loads.
(higher value: less battery drain, performance impact subjective)
target_loads: The amount of load, in theory on percentage; where the actual frequency should be used. Target_loads can be setup per frequency to provide certain "bias" on cpu clocks. An example "35 475600:88 600000:21 960000:98" means that anything before 475Mhz would have a target load of 35%. At 475Mhz before ramping up there should be at least 88% of cpu load, once this threshold is broken it'll ramp up to 960Mhz immediately since 600Mhz is set less than 475Mhz. Therefore the two "bias" created on the sample above is 475Mhz and 960Mhz. It is not recommended to provide any values higher than 98 as this will reduce performance on your cat greatly.
(higher value: less battery drain, worse performance)
min_sample_time: The minimum amount of time the governor must wait at a given frequency until it can decide to reduce the frequency.
(higher value: better performance, battery impact HIGHLY subjective)
hispeed_freq: This would be the frequency that the user "assumes" would be enough to handle a boost in cpu load. Too high value would greatly impact the user's UI performance but would definitely worsen the battery life.
(higher value: higher battery drain, better performance)
go_hispeed_load: The load assigned to the cpu where it is recommended to go to the hispeed_freq. Set this quite high as this bypass almost everything in the interactive tunables.
(higher value: less battery drain, performance impact subjective)
above_hispeed_delay: A delay setup in frequency:miliseconds to slow down and "delay" aggressive ramp ups. E.g. 19000 600000:24000; provides 19ms delay to cpu frequencies not specified after reaching hispeed_frequency, before ramping up to a higher frequency. If, for example you have your hispeed_frequency set up to 960Mhz, and your above hispeed_delay to 30000 1248000:22000 1354000:40000; the 30ms will only be used at 960Mhz up until 1248Mhz where the delay is 22000. Please note that 30000(30ms) from the example above will NOT BE APPLIED to all frequencies BELOW the set hispeed_frequency (anything below 960Mhz). Also, specified "frequency:delay" ratios should be written in ascending order according to cpufreq linux documentations.
(higher value: less battery drain, worse performance)
align_windows: With the value of "1" for On and "0" for Off. If "1" is designated, the cluster for cpu clocks (divided into big and little) will fire at short quick intervals, usually by 1ms to provide a reliable boost to what timer_rate has converted cpu loads/clocks into.
(If ON: better performance)
max_freq_hysteresis: Checks the cpu for "hysteresis" or previous cpu clock records and base the next ramp up on frequencies previously used. If your cpu tends to have a bias towards lower cpu clocks, with this on a high value; it should frequently stick to lower cpu frequencies.
(higher value: less battery drain, performance impact subjective)
powersave_bias: Value of "1" to turn ON and "0" for OFF. If your cpu decides to go for 960mhz, with powersave_bias ON it'll go to a frequency one step below 960mhz.
(turn ON: less battery drain, worse performance)
use_migration_notif: Value of "1" for ON and "0" for OFF. Reevaluate the cpu frequency if "notified" (unclear, we can assume this as either an unschedule app notification or a "timed" boost) to fire in 1ms. This aids timer_rate in quick changes with system loads.
(turn ON: better performance, battery impact subjective)
ignore_hispeed_on_notif: Value of "1" for ON and "0" for OFF. Ignores the hispeed_load, hispeed_frequency and above_hispeed_delay once a cpu is "notified". Therefore, if a cpu is "notified" if this is set to "1" the cpu can ramp up to frequencies computed by timer_rate without any delays coming from hispeed frequency logic.
(turn ON: heavy battery drain)
fast_ramp_down: Value of "1" for ON and "0" for OFF. Ignores min_sample_time which provides delay on cpu frequencies in miliseconds. This holds true ONLY if a cpu is "notified" and therefore avoids unreliable "bias" on certain clocks due to quick shift of cpu loads.
(turn ON: less battery drain, performance impact HIGHLY subjective)
I highly encourage people to tweak their interactive governors on their respective kernels as this highly amounts to bettery performance and battery life. With that said, this concludes a simple revamp of this thread and I hope more and more people within the angler community would be interested to tinker. Imagine the possibilities!
CREDITS TO:
@The Flash - for letting me steal his thread because he slow af.
@soniCron - the main contributor for all of this, I don't know if he still exists.
Corndude - dude
@shadowstep - for being a good friend though he "mistakenly" killed his angler *retarded screeching*
@Saber - for providing the Most-up-to-date CPU frequency guide
@frap129 - for being really awesome and providing the community fraps.
And to EVERYONE that has made all this possible, I give the sun to you!
Download Links
Profile Download Links
Profiles by Alcolawl from @Alcolawl[/b]
[*]Profiles by Xsilas43 from @Xsilas43[/b]
[*]Profiles by .hEimDaLL from @.hEimDaLL
[*]Wingoku Profile from @fapste
[*]GlassCannon from @phantom146
[*]EXkm Profiles from @xperator
[*]Project Zhana OP3 Port from @deani77
Apps that Allows Kernel Profile Setups
Apps that Allows Profile Setups
Exkernel Manager App by @flar2
Spectrum Kernel Manager by @frap129
Kernel Profiler by @frap129
Diving Deep into Interactive Governor
Diving Deep into the Interactive WorldUnderstanding how parameters co-exist and the OP's viewpoint regarding cpufreq.
The interactive governor has been around for years and is without a doubt the most popular cpugov present in the linux archives. The development of this linux-based core has been ongoing, patches and evolutions to interactivex has been widely appreciated by android enthusiasts and non-enthusiasts alike. Interactive governor is also without a doubt, the majority baseline for new governors being developed which goes to prove that it is one of the most efficient and optimal cpugov within the world of android fanboys.
Before we start, take a look at this graphic thingy:
There is no such thing as a "perfect" balance. I myself, live by a code to never ever let my phone slow down just for the sake of bragging that I got this SoT *autistic screeching*. If you have to choose between the two of those, I would wholeheartedly suggest to finish tasks first (yielding better performance) than just idle in despair looking at your battery percentage the whole day. Lastly, please do bring a powerbank with you.
Enough with this, let's talk facts:
I will be breaking down the parameters here, how they should co-exist with other parameters and what you should change in order to provide a smoother experience. We will also be digging deeper as to how each parameters should help you with your daily usage. Let's begin.
Hispeed_Frequency Logic:
The hispeed logic is what makes your angler boost, not gradually; but burst through the set optimal load you deemed necessary for task completion. We consider this very important as this provide the overall smoothness, task completion time and if used properly along with other parameters; may yield to better battery.
hispeed_frequency: This is the bread and butter of the interactive governor. What makes interactive unique to others is the user can set a specific frequency "bias", where he/she finds it optimal(according to usage). When paired with input_boost, this significantly increases responsiveness and smoothness to overall android feel. Personally, I would never recommend to set hispeed_frequency to the lowest cpu clock e.g. 384mhz because it will defeat its purpose of "burst" boosts. In the past, many users attempted to set hispeed_frequency to the lowest clock to prevent sudden scaling from cpu frequencies however, in turn, they have to sacrifice the responsiveness of the device A LOT. If you want to still try it, I'll bet my scrotums again that switching between apps and opening your angler coming from deep sleep/doze without a fingerprint_boost (featured in Flash kernel and Electron) would stutter and cause you to at least lag for a second.
From tests, my best recommendations for a hispeed_frequency are:
600/634mhz - If you are a typical light user, opens your device to read a lot of stuffs about growing back your pubes and ruining the timeline, like barry. Whenever you are switching from a light app (reddit, 9gag, fb) to a heavy app such as Youtube, you should experience a slight stutter but you could still live.
960mhz - Good enough to balance almost everything. From light users to heavy users, this should be optimal. Personally never experienced jitters coming from hispeed_frequenciy set to this (except with really low timer_rate).
1248mhz - Fast and extremely reliable but unfortunately should give you a little more drain. On the flipside tho, it is the default input_boost/hispeed_freq from interactive itself as well as other variations of the governor. If you use heavy apps a lot such as games and likes switching stuffs a lot, stick to this.
Anything above 1248mhz I would really not recommend. Coming from personal tests, It does run phenomenal but it is too much of a waste. That performance isn't worth the battery expended so with all due respect just stick to a lower frequency.
go_hispeed_load: Provides the desired load from 0-X depending on the user's preference. This bypasses your set target loads from below your hispeed frequency e.g. if your hispeed_freq is set to 960 mhz, anything under 960 mhz is bypassed whenever the "assigned" load threshold you input in this parameter is reached. Meaning, even if you set 302mhz as 999 on your target loads, whenever your timer_rate computes a load that has at least reached to your assigned go_hispeed_load it should automatically ramp up to your hispeed_frequency. However, this does not mean you can abuse the power of your target_load. Setting your target_load too high below your hispeed_freq would still give you lags especially if your timer_rate is above 50000. Just a tip: you can make this to 0 if your input_boost is set to your hispeed_freq.
input_boost: Technically not part of the interactive parameters but still worth the mention as this copies the hispeed_frequency logic and helps maintaining boosts. The input_boosts increases your frequency to the assigned value whenever a task is loaded in your device. This does not work like touchboost as touchboost is a nuclear waiting to explode. Input_boosts scales even if your screen is off (but rarely) and wouldn't increase your phone's clocks whenever you touch it (boop boop). Rather, it only boosts your device whenever necessary (e.g. IO overheads, task completion, downloads, alarms syncing).
If you really like the most optimal performance your cat can achieve, aim to put input_boost the same as your hispeed_frequency values'. It should not waste too much battery and should still be controlled by above_hispeed_delay.
Controlling your Hispeed_Frequency:
There are only two parameters that can actually control your hispeed_frequency scaling namely go_hispeed_load (mentioned above) and above_hispeed_delay. However, a third one which is quite special; ignore_hispeed_on_notif can also impact at how the governor performs, let's dig in to it:
above_hispeed_delay: Is a "delay" timer in miliseconds set by the user with the format "Initial delay, frequency:delay miliseconds". The intiial delay is applied to all frequencies EQUAL TO OR ABOVE the hispeed_frequency, whilst the frequency:delay ratio is applied per specific frequencies again EQUAL TO OR ABOVE the set hispeed_freq. E.g. if you set your hispeed_frequency to 960mhz, and you have set your above_hispeed_delay to (X 384000:Y 600000:Z 960000:M), Your X value would be aligned to all frequencies above 960mhz (since you specified a delay in 960mhz) whilst your Y and Z is IGNORED, because you're retarded short-sighted enough to not read what I and the linux archives just said.
I personally, do not recommend hispeed_delay to be above 35000 unless you're eager to "suspend" or provide "bias" on a specific frequency. This is because I find 35000 and anything above that to be too long for a delay and should provide you nothing but lags and would just piss you off instead of providing a better battery. If you do want to suspend a cpu clock make sure that it is efficient enough (e.g. 1248mhz or above) to handle heavy loads.
ignore_hispeed_on_notif: Turn on by input of "1" and must have use_migration_notif to "1" also otherwise it won't work. The ignore_hispeed_on_notif (damn that's long) as the name puts it; ignores the hispeed logic, meaning your above_hispeed_delay and go_hispeed_load is ignored whenever the hrtimer (a special timer) coming from use_migration_notif triggers. This usually yields better performance but at the cost of a huge battery drain, since hrtimers also trigger on deep sleep, therefore; most likely, your cpu would scale up even though you think there's no task happening in the background. I do not recommend turning this on, please do not, you kennot.
The Caviar of Target Loads:
The most sought to parameter in the interactive kernel is the target_loads. Along with hispeed_frequency, target_loads is another parameter that makes the interactive governor the most flexible, controllable and probably battery-friendly cpugov. You can adjust this to function as a performance-like governor, a powersave or even imitate how conservative governor gradualy boosts. Below, you will see tons of explanations and what criticisms I personally got about target_loads:
target_loads: Computes the load per frequency ratio, in the format of "X 600000:Y 960000:Z" and so on, depending on the users' perceptive usage. Where X, is the initial load given to all frequencies below the first specified frequency:ratio stated (therefore in the example, anything below 600mhz), and Y/Z are loads given to specific cpu clocks. The target_loads unlike above_hispeed_delay, isn't linear. You can start off with a high frequency ratio of 384000:88 then go down to 487600:22 and get back up to 90 at 600mhz. Because of the latter, you can provide "bias" on certain frequencies you deem to be fast enough to handle specific loads.
Just a heads-up. I do not believe in optimal and nominal frequencies. I think those were just bullshified terms that was made so people would have something to bias the loads to. The optimal frequency should be your "preferred" frequency. There is no 960mhz when watching youtube nor the specific frequency for just reading webpages at 600mhz. There are certain apps that are relies on heavy foreground (e.g. whatsapp and snapchat) or sometimes even fb, and if you're gonna stick to 600mhz because somebody told you its the optimal frequency for users that just reads, you can kiss my grandma. Everything differs, a good android enthusiast should and will explore what frequency they think their usage fits. It's just that simple.
Before trying to input random numbers on your target load, try to see what your perceptive usage is. If you would like your device to stay on lower frequencies as much as possible, put a value between 75-92 on clocks below your hispeed_frequency. Anything above that might lead to stutters depending on your min_sample_time and timer_rate.
Provide higher load thresholds on your hispeed_frequency and above. Since you have set your hispeed_freq to be the most optimal cpu clock all-around your dynamic loads, provide a higher threshold to it (e.g. 90 and above) so your kernel will bias to it more unless heavy loads are on play.
Put a value of 98-99 to frequencies you deem to be the most efficient on heavy loads. I personally like 1248mhz a lot and therefore use it as my cpufreq for heavy loads. Setting your load to 99, rarely makes your frequency go higher than the specified cpu clock, whilst setting it to 98 is decent enough to gradually let frequencies ramp up from it.
An important note. You can create certain "bias" towards cpu clocks as I have stated above, target_loads aren't linear and therefore, frequencies you deemed to be slow enough to handle cpu stressmay be given less priority. This is done by providing any loads below 50. E.g. 384000:75 487600:22 600000:88 672000:35 960000:95 by using the example given, your cpu clocks should bias towards 384mhz, 600mhz and 960mhz respectedly, eliminating the need for 487mhz and 672mhz. We do this to provide better responsiveness for our cats and I personally recommend trying this until you find your sweet spot.
Providing the Delays of Responsiveness:
Delays aren't only used to slow down the ramp up of your cpu clocks. They are also used to delay things such as the given time of each cpu frequencies before ramping down. Because of this control, the interactive governor provides a better all-around smoothness than any other governors out there, combined with your target_loads and hispeed_frequency; fluidity should never be an issue!
min_sample_time: If above_hispeed_delay provides a delay before the cpu scales up, min_sample_time is the other way around. Min_sample_time is a timer in miliseconds with X0000 format, used as a delay for all cpu clocks per cluster, before it ramps down, assisted by computations coming from timer_rate. As one of the core parameters in android to provide fluidity universally, this parameter could be swapped for input_boost delay and providing a higher timer for this with lower timer_rate, in my own experience; provides you the capability to totally negate input_boost.
Experiment on this one as this is very subjective. I do suggest that if you have a high timer_rate , provide a higher min_sample_time value or else your kernel won't be as responsive as you would like it to be.
timer_slack: to assist timer_rate to provide a stable and constant performance track, timer_slack in miliseconds, provides a delay on the highest frequency of the governor. Because timer_rate especially if below 40000, computes the frequency of the current load given to the cores, min_sample_time aids to slow down timer_rate's aggressive approach to either ramp up/ramp down the frequency. An example of this is moving to another app from one foreground to another, if timer_rate has been set low enough that it computes the switching to provide a higher frequency then within 20ms to ramp down because the load has settled down, timer_slack prevents this from happening, and thus should create responsiveness to our devices. This again is highly subjective. Play on its values depending on your needs, most developers or interactive enthusiasts use -1 to prevent timer_slack from delaying the high frequency which provides a better battery life.
Underrated Parameter; the Timer Rate:
timer_rate: is probably the most undervalued and underrated parameter there is in the interactive governor. Most governors have this parameter and is rarely, I mean rarely! appreciated. You have to change that notion starting now. Timer_rate provides things two ways. Lower value equates to faster response and performance while higher value provides longer battery life. Of course the latter means you'll be sacrificing your device's fluidity.
The default timer_rate is 20000. This means that every 20ms, your governor will compute the loads burdened to your kernel and timer_rate will provide the signals to target_loads to adjust depending on the values given.
An "efficient" timer_rate clocks in between 20000 and 40000. By my own tests, anything above 40000 slows down the "frequent" change of cpu clocks. As a proof, you can check your kernel manager's dashboard and set your timer_rate higher than 40000; you will notice that it won't be jumping from one frequency to another too much.
A high timer_rate could still be efficient given that you have a high min_sample_time and a reasonable timer_slack. This three holy trinity, when tweaked properly, should give you better performance without the significant drop of battery life for our angler.
The Special Parameters:
There's a (3)three parameters that I would like to call special. This is because they can be turned off and wouldn't cause any significant changes to the interactive governor and from the fact that they need use_migration_notif turned ON to function. Also, just a quick mention, during my long tests; I find some of these parameters intrusive so I wouldn't really recommend them turned ON unless you are willing to experiment on things.
use_migration_notif: can be turned on with the value of "1". This is the core switch for fast_ramp_down and ignore_hispeed_on_notif (please see hispeed logic for description) to work. With this on, migration timers also known as hrtimers (see Hrtimers - Linux Archive for spot-on description) are allowed to be computed as a "load". This can be comparable to ignore_nice_load from other governors however, unlike the latter, use_migration_notif needs to be turned on to work. To summarize, with hrtimers computed as loads, this should provide more gradual boosting than before, especially that hrtimers for linux kernels are made to "optimize timer-wheel" but the battery impact is highly subjective. Also, hrtimers may fire while on deepsleep, though it won't break doze, this would increase your cpu frequency as it is computed as a positive load from your kernel and should therefore drain a little more battery, especially when you have ignore_hispeed_on_notif set to 1.
fast_ramp_down: can be turned on by setting value to "1". This simply ignores min_sample_time for hrtimers and therefore should provide you better battery life. Whenever your cpu clocks ramps up due to hrtimer, min_sample_time would delay the cpu frequency before going down but with fast_ramp_down if the load computed by your kernel is indeed an hrtimer, it'll ignore min_sample_time value and proceed to ramp down the frequency in 1ms.
Turning the three: use_migration_notif, ignore_hispeed_on_notif and fast_ramp_down ON is something that I would never recommend, unless you're experimenting, doing your own tweaks or holding on to your dear life. There is no way we can accurately measure this three unlike the other parameters provided, also; hrtimers are being patched from one kernel to another and is being updated constantly, I am pretty sure in the future we would be taking advantage on that parameter soon.
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Second this. Been following on the 5x page as well and was using Ghostpepper until earlier today. For me ghostpepper got me the best SoT(5hrs)with average usage (mainly whatsapp, Facebook mobile site, instagram, Spotify and some GPS usage with it on high accuracy). Now using Butterfly and so far performance is outstanding, excited to see what the battery life will be. Huge thanks to @soniCron for the work!
moraytadroidz said:
This is great, I've been following this work in the Nexus 5X forum and I've got to say this is a great way to fine tune and optimize our 6P.
Edit. I'm currently on the maddog profile and experiencing excellent performance and superb batter life, 630 sot avr.
Click to expand...
Click to collapse
Any info on what is the best for battery life? Don't really care about performance, it's fine on stock imo. So far I have not noticed any difference in battery life between this and stock.
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Alcolawl said:
Glad there is a separate thread for these tweaks on the Nexus 6P. I'll continue to update that post with the newest scripts for this device, but always remember that I CANNOT test the scripts for the Nexus 6P because ai simply don't own the phone. Progress and updating scripts will heavily rely on testing and feedback from participants in this thread. This is paramount, as its difficult to maintain scripts for a device I don'tactually have access to. Please make sure to either mention me or PM me when giving feedback on the scripts I've uploaded.
Thanks again, @Corndude!
Click to expand...
Click to collapse
Thank you. Glad to have you checking on this thread as well!
I'm not sure it's necessary to copy the text to each of the posts verbatim... I'd suggest linking to the original posts and then add on 6P-specific info (such as frequency ranges, voltage levels, etc) so as to not overwhelm your users. (I also recommend this because the OP guide on the 5X forum is going to get a full rewrite incorporating everything we've learned thus far, sooner than later.)
I have no problem with you duplicating the text, mind you. I just think it might be better for your users if you linked rather than duplicated. (Especially if it's not updated with the 6P in mind.)
I'll try to keep track of this thread for a while, but if anyone urgently wants my attention, PM me.
Great work, guys!
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Franco works just as well. It's only important that you can disable touchboost.
shawnaye said:
For Butterfly and Ghostpepper, is there settings for franco kernel? Or must I use the respective kernels necessary.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
+1 on thread! Test it yourself.. I've had great success on GhostPepper.
Evolution101 said:
So far people are mainly using it on Elemental X and Kylo. Butterfly has been working great for me on Elemental
Click to expand...
Click to collapse
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
nadiros said:
I must have my wires crossed. Thought I read that Butterfly required Kylo kernel as ElementalX has no Intellactive governor?
Click to expand...
Click to collapse
I think you might be thinking of the Redhawk alpha. Butterfly is for the interactive governor
Gytole said:
I use franco on Pure Nexus, and under the franco app I turn the performance to power saving. No hiccups or lag on anytjing I do and I score 7+ hours SOT every charge
Click to expand...
Click to collapse
Really ? Gonna give that a go!
Thanks for starting this thread
I'm finding ghoststepper to be very smooth - butterfly was certainly a sipper but slightly less smooth for me I think.
@Corndude Glad to see this here, too - I've been following the OP on the N5X forum since soniCron posted it.
One suggestion: maybe put "[WIP]" or "Work In Progress" at the start of the thread title as I know the 6P is having less than desirable results in comparison to the huge benefits they're seeing on the 5X & it would be a shame if people were put off by bad reviews/comments of the tweaks before we (as a community) can stabilise the settings to give great battery life without affecting the performance at all.
I know GhostPepper is very close to getting there (6.5-7.25 hrs SOT for me), but I still think we can squeeze much more out of this theory - I mean, we have a much larger battery with the same software specs, so we should technically be able so squeeze at least another 1/2 hours SOT out of the 6P if 5X users can get 8/9hrs SOT.
ps. just a heads up - your "head on down to the 2nd post" in the OP links to the 5X OP & the OP also includes 5X frequencies - these should probably be swapped out of the 6P frequencies, otherwise people might try inputting them to their 6P's (which will result in target_loads not saving)
edit: 6P Maximal/Minimal loads for OP.
CPU #1 Maximal Efficient Loads
384000:75
460000:69
600000:80
672000:79
768000:80
864000:81
960000:69
1248000:84
1344000:82
1478000:86
1555000:0
CPU #1 Minimal Efficient Loads
460000:20
600000:30
672000:12
768000:14
864000:13
960000:11
1248000:30
1344000:8
1478000:10
1555000:5
CPU #2 Maximal Efficient Loads
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:84
1344000:84
1440000:84
1536000:85
1632000:85
1728000:85
1824000:84
CPU #2 Minimal Efficient Loads
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1728000:6
1824000:6
1958000:7