[UPDATED 05/08/17] Advanced Interactive Governor Tweaks by SoniCron - Angler thread

Which one do you prefer?

  • Total voters
  • Poll closed .


Senior Member
Apr 30, 2015

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

Table of Contents

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!


  • @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!
Last edited:


Senior Member
Apr 30, 2015
Diving Deep into Interactive Governor

Diving Deep into the Interactive World
Understanding 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.

Last edited:


Senior Member
Oct 20, 2014
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.
Last edited:
Dec 30, 2015
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!

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.


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.


Senior Member
Jul 21, 2012
New York
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!


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!
Thank you. Glad to have you checking on this thread as well!


Senior Member
Jun 1, 2014
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!


Senior Member
Sep 28, 2011
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


Senior Member
Aug 7, 2013
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
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


Senior Member
Jul 22, 2010
Hampshire, England
@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

CPU #1 Minimal Efficient Loads


CPU #2 Maximal Efficient Loads


CPU #2 Minimal Efficient Loads

Last edited: