• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Which one do you prefer?


  • Total voters
    15
  • Poll closed .
Search This thread

phantom146

Senior Member
Apr 30, 2015
1,081
1,127
Malabon
xi5pjqu.png

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!

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

phantom146

Senior Member
Apr 30, 2015
1,081
1,127
Malabon
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:​

meH5ZOe.png


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:

moraytadroidz

Senior Member
Oct 20, 2014
57
35
Manila
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
27
5
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.
 
C

Corndude

Guest
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.
 

Alcolawl

Senior Member
Jul 21, 2012
1,398
2,278
New York
Google Pixel 4
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!
 
C

Corndude

Guest
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!
 

soniCron

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

shawnaye

Senior Member
Sep 28, 2011
1,477
454
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
 
C

Corndude

Guest
Franco works just as well. It's only important that you can disable touchboost.
 

Gytole

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

Jsilver73

Senior Member
Nov 5, 2013
3,144
2,345
48
Christchurch UK
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.
 
Last edited:
  • Like
Reactions: abbz123

DanielF50

Senior Member
Jul 22, 2010
458
206
Hampshire, England
Google Pixel 6 Pro
@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
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 112
    I've created some personal ( EXKM ) profiles and I thought I'd share with you

    DeadPool: The next version of BlackPepperV2. You know how it's gonna be

    Saber V2: Designed to work without InputBoost. Mostly no lags/heat issues. Suitable for heavy texting users. Probably not good for gaming. Based on DeusEx family.

    ReZero: Very simple profile like Stock، but optimized in many ways for better battery life and smoother experience.

    DeusEx: Based on AmaneunsisOne and BlackPepper. If you like BlackPepper make sure to try this. Thanks to Juzman
    DeusEx Revolution: a bit different than the original. More performance oriented. Great for gaming. Almost no lags.

    DragonFly : A profile based on DarkSpice7.5 and EclipseR3. It's similar to Butterfly profile meaning its aimed for performance and responsiveness but its snappier and faster than Butterfly. It jumps to mid frequencies all the time even for small tasks.
    You shouldn't expect great battery life! Even though It should be more battery friendly than Butterfly. I get a minimum of 5hours SOT with this.

    Excalibur: Based on DragonFly and GhostPepper. It's almost fast as DragonFly and it has great battery life. 0℅ idle drain on wifi/normal signal reception. And if you dont know what Excalibur is, shame on you and watch this, not just the clip, get to watch the whole anime after cause it's epic :good:

    BlackPepper: Based on GhostPepper. Designed for battery life without compromising performance too much. Expect many many SOT hours. If you liked Ghostpepper's battery life, you will probably like this even more.

    Just give them a shot and tell me what you think.

    Instructions:
    Install Ex Kernel Manager app. Then move the files to /sdcard/ElementalX/gov_profile and rename to remove ".txt"
    If you don't have the app and want to run the profiles through terminal get the ".sh" variety.

    Other tweaks/values you might want consider:
    Use Kylo or Ninja kernel.
    Sioplus for i/o scheduler
    Don't use FB app, use browser or alternative client apps
    For more see my full guide at this link
    65
    NOTE: Please re-download the .txt file below and re-apply. I've missed writing the timer_slack for big cluster and the big cluster's input_boost frequency doesn't stick. This should fix that! Thank you!
    Introducing GlassCannon!

    Description: A sound modification to the famous interactive parameters. Provides the smoothest interface, great performance while bestowing the lowest frequencies available. Ramping up quickly to maximize "inputs" from I/O overheads then immediately ramping down once tasks are done. The perfect balance between lowering down your frequency, and finishing up tasks quickly.

    Why Glasscannon? Why not?

    Who am I? I came from the hammerhead scene. I have been modding interactive parameters for more than 2 years and owns a community called: Android Battery Community whom has its own fair share of followers but has been quite stagnant for almost a year ever since my hammerhead broke. Though, I have been tweaking things with other devices; LG G4, Samsung Note 6, OPO and other smartphones that I got my hands on. Now I think it's time for me to get into the Nexus 6P scene.

    The difference? After years of being a paranoid about my battery (literally looking at dashboards, cpu cycles etc. you know, that guy who just tends to not be satisfied about everything) I finally settled down and read a lot of things and made it as my basis. Most tweaks in here uses target load as an optimal way to force cores to stick into lower frequencies but we won't be doing that with GlassCannon. We will be using two underrated tunables: above_hispeed_delay and input_boost. This two underrated tunables are being neglected for years, though some used it quite efficiently; I have yet to see a tweak that maximizes the two tunable's potential. We would be using above_hispeed_delay as a substitute to the unpredictable target_load. Instead of assigning too much within a tunable that we can't even lay our finger on how it works properly, why not let the SoC handle it and assign a delay along with timer_rate so it can run efficiently? And let input_boost jump up here and there to provide quick surge whenever there are tasks running under the hood.

    Look under:

    Code:
    [COLOR="Gray"]/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor interactive
    /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 384000
    /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1555200
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 93
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0  600000:19000 672000:20000 960000:24000 1248000:38000
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 50000
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 600000
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 380000
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 29 384000:88 600000:90 672000:92 960000:93 1248000:98
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 60000
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
    /sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
    /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor interactive
    /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq 384000
    /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq 1824000
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load 150
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay 20000 960000:40000 1248000:30000
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate 60000
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq 960000
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads 98
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time 60000
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/boost 0
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/align_windows 1
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif 1
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_sched_load 0
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 0
    /sys/devices/system/cpu/cpu4/cpufreq/interactive/boostpulse_duration 0
    /sys/module/cpu_boost/parameters/input_boost_freq 0:600000 1:600000 2:600000 3:600000 4:960000 5:960000 6:960000 7:960000
    /sys/module/cpu_boost/parameters/sync_threshold 1248000
    /sys/module/cpu_boost/parameters/boost_ms 40
    /sys/module/cpu_boost/parameters/migration_load_threshold 15
    /sys/module/cpu_boost/parameters/load_based_syncs Y
    /sys/module/cpu_boost/parameters/shed_boost_on_input N
    /sys/module/cpu_boost/parameters/input_boost_ms 300
    /sys/module/cpu_boost/parameters/input_boost_enabled 1
    /sys/module/msm_performance/parameters/touchboost 0
    /sys/module/msm_thermal/core_control/enabled 0
    /sys/module/msm_thermal/parameters/enabled Y[/COLOR]

    Explanation:
    go_hispeed_load: Anything between 85-94 is average by my tests, it tends to stick to hispeed_load 40-60 which is what I think would be "optimal" for our cat.
    above_hispeed_delay: The most important part of our tweak along with input_boost. This should set up the perfect "delay" so cpu cores could adjust and decide before ramping up to higher frequencies. Our frequency set as hispeed from little cluster is 600000.
    target_loads: We won't be dwelling much in this. We put a small amount so that our frequency could ramp up if needed and take a pause on frequencies we deemed to be really significant; 600mhz, 672mhz, 960mhz and 12348mhz. Along with hispeed_delay, it should provide low consumption and tend to stick on 384mhz and 600mhz 89% of the time.
    timer_slack: Put it to 380000, just trust me.
    max_freq_hysteresis: Asking why theres jitters and a bit of stuttering on your screen? this is the culprit. Turn it to 0 and you will be fine as long as you correct the other tunables. This is because hysteresis actually uses "former" frequencies to calculate which frequency would be best to ramp up to next. If you tend to stick to lower frequencies more, with this on then you will be sticking at low frequencies almost forever, which obviously isn't something good.
    input_boost: Now, to explain why this is important; there are two things I would like to emphasize. (1) One, this value was made so that under the hood tasks as well as simple bumps to your frequency if there is a notification, sync etc. would be possible. (2) this value is extremely useful to provide that quick boost to complete tasks with ease. The big clusters would have an input_boost of 633000 which was supposed to be the stock mhz. Why? I deemed that the big cluster isn't that necessary unless you are running an extremely graphic heavy game. So tone it down to 384mhz underclocking it and provide input boost to the mhz that was supposed to be the stock frequency, increasing battery life without sacrificing anything.

    Will this be updated? NO, NEVER. I am asking myself why does this other "tweaks" update from time to time if there are no kernel parameters that are changing? Aren't all those tweaks supposed to be tested hundreds of times before releasing? Then why change the parameters again? Am I asking too much? Am I fat? NO. Just NO. EXCEPT if there will be changes within the interactive parameters then sure.

    Credits: @soniCron, @xSilas43, @shadowstep for pointing out the missing timer_slack and input_boost, google for many things to read, this website for music while typing, that website for providing me more things to read, a bucket of fries and two chickens to make me company.

    Go ahead and feel free to download the .txt file below and happy tweaking!
    65
    [PROFILE]ÆSIR Governor Tweaks by .HEIMDALL. (2016/02/27)

    ÆSIR Governor Tweaks by .HEIMDALL.
    This profile is was based on DarkSpice by @xSilas43, the excellent guide by @soniCron, the work of @Alcolawl, @flar2, @Corndude and all the others I forgot to mention

    SYNOPSIS

    This post needs an update (planned for 2016/03/01).
    Update delayed. Quite busy atm.

    Please be patient. All information you need is noted below!


    These profiles are made to be very battery friendly with great responsiveness/snappyness!
    They are originally for the Nexus 6P, but there is a 5X Version available, too. I can't guarantee it performs the same as on the 6P, because I don't own that device to test it.
    So I'm relying on your feedback there.

    HEIMDALL: interactive / interactive
    VIDAR: interactive / elementalx
    LOKI: elementalx / interactive

    Some stats: (HEIMDALL v3 - outdated since 27.02.2016
    battery friendly and snappy
    Idle: 384/384
    Input Boost: 600MHz (Cluster 1) 40ms
    Music Playback: average @ 384/384 (tested in Amazon Prime Music and PowerAmp with V4A enabled)
    YouTube Playback: average @ 600-672/384
    Moderate Scrolling: average @ 600-672 (tested in Tapatalk, NovaLauncher, Xposed installer, GMail)
    Typing: average @ 600-672/384 (tested in WhatsApp, AOSP Messaging, Google Messaging)

    Detailed comparison-table (Stock, HEIMDALL v3, GhostPepper 1.1, DarkSpiceR7.5, ButterFly):
    comparison.png
    (based on my personal usage habits - yours might differ!)

    Why yet-another-other-... governor profile!?
    Yeah, you are right, why another one? There are already a few really good ones out there. I used GhostPepper for a long time and switched to DarkSpice some time ago.
    Both were nearly perfect for my usage pattern and I got good SOT times and performance (I preferred DarkSpice a little). Well, "nearly perfect" isn't "perfect" you might say, and that's why I tried to optimize the profiles to fit my (personal) needs.

    But what about speeeeed?!
    Those profiles should be very responsive without compromising your battery life too much. But I'd suggest you just try it...
    ;)

    SUPPORTED DEVICES
    I wrote this profiles for the Nexus 6P (SnapDragon™ 810) - tested with PureNexus and ElementalX Kernel.
    A version for the Nexus 5X (SnapDragon™ 808) is available since v2. I tried to keep it as close as possible to my original 6P profile, but giving attention to the HexaCore Design of the 808.
    I can't test the 5X Version because I don't own that device. I'm relying on your feedback for that device.
    This should probably work on other devices with the same SoC (SnapDragon™ 810/808), as long as ROM and kernel support the settings.

    LOKI and VIDAR are ElementalX governor profiles ONLY!!!
    DO NOT USE THEM WITH A KERNEL THAT DOESN'T HAVE ELEMENTALX BUILT IN!


    DOWNLOAD
    The newest version of HEIMDALL is v4 (2016/02/27)
    The newest version of LOKI is v1 (2016/02/27)
    The newest version of VIDAR is v1 (2016/02/27)
    You can download the profiles from here.


    Feel free to test this profile. Would be great if you could report back and share your findings about performance and battery usage.
    I'm gonna try to tweak this a little more while using it.


    ATTENTION:
    Because of the Dual-Cluster InputBoost make sure inputboost is enabled and input_boost_freq and input_boost_ms are set (apply on boot for all!!!)
    WHEN YOU SWITCH BETWEEN MY (or any other) PROFILES IN EXKM YOU NEED TO APPLY THEM TWICE!!!
    Because of a bug(?) in EXKM, changing the governor and values at the same time could prevent the values from being applied.
    To apply the profiles successfully you MUST
    1. go back to CPU after applying the profile for the first time
    2. reopen Governor-Options and load the profile again.
    3. all values should be set now.


    Changelog

    HEIMDALL v1 (2016/02/20)
    Initial Version (based on DarkSpiceBeta/R6)
    HEIMDALL v1.1 (2016/02/20)
    tweaked above_highspeed_delay and timer_rate for battery
    HEIMDALL v2 (2016/02/21)
    tweaked above_highspeed_delay, timer_rate, go_highspeed_freq (Cluster 2), ...
    added Nexus 5X Version (testing is up to you, I don't own that device)
    HEIMDALL v3 (2016/02/22)
    added IO Scheduler and Read ahead values
    added commands to activate all available cores
    added input_boost_enabled=1
    added termal control settings to profiles
    tweaked min_sample_time, target_loads, timer_rate, above_hispeed_delay
    "beautified" .sh Script
    set input boost for 5X to 672MHz as it seems to use the same voltage as 600MHz - please let me know if im wrong
    synchronized .sh and profile settings
    HEIMDALL v4 (2016/02/27)
    fixed errors in .sh files
    fixed frequencies
    added max_freq_hysteresis
    tweak go_hispeed_load, hispeed_freq, target_loads, timer_rate, min_sample_time, above_hispeed_delay
    introduced dual-cluster inputboost
    LOKI v1 (2016/02/27)
    initial release
    Cluster 1 with elementalx governor
    based on HEIMDALL v4 settings for Cluster 2
    VIDAR v1 (2016/02/27)
    initial release
    Cluster 2 with elementalx governor
    based on HEIMDALL v4 settings for Cluster 1
    HOW TO INSTALL?
    A. Using EXKM (if you have problems with this one, use the .sh file - suggested!)
    1. the file without extension is the actual EXKM profile. Download it and place it under /storage/emulated/0/ElementalX/gov_profiles/
    2. open EXKM
    3. go to CPU -> Governor-Options
    4. load the profile you downloaded
    5. click "apply on boot"
    6. make sure touchboost is off (apply on boot!!!)
    7. make sure min CPU freq ist set to 384MHz for Cluster 2 (apply on boot!!!)
    8. make sure inputboost is enabled, input_boost_freq and input_boost_ms are set (apply on boot for all!!!)
    9. DONE!
    you only need to load the profile once (for one cluster, doesn't matter if little or big). All other values get set automatically.

    B. Using a terminal/shell (suggested)
    1. download the .sh file
    2. use your favorite root file-manager or terminal emulator to run the .sh file under su (root) context.
    3. Check the values in EXKM (or any other supported kernel management app)
    4. make sure touchboost is off (apply on boot!!!)
    5. make sure min CPU freq ist set to 384MHz on both Clusters (apply on boot!!!)
    6. make sure inputboost is enabled, input_boost_freq and input_boost_ms are set (apply on boot for all!!!)
    7. DONE!
    You can save the profile using EXKM to change it to your liking
    (remember: EXKM doesn't save all settings of this profile, so if you change something and reflash your ROM, you need to run the .sh again before applying your changed profile)


    ATTENTION AGAIN:
    Because of the Dual-Cluster InputBoost make sure inputboost is enabled and input_boost_freq and input_boost_ms are set (apply on boot for all!!!)
    WHEN YOU SWITCH BETWEEN MY (or any other) PROFILES IN EXKM YOU NEED TO APPLY THEM TWICE!!!
    Because of a bug(?) in EXKM, changing the governor and values at the same time could prevent the values from being applied.
    To apply the profiles successfully you MUST
    1. go back to CPU
    after applying the profile for the first time
    2. reopen Governor-Options and load the profile again.
    3. all values should be set now.


    The "I tried your profile, but ..."-section

    At first, this is just a profile (tweaks) for the interactive governor. If you expierience any unexpected fc, reboots, massive stuttering/lagging, etc, this script/profile ist most likely not responsible for that.

    My phone uses still to much battery

    1. Have you disabled touchboost?
    2. Set brightness to a lower level.
    3. Use a dark / black theme
    4. Don't play games all day ;)
    5. Get rid of unnecessary (background-)apps
    6. Try another profile
    7. Check the links in my signature, there might be something that helps you.

    My phone is lagging

    1. Get rid of unnecessary (background-)apps
    2. Try a different IO-Scheduler
    3. Try another profile
    4. Check the links in my signature, there might be something that helps you.


    Screenshots
    5 minutes idle time with screen on. DarkSpiceR6 compared to HEIMDALL v1.1
    CPU frequency and usage stats (updated regularly)
    38
    xi5pjqu.png

    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!

    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!
    33
    Shuckeru's review/tests for govenor profiles

    Some of you have probably seen my tests, and lately I've just seen people hopping onto the most talked about profile, which isn't exactly the best thing to do. I have done testing for quite a few profiles and I'll use this post as a center for all my testing so everyone can come here, look at the results, figure out what's probably best for them, then chase that awesome battery life.
    I'll be providing a short summary of things people look for in the profile here, but please go to the respective posts for more detail in usage experience.

    PLEASE NOTE: Just because profile has done well for me doesn't mean it will for you and vice versa.

    Here are a few things to keep in mind that will affect your final battery life
    1. kernel
      different kernels do different things which will use battery at different rates. Contact your kernel developer for more info.​
    2. apps
      More things run, more battery used. simple​
    3. ROM
      people make optimisations (+ve effects on battery), add features and/or services on top of AOSP ROMs which may or may not affect battery.​
    4. temperature
      bit of physics here, phone/CPU hot = energy lost to heat instead of computing. This is not the whole story but an over simplification for those who don't realise.​
    5. movement
      If you're on MM, this will affect you more than official N users as they have Doze on the go now, but I haven't seen anyone commenting on how well it works. However I have found that having your phone facing towards you in your pocket with wake gestures turned on will drain more battery because of the phone attempting to recognise your thigh/butt's input.​
    6. governor/profile
      What you're here for.​
    7. manufacturing consistency
      no one can control this. some phones are just made more equal than others​
    any combination of these will change the results you get and as such, this means that it is very hard to do a controlled real world test thanks to the flexibility that has been vested onto our Huawei Nexus 6p.
    With that said, I'd like to make sure everyone knows to take the following information as a guide, not concrete facts and is by no means exhaustive. If you have something you'd like me to add or would like me to revisit any profile just let me know via pm/reply.

    definitions:

    Light usage:
    As a general rule of thumb, if you're browsing content. That's pretty light.
    Things like checking the news, your social media, forums, watching an offline video, NFC transactions, banking, taking notes.
    These actions do not constantly use data/gps and do not require high CPU usage.

    Heavy usage:
    Another rule of thumb, your phone gets hot. The CPU's probably working hard.
    Playing games, video streaming, calling via cellular/data, video calling, navigation, remote management
    These actions require some combination of data/gps/cellular and probably uses higher CPU frequencies.

    Idle usage:
    Few exceptions here, I do it with screen off, and usually falling under this category because it is for non-SOT actions. That's why when I do, I can only track it via idle time.
    Music streaming, Whatsapp Web

    I think this is enough examples. I don't use every app/mod out there and I'm sure you're smart enough to figure how your app should fair

    phone setup:
    ROM: stock MM
    Rooted: yes
    xposed: yes
    wifi: always on
    data: 4g/3g always on mostly with average(yellow) reception
    bluetooth: always on
    nfc: always on
    location: high accuracy
    brightness: auto
    daydream/screensaver: off
    ambient display: off
    fingerprint: yes
    swipe to unlock: off


    EXKM setup:
    kernel defaults
    with the following exceptions:
    I/O Scheduler: sioplus
    readahead: 2048

    Discontinued profiles

    Profile tests done using Elementalx 1.16 kernel:

    Heimdall v4
    Performance: hiccups near RAM limits, smooth otherwise
    SOT: 2hrs
    verdict: eh... its outdated anyway and gmail was probably sucking batt.
    post with detail

    ghost pepper
    Performance: Often see UI micro freezing, smooth when in use
    SOT: 2.5hrs
    verdict: there was this feeling that i had like "range anxiety"
    post with detail

    eclipse r1 (light usage only)
    Performance: hiccups near RAM limits, smooth otherwise
    SOT: 6.5hrs
    verdict: really nice all rounder without lagging in games too much.
    post with detail


    Profile tests done using kylo R21 aosp 4.9: (incomplete section)

    eclipse r3
    Performance: occasional UI hiccup
    verdict: not so good for gaming.
    Heimdall v4


    Profile tests done using AK 0.66-2 UBER 5.4 (incomplete section)

    eclipse r3


    Profile tests done using kylo R36 UBER 6.x: ended 2 Sept 2016

    Saber
    Usage: 2hrs light, 1.5hrs heavy, 1.5hrs idle
    Performance: feels like Amanuensis (slower than performance oriented profiles)
    Idle drain: ???
    SOT: ~4hrs
    verdict: still feels better than Heimdall, but why use this when there's Dragonfly?
    post with detail

    Blackpepper v1
    usage: 2.75hrs light, 2hrs heavy, overnight + 1hr idle
    performance: lag on wake/some nav functions. No problems in most games, lower fps in 3d intensive games
    idle drain: <1%/hr
    SOT: 4.75hrs
    verdict: for the people who constantly complain about "my phone is too hot"
    post with detail

    Glassfish v1
    usage: 3hrs light, 1.5hrs heavy, 3hrs idle
    performance: stuttering in most games, lags on fingerprint to wake
    idle drain: 2.1%/hr
    SOT: 4.5hrs
    verdict: is alright, but "unusable" when on low battery
    post with detail


    Profile tests done using Ninja v1.9 for M:

    DragonX v1 Hotplugging disabled
    usage: 3.25hrs light, 2hrs heavy, 1.5hrs idle
    performance: smooth and responsive, no observed lags
    idle drain: <1%/hr
    SOT: 5.25hrs
    verdict: Great all rounder, but reported scrolling lag in specific applications
    Post with detail



    Improved profiles

    Profile tests done using kylo R36 UBER 6.x:
    AmanuensisOne
    (Uber heavy)
    Usage: 3.5hrs heavy
    Performance: just a little slower than being fully performance blowned like butterfly. No lags though
    Idle drain: N/A
    SOT: 3.5hrs
    verdict: the new baseline for my tests since 28 July 2016
    post with detail

    (mixed usage)
    Usage: 3hrs light, 2hrs heavy, 8hrs idle
    Performance: just a little slower than being fully performance blowned like butterfly. No lags though
    Idle drain: <1%/hr
    SOT: 5hrs
    verdict: the new baseline for my tests since 28 July 2016
    post with detail

    and since this is the baseline another piece of information that may interest you- script vs exkm profile differences.

    DragonFly
    Usage: 2.5hrs Light, 1.5hrs heavy, 30mins-1hr idle
    Peformance: best of all. 0 lags
    Idle drain: <1%/hr
    SOT : 4hrs
    verdict: No compromises and yet such respectable SOT. pretty average with heavy drain, but this time its full speed ahead.
    post with detail

    Excalibur v2
    usage: 3.75hrs light, 1hr heavy, overnight idle
    Performance: snappy. no lags.
    idle drain: 1.17%/hr
    SOT: 4.75hrs
    verdict: would not mind using this for a daily
    post with detail

    Deadpool
    usage: 2.5hrs light, 1.75hrs heavy, 6hrs idle
    performance: smooth even when CPU throttles
    idle drain: <1%hr
    SOT: 4.25hrs
    verdict: THE profile for light users
    post with detail

    Hawktail v1
    usage: 2hrs light, 1.75hrs heavy, 6hrs idle
    performance: stutter in pokemon go
    idle drain: <1%hr
    SOT: 3.75hrs
    verdict: has really good background usage
    post with detail

    GlassFish v1.2
    usage: 2.5hrs light, 2hrs heavy, 9hrs idle
    performance: stuttering in most games and apps
    idle drain: 1%/hr
    SOT: 4.5hrs
    verdict: is alright if you can stand stuttering, not worth the sacrifice in user experience to save low battery unusability as in v1
    post with detail

    DeusEx
    usage: 3hrs light, 2hrs heavy, 5.5hrs idle
    performance: micro stutters on low battery if CPU is hot, still usable
    idle drain: <1%/hr
    SOT: 5hrs
    verdict: I can recommend this alongside Amanuensis
    post with detail


    Profile tests done using Ninja v1.6 for M:


    DeusEx Revolution
    usage: 2.5hrs light, 2hrs heavy, 9hrs idle
    performance: lags when hot/low battery in heavy usage
    idle drain: <1%/hr
    SOT: 4.5hrs
    verdict: not exactly for mixed/heavy usage. Should be ok for light usage
    post with detail

    Saber v2
    usage: 3.5hrs light, 1.5hrs heavy, 15hrs idle
    performance: Very smooth and responsive, until Power saver mode kicks in. Stutters when warm only in games but not UI
    idle drain: <1%/hr
    SOT: 5hrs
    verdict: Don't let Android power saver kick in and you should be mint
    Post with detail


    Profile tests done using Ninja v1.9 for M:


    DragonX v2 Hotplugging disabled
    usage: 3hrs light, 1.75hrs heavy, 10hrs idle
    performance: very smooth and responsive, no observed lags
    idle drain: <1%/hr
    SOT: 4.75hrs
    verdict: Even smoother than v1, doesn't get as hot, could have slightly more SOT
    Post with detail


    Profile tests done using Ninja v1.11 for M:


    Werewolf v1.2 Hotplugging disabled
    usage: 2.5hrs light, 1.5hrs heavy, 5.5hrs idle
    performance: smooth enough and mostly responsive, lags on 3d fire effects
    idle drain: <1%/hr
    SOT: 4hrs
    verdict: Smooth enough for daily use, but not enough SOT.
    Post with detail



    Recommendations Updated 31 Aug 2016
    Light users: Deadpool/Saber v2
    Mixed users: AmanuensisOne/DragonX v2/Deux Ex
    Heavy users: AmanuensisOne/DragonX
    performance users: Dragonfly
    cold phone users: Blackpepper v1