[Nexus 6P General] phantom146:
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:​

[IMG="This is a secret message: message says, SWIGGITY SWOOT"]http://i.imgur.com/meH5ZOe.png[/IMG]

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.