[KERNELS][GUIDE] KERNELS EXPLAINED, governors, hotplug, frequency, CPU, GPU, I/O, etc

[bloof]

GENERAL GUIDE TO KERNEL SETTINGS​

some focus on Dorimanx and Boeffla Kernels​

POWER CONSUMPTION VS PERFORMANCE​

GOVERNORS AND HOTPLUGS​

I/O SCHEDULERS, NET CONGESTION, BENCHMARKS​

UPGRADE/DOWNGRADE BOOTLOADERS, RECOVERY​

The purpose of this thread is to put in one place some answers to a LOT of questions on what governors and hotplugs actually do and how to search for your best kernel settings that match your style of phone use.

I also suggest trying the multi-core with low frequency approach for very good performance AND battery savings (yes, you can have both). Frequencies of 1.5/1.7 GHz with an aggressive governor and hotplug should give the same performance as 2.5/2.8 GHz frequencies but with massive battery savings.
I am still in the early stages but would hope others will try this.

This is NOT an ULTIMATE guide, please provide all feedback and comments you see fit, it is all welcome, there are a lot of people with experience and knowledge in this forum.


Post 1: Table of contents

Post 2: Basics of performance and power consumption: how to save power without sacrificing performance

Post 3: Governors, Hotplugs and Recommendations

Post 4: More Detailed Reviews and Recommendations with an emphasis on Dorimanx/Boeffla kernels

Post 5: Visual Comparisons of Governors, Hotplugs

Post 6: Comparisons 2 cores high freq vs 4 cores low freq

Post 7: Battery saving tips and smoothness/lag-free tips

Post 8: TCP NET CONGESTION

Post 9: I/O Schedulers

Post 10: upgrade/downgrade recovery/bootloader/kernels to JB/KK bootloaders, bumped/loki: implications for flashing ROMs.

Post 11: BENCHMARKS

Post 12: Cool Tool Settings

CREDITS to a LOT of people! @dorimanx, @boeffla for their kernels, @ZaneZam for his great governors, @gsstudios for his phenomenal governors guide, xda forums for teaching me, and so many others!

**************************************************************************************************************************************************************
**************************************************************************************************************************************************************
Changelog:

24.02.2015: minor
- added text on power consumption post 2, minor update. Added 2 links to qualcomm blogs for more info.
- added boeffla's settings for his kernel to post 4.

23.02.2015: minor
- added intelligent HP to Dorimanx text
- recommend intelligent HP as alternative to MSM for less battery drain


20.02.2015: MAJOR
- NEW POST #6: VISUAL COMPARISONS OF 2 CORES HIGH FREQ TO 4 CORES LOW FREQ
- post 5: added Dorimanx governors pictures
- moved post #7 to #10 (THANKS d00ltz!)
- moved post #6 to #7


19.02.2015: MAJOR
- NEW post 5 completely re-written with new stuff
- post 5 "battery savings tips, etc" moved to post 6
- post 6 "cool tool" moved ot post 12
- merging of dorimanx/boeffla specifics in one post (#4)
- complete re-write of dorimanx/boeffla specifics
- complete re-write of post 3 for general governors/hotplugs

18.02.2015: minor
Post 4: added dedicated kernel settings thread link, added extreme battery profile

 

[bloof]

PERFORMANCE AND POWER CONSUMPTION BASICS​

And how to achieve same performance with less battery drain​

performance = how quickly things get done
power consumption = how much battery is used

Let's take a car as analogy. The performance (speed) would be represented by time to 100 kmph and time to travel 1 km, for example. Consumption would be total fuel consumed.



**************************************************************************************************************************************************
**************************************************************************************************************************************************

CPUs, GOVERNORS AND HOTPLUGS:

For cpus four things matter:
1. clock freq. We will assume that at double the frequency the task takes half the time.
2. how many cores are in use. This is from the hotplug.
3. scaling frequency. how does the governor ramp up the cpu freq and how long it takes to get to max freq.
4. thermal engine.


CPU power consumption = voltage^2 x frequency x capacitance

P = v^2 x f x c
P= power
v = voltage (can be modified by kernel, but not recommended if you don't know what you're doing)
f = frequency (can be modified by kernel)
c = capacitance (depends on actual physical build of the system)

See attached picture for a graph representation of CPU power consumption versus frequency and note the non-linear aspect. This is due to the voltage being a non-linear parameter in power consumption.
The picture is a bit misleading, at higher frequencies above 1400 MHz the voltage rises more quickly and power consumption increases more rapidly.

NOTE: undervolting can greatly help reduce power consumption, but it can be very bad for your cpus, it can fail to trigger cpu cycles and all sorts of other things, it is NOT GOOD unless you know what you are doing.
other assumption: your cores can have voltage distributed individually and at different voltages from each other.

Clock frequency:
Let's assume that double the clock freq means the task takes half the time. This might not be true of badly designed cpus, etc. But who cares.
The consumption is LINEAR with frequency, if you have double the clock speed you will use double the power. BUT THAT'S NOT TRUE FOR VOLTAGE!!!!
A cpu uses more voltage at higher frequencies, so the power consumption rises VERY QUICKLY with higher clock speeds.
So the question is: is it better to have multiple cores at lower frequencies or one core at high frequency?


Hotplug and multitasking:
If you are doing ONE task, and the application/system is good enough to use all the cores, then doubling the cores will lead to the task taking half the time.
But, if you are multitasking, some cores are doing something else and can't be used. So in practice having double the cores doesn't mean having double the available frequency.
The hotplug can be aggressive or not:
- as soon as more cores are needed it will wake all of them up and get things done. More performance, more consumption.
- it will wake up cores more slowly and keep them on for less time. Less performance, less consumption.


Scaling frequency:
Coming back to the car, if you want pure performance you floor the pedal and achieve the best results in terms of time to 100 kmph and time for traveling 1 km but you burnt all your fuel.
A governor that scales frequencies can do it in two ways:
- max power for a long time: same as flooring the pedal, jump straight to max freq and stay there until the end of the task. Some governors will stay there longer, expecting that you will do a task requiring max freq pretty soon after you've done it.
- scale freq over several steps with plateaus for a certain time. This is like setting speed limits on the race track: the car will accelerate more slowly, take longer to get to the destination but burn a LOT less fuel.


Thermal engine:
cpus get hotter at higher freq, to the point where you can PERMANENTLY DESTROY or DAMAGE them.
Hence, the kernel will have a thermal engine to regulate clock frequency depending on cpu temperature.
What this means is that for heavy tasks that take a long time, the maximum practical cpu frequency will be MUCH LOWER than the theoretical max frequency. For example, if you have max freq at 2547, your thermal engine might simply set the freq at 1190 during the task! That's a GOOD THING!

**************************************************************************************************************************************************
**************************************************************************************************************************************************

THE BIG QUESTIONS:
Should I use more cores at lower freq or not?
What is the difference between one core at high freq vs one core at lower frequency?

In a simple system, one task to do, let's have a look. I am using voltage/freq from OnePlus One phone, but I expect things are similar for everyone.
If the task is long and heavy, all the cores will work at reduced freq due to thermal engine, so it doesn't matter what you do. These results are only for quick tasks.

PS: don't ask about the units, this is relative comparison for ratios, so units don't matter.

The real drop in performance is not as much as the simple frequency reduction, it depends a lot on the cpu hardware. Some numbers I found (for different cpus):
- 31% frequency reduction = 26% performance reduction; 66% reduction in power consumption
- 20% frequency reduction = 13% performance reduction; 49% reduction in power consumption

But the numbers shown below are approximately correct.

Example 1: same task, 1 core vs 2 cores
1 core at 2547 Hz. Performance = 2572. Consumption = 3.084
2 cores at 1267 Hz. Performance = 1267x2 = 2534. Consumption = 0.88
=> Same time to complete task, the 2 cores at lower frequency consume one third of the power!


Example 2: same task, only 1 core.
1 core at 2547 Hz. Performance = 2572. Consumption = 3.084
1 core at 1958 Hz. Performance = 1958. Consumption = 1.75
For the same task, the core at 1958 needs to be ON for 2572/1958 = 1.3 times longer than core at 2547. So it will consume 1.75x1.3 = 2.3
=> the single core at 1958 will take 25-30% longer time but consume 25-30% less battery.
In practice the time taken will be shorter and the battery saving larger than these numbers.


Example 3: same task, only 1 core, different gov
Max freq = 2572
Start freq = 268
Freq scaling steps: 1 ms
1 core straight to 2572: Exxon governor
1 core at 1190 then 1574 then 2265 then 2572: greenpeace governor
=> answers: I have no idea, not calculating this.
- for very quick small tasks, the greenpeace gov might never reach the highest freq, and will consume insanely less power than the Exxon gov.
- for long heavy tasks, they will consume about the same and take about the same time since they will be throttled by the thermal engine.
- for medium tasks, the greenpeace gov will take longer to complete, maybe 20-30%, but consume about 40-50% less battery. This really depends on the governor, most good governors are pretty balanced and will fall somewhere in-between.


Example 4: hotplugs
I won't even get into this, but if you throw-in hotplugs in there the difference between an (aggressive hotplug + Exxon governor) and a (less aggressive hotplug + greenpeace governor) increases significantly to the point where you will actually notice applications taking longer to load, screens not rotating quickly at all, general annoyance at your phone behaving like a nokia vintage 1998.

You also understand why no-one in their right mind will calculate governors and hotplugs configurations for you and tell you which is best.


**************************************************************************************************************************************************
**************************************************************************************************************************************************


MY BIG QUESTION: ACHIEVING THE SAME PERFORMANCE WITH LESS BATTERY DRAIN
For the same expected performance, is it better to have a battery-saving governor + aggressive hotplug or an aggressive governor + battery-saving hotplug?
That's the big question.

We've already established that you should underclock your frequencies, if you didn't get that from everything I said then it's your life anyway, doesn't affect me.

From example 1, we can clearly see that theoretically more cores at lower frequency makes sense, especially since thermal engines will reduce clock speeds for super heavy tasks.
However, when multitasking comes into play as well as ****ty apps/systems not making full use of the fact that there are several cores to choose from, then the answer is not so clear cut.

I have found that for power consumption the hotplug seems to matter much more than the governor, but it could depend heavily on what you use your phone for.


Play around with your kernel, and test with user experience, not benchmarks. For example:
1. a very battery friendly governor with a very battery friendly hotplug, leaving theoretical max freq at 2572 or whatever.
dorimanx: alucard HP + max freq 2.3 + alucard govs
boeffla: zzmove native default HP + max freq 2.5 + zzmove battery extreme yank

2. very aggressive governors & HP:
dorimanx: MSM HP + max freq 2.8 + intelliactive/darkness
boeffla: zzmove native 2 cores min + max freq 2.8 + zzmove insane/intelliactive/ondemand

3. try this: aggressive HP + UC + semi-aggressive governor
dorimanx: MSM HP + max freq 1.7 (for all cores) + darkness/ondemand/impuls
boeffla: zzmove native 2 cores min (or Default HP) + max freq 1.7 + zzmove - performance
Try this even at 1.3 MHz, you might be surprised.

You will start noticing that you can't make the difference between crazy performance settings and more balanced ones, and if you can't tell the difference then for goodness' sake stick to the battery friendly option.


**************************************************************************************************************************************************
**************************************************************************************************************************************************

GPU:
The GPU is a major function of power use and performance, the more screen changes happening (scrolling, gaming, etc), the more it is used.
Controlling the GPU max freq can significantly help reduce battery consumption but will lead to issues with gaming especially (loss of Frames per Second, unresponsive game).
I would recommended underclocking the GPU unless you really need it. If that leads to issues for your daily phone use then scale back min/max frequency to default levels or even overclocking.

More importantly, if you kernel allows (Dorimanx, Boeffla do), then reduce min GPU frequency to 27 MHz. That is a large battery saving feature with no performance impact.

See attached picture for the relationship of power usage of GPU versus frequency. GPU freq index 0 to 3 is low to high frequency.

**************************************************************************************************************************************************
**************************************************************************************************************************************************

UNDERVOLTING:

Just a quick add to show tables of voltage versus frequencies and if you square the voltage times the frequency you will realize how quickly power consumption grows with frequency.

Example voltage versus frequency for Z2 (from here (credits @Haldi4803).
300mhz = 775mV
422mhz = 775mV
652mhz = 775mV
729mhz = 775mV
883mhz = 780mV
960mhz = 790mV
1036mhz = 810mV
1190mhz = 820mV
1267mhz = 850mV
1497mhz = 860mV
1574mhz = 880mV
1728mhz = 915mV
1958mhz = 975mV
2265mhz =1010mV
2457mhz =1010mV

Voltage OnePlusOne (credits @Lord Boeffla, at least that's where I take it from):
300mhz = 770mV
422mhz = 775mV
652mhz = 775mV
729mhz = 775mV
883mhz = 785mV
960mhz = 795mV
1036mhz = 805mV
1190mhz = 825mV
1267mhz = 835mV
1497mhz = 865mV
1574mhz = 875mV
1728mhz = 900mV
1958mhz = 945mV
2265mhz =1005mV
2457mhz =1040mV
2572mhz = 1095mV
2726mhz = 1125mV
2880mhz = 1155mV

**************************************************************************************************************************************************
**************************************************************************************************************************************************

Further Reading:
Qualcomm article on power consumption
Another Qualcomm article on battery & power
Integrated CPU-GPU Power Management for 3D Mobile Games
Wikipedia: Underclocking
An Analysis of Power Consumption in a Smartphone
Utilization-based Power Modeling of Modern Mobile Application Processor

 

[bloof]

GOVERNORS AND HOTPLUGS​

explanations and recommendations​

also see next post for a lot more details​

If you like reading on kernels and such, there is also this phenomenal thread by Haldi: Haldi's Thread for Z2(credits @Haldi4803)

Governor Descriptions:
I will NOT go through descriptions of all the governors, by far the most complete I have found is this one: Best List of Governors

READ THE LINK ABOVE. It contains a LOT of very good information on governors.

You can find more links in here, and here and here and here.
(credits to authors, I am a bit confused who the authors actually are, lots of reposts).

Many governors listed in the links above are out of date and not optimized for modern quadcore processors, which are a lot better than they used to be (for example, voltage distribution can be different for each core, etc).

BEFORE YOU START, KNOW WHAT ARE CPU INTENSIVE TASKS:
- Heavy gaming (either graphic or AI intensive): you will lose almost 1% battery per minute, nothing you can do about this, but if you use battery saving features your game might lag/stutter.
- Browsing & multitasking (which usually involves browsing)
- Photo/video editing, viewing/zooming/generally playing around with visual multimedia
- GPS
- Long term background usage: your screen, network, apps that sync (facebook, gmail, etc). See in post 5 a few things you can do. But this thread is not about these issues so I won't talk about this.
- video playback, general phone use, etc are NOT heavy tasks


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

What is a governor for Noobs:
performance = how quickly things get done
power consumption = how much battery is used
Let's take a car as analogy. The performance (speed) would be represented by time to 100 kph and time to travel 1 km, for example. Consumption would be total fuel consumed.
The governor sets speed limits on the tracks for various distances to cover as well as how hard to step on the accelerator. This will CONTROL how quickly the car gets to the destination and how much fuel it consumes.
Some governors are battery friendly, they will ramp up the speed slowly and for longer distances but use less fuel.
Some governors are performance driven where they will jump to max speed straight away (I know, a car can't do that, but a phone can), and stay there until you reach the destination.
Some governors are balanced, accelerating more or less quickly to max speed or close to it, consuming more or less fuel.

IMPORTANT: the behavior of governors cannot really be un-linked from the hotplugs. You might find combinations of certain governors/hotplugs make a performance governor more battery friendly for your style of phone usage. See this list as a guideline.


What is a Hotplug for Noobs:
It is also important to talk about the hotplugs (very briefly here): if you imagine the car again, you would say there is NO WAY that you can achieve the same performance AND save fuel at the same time.
Let's have another car analogy: you have 4 lanes and 4 cars. They need to take 100 very heavy pizzas to the destination (let's ignore added friction due to car weight). You can let one car do ALL the work, or spread the load between one to four cars. That's what a hotplug does. Knowing that a car with 50 pizzas consumes a lot less fuel than a car with 100 pizzas you can now see how we can have the same performance and save on fuel: load two cars with 50 pizzas and let them accelerate as quickly as possible to the destination (performance governor). They will get there as quickly as one car with 100 pizzas (=same performance), but burn less fuel (=battery saving).


VERY IMPORTANT: Despite the existence of dedicated hotplugs in new CPU systems, a GOVERNOR can have its OWN hotplugging coding.
All it means is that the codes to switch additional cores ON and OFF is also included in the governor. Not all governors have this. PegasusQ and zzmove do for example. Therefore, if in your kernel those governors come with a dedicated hotplug you should use it.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

GOVERNORS:

This section will simply go through the various options in both kernels and let you know which ones are more or less performance or battery friendly.
Since I don't have all the phones and all the kernels, this might or might not apply to your kernel. However there are many governors that are common to everyone so that helps.

Governors:

Below is a list of the main governors loosely ranked from battery to performance focus:
MORE DETAILS ON A LOT OF THESE GOVERNORS IN THE NEXT POST.

NOTE: the combination with the hotplug is very important. Using a performance governor (that comes down to low freq often, such as ondemandplus or darkness or others, see below) with a battery saving hotplug can have very good balance and battery savings.

Extreme Battery Governors: Don't play heavy games with these
Conservative: anything with that name is very battery friendly and WILL sacrifice on performance, but could be OK for you.
Powersave: anything with that name is very battery friendly and WILL sacrifice on performance, but could be OK for you.
Intelimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor, I am not sure if it is more or then battery saving than Yankactive.
Yankactive: a modified interactive, good for battery save, bad for games. (low FPS).
zzmove extreme battery variants: zzmove governors with "battery extreme", "battery extreme yank", "battery yank" or "battery plus" in the title. "zzmove battery" is probably already in the balanced governors section (with a focus on battery savings).

Balanced Battery Governors:
zzmove battery: focus on battery savings, but not bad on performance, so in the balanced section.
Alucard: a favourite choice of many for battery without losing much performance.
Darkness: alucard that goes very quickly to max freq but does not stay there long. Better for responsiveness and good for battery too.

Balanced Governors:
Nightmare: has the coolest name. A PegasusQ modified, less aggressive and more stable. Good for performance without being battery unfriendly.
zzmove moderate/optimal: made to be balanced, please use with associated hotplug, moderate is an updated version of optimal. A lot of people are very happy with these two governors. zzmove governors ALL have battery saving features for phone idle, so waking up phone can seem more laggy than with other governors, but it saves battery. I find this a good compromise.

Balanced Performance Governors:
OndemandPlus: based on Ondemand and Interactive with modifications to the upscaling codes so it does scale to max freq as quickly, performance reported as very battery friendly in combination with a battery friendly hotplug such as Alucard, so not sure where to rank this one. For pure performance would use something else.
Ondemand (Dorimanx kernel ONLY): very good performance and balance oriented. Used by the man himself (Dorimanx).
Interactive battery variants: some variants of Interactive are more battery focused ("battery" or "extreme battery" in the title, etc) but assume those are balanced governors, probably on the performance side.

Pure Performance Governors:
zzmove performance/game/insane: performance governors, (please with with associated hotplug). "Performance" can be used as a balanced governor as well, depending on your other kernel settings. "Game" is designed to better handle hot phones when heavy gaming. "Insane" is more performing than "performance". Zzmove governors ALL have battery saving features for phone idle, so waking up phone can seem more laggy than with other governors, but it saves battery. I find this a good compromise.
Interactive: the basic android governor that focuses on quick jump to high frequency to please users when they switch on the phone and go straight to doing something on it. Very performance oriented and has a lot of more modern derivatives.
Impulse: based on interactive, more modern, making use of new phone architectures. Probably more efficient than Interactive. Could be better than Intelliactive for newest phones.
Intelliactive: based on interactive. Uses some tricks to save battery without sacrifice of performance. Preferred over Interactive basic.
Ondemand: very performance oriented, no thought to much battery savings. NOT to be confused with "Ondemand" in Dorimanx kernel, that one is more balanced performance oriented, heavily tweaked by one of the best kernel developers ever.
Slim: new governor, very performance oriented, not much thought (if any from what I hear) to battery savings. Use it with a phone with good battery life and performance is your thing. OnePlus One is mentioned as a good phone for this.
Wheatley: based on Ondemand. More modern, probably more efficient (=same performance but better on battery than Ondemand).
Intellidemand: based on Ondemand. Behaviour changes with GPU load, so if GPU load is high it behaves like Ondemand, otherwise tries to save a bit of battery. Use it if you play games for example but don't do only that.
PegasusQ: an old governor based on Ondemand and made for performance. There are probably better newer governors now, but people still report happy use of this one (probably with battery saving hotplugs).
Performance: usually means the cores will stay at maximum frequency. You can't have more performance than this but say goodbye to battery life.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

HOTPLUGS:

Ranked from battery friendly to performance:
It is very hard to "rank" hotplugs, but their combination with governors can make a world of difference, especially when going for a "balanced" approach. What usually works there is to use a battery-performance or pure performance governor with a battery saving hotplug.

Each kernel has their own hotplugs or variations thereof. You will really need to check your own kernels for more information.


Battery Hotplugs:
Alucard HP: very famous, a favourite of all "balanced" (usually in combination with a balanced battery governor to be on the more balanced battery side or with a performance governor to be more on the balanced performance side) or "pure battery" phone styles. Does not switch on cores excessively for low load tasks, but does NOT sacrifice performance much.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max).

Middle of the road Hotplugs:
Default LG HP (Doriamanx kernel ONLY): This is NOT the default LG hotplug, but a heavily tweaked version. Probably a middle of the road hotplug.
MSM HP with battery profiles: (I am only familiar with the Dorimanx implementation). It will switch on more cores very quickly. In Dorimanx kernel, this hotplug can be heavily tweaked to be battery friendly to pure performance. With the right tweaks it is a very good choice for balanced performance.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max).
Default HP: I fail to see how any hotplug called "default" would be anything but a middle of the road hotplug, UNLESS your kernel maker has made their own default kernel hotplug, in which case you should probably use it if recommended for that kernels' main governor or for whatever reasons the kernel maker created that hotplug. Phone manufacturers love to have happy users so it probably will not try and save too much battery and not be too clever either. Pick another hotplug more suited to your needs if you have one available.

Aggressive Hotplugs:
MSM HP: (I am only familiar with the Dorimanx implementation). Hotplug for pure performance. It will switch on more cores very quickly. Very good choice for balanced performance or pure performance styles. In Dorimanx kernel, this hotplug can be heavily tweaked to be battery friendly to pure performance. Recommended if you use the combination of low max frequency and multiple cores online.
zzmove native default HP: I will put this HP in all sections as it is intended to be used with zzmove and will help the zzmove governors behave the way they are intended to. You should really use this if you use zzmove governors. Has battery savings for idle (1 core max), so will not respond as quickly on phone wake up as other aggressive hotplugs.

*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

RECOMMENDATIONS:

THE GOLDEN RULE 1: IT ALL DEPENDS ON WHAT YOU USE YOUR PHONE FOR. EVERYONE WILL PREFER DIFFERENT SETTINGS.
THE GOLDEN RULE 2: YOU CAN'T ARGUE ABOUT TASTED AND COLORS AND YOU CAN'T ARGUE ABOUT GOVERNOR AND HOTPLUGS SETTINGS.


My recommendation for you to try, balanced, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1.7/1.5/1.5/1.5 || Governors = Intelliactive/Darkness x3 or Darkness x4 || HP = MSM
- (I have not tested Yankactive/nightmare/ondemand/impulse combinations, feel free).
- GPU: max speed = 389 MHz || min speed = 100 MHz
- MSM hotplug: suspend mode to always active.
- You can set higher frequencies than 1.5, but just try it this way anyway.


Very Battery Friendly :
- CPU: set your max frequency to something much lower than your phone's max frequency (not your kernel's overclocking max frequency). At least 40-50% lower but check if your phone is built for that. For high end phones use 1.3 to 1.5 GHz for example. Increase if you have issues waking up your phone.
- Governors: obviously a battery one.
- HP: obviously a battery one if available. If desperate for battery saving, try to use hotplugs that allow 1 or 2 cores max.
- GPU: underclock your GPU to one step above the minimum; set min GPU to the minimum you can find
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc)
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.

Balanced on the battery-side version 1: everything balanced
- CPU: set your max frequency two to three steps lower than your phone's default max frequency (not your kernel's overclocking max frequency). Depends so much on your phone that you will have to see.
- Governors: use a balanced battery friendly governor.
- HP: use a battery friendly hotplug.
- example: alucard governor with alucard hotplug
- GPU: underclock your GPU to one/two steps below default GPU max; set min GPU to the minimum you can find
- Optional:
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc).
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.


Balanced on the battery-side version 2: battery friendly hotplug and other settings and performance governor
- A lot of people like these settings as phone responsiveness is very good and good battery life. It might not be achievable with all kernels.
- CPU: set your max frequency one to four steps lower than your phone's default max frequency (not your kernel's overclocking max frequency), depending how "balanced" you want this. Depends so much on your phone that you will have to see.
- Governors: use a balanced performance governor or even a performance governor.
- HP: use a battery friendly hotplug or middle of the road if nothing else available.
- Example: ondemandplus/darkness governor with alucard hotplug, or zzmove moderate/optimal/performance governor with zzmove hotplug
- GPU: underclock your GPU to one/two steps below default GPU max (unless you play a lot of heavy games); set min GPU to the minimum you can find.
- Underclocking your GPU will not affect your video playback. Use default or max GPU only if you play games that require it or a lot of web browsing, etc.
- Optional:
- Additionally you can change: touchboost OFF (or reduce freq), CPU gov sample rate to a higher number, etc. Depends on what your kernel lets you do.
- Disable all logging (kernel logging, android logging, etc).
- Disable all other non-essential kernel settings (audio boosts, gesture controls, etc). This depends so much on your kernel that I can't help you more.


Pure Performance:
- CPU: set your max frequency to phone's default max frequency or overclock if you like (although with modern good phones I really think that is completely unnecessary).
- Governors: use a performance governor, or a high level "balanced performance" governor to save a bit of juice (depends on your other settings).
- HP: use an aggressive hotplug.
- Example: your choice, shouldn't be hard to figure it out.
- GPU: set to default GPU max or overclock if you like; set min GPU to default min frequency (many kernels allow a min GPU at 27 MHz for example, don't use that if you play games, otherwise you can still use it here).
- Additionally you can change: touchboost to higher frequency, CPU gov sample rate to a lower number, etc. Depends on what your kernel lets you do.
- There's probably more settings you can change to boost performance if desired.

 

[bloof]

GOVERNORS AND HOTPLUGS​

Kernel Specific Dorimanx & Boeffla
but this contains useful info for all kernels​

*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

DORIMANX GOVERNORS AND HOTPLUGS:

Dorimanx Specifics:
Dorimanx kernel has many tweaking options, including the ability to set governor and min/max frequency independantly for each core. This gives a level of tweaking not often seen elsewhere.


Governors:

IMPORTANT: the behavior of governors cannot really be un-linked from the hotplugs. You might find combinations of certain governors/hotplugs make a performance governor more battery friendly for your style of phone usage. See this list as a guideline.

Below is a list of the main governors loosely ranked from battery to performance focus:

Battery Governors:
Conservative: keeps the core frequency at minimum most of the time, very battery friendly but not very clever. Terrible fore performance.
Powersave: keeps the core frequency lowish all the time, very battery friendly but not very clever. Terrible fore performance
Intelimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor, much more battery friendly than Yankactive.
Yankactive: a modified interactive, good for battery save, bad for games. (low FPS).

Balanced - on the battery-side:
Darkness: alucard that goes very quickly to max freq but does not stay there long. Better for responsiveness and good for battery too. Frequently prefered over alucard.
Alucard: very good for battery. Goes slowly to max freq, stays there longer if required.
OndemandPlus: based on Ondemand and Interactive with modifications to the upscaling codes so it does scale to max freq as quickly. It is a performance governor at heart, but reported as very battery friendly in combination with the right hotplug (alucard). I have doubts this is more battery friendly than alucard with an aggressive hotplug (eg: MSM). In summary, will not go as quickly to max freq as ondemand but downscaling is similar.

Balanced - on the performance-side:
Nightmare: has the coolest name. A PegasusQ modified, less aggressive and more stable. Good for performance without being battery unfriendly.
Ondemand: this is the dorimanx ondemand, not the standard one, do not be confused by the name and finding it in the balanced governors. I think his current version is more balanced between performance and battery. The basics of ondemand is to scale freq based on need, so will boost freq if needed much more than alucard will. Probably the most tweaked/up to date governor in this kernel. Seems to prefer staying at medium frequencies rather than scale up and down all the time.

Performance:
Impulse: Impulse governor is based on CAF Interactive but with additions to work smoothly with CPU Boost driver and improved freq stabilization. Based on the fact that this is based on interactive it is a performance governor but probably more battery friendly/efficient. More battery friendly than intelliactive. Probably on par with interactive but probably more efficient as it is newer.
Interactive: the basic android governor, based on pleasing users by very quick response to high freq to reduce lag when switching phone on and expecting user will interact with phone quickly (launch app, etc). This governor does come back to low frequencies quickly and therefore more battery friendly than intelliactive.
PegasusQ: an old governor for dual cores. The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. See governor link at beginning of post to find out more. It is a good governor but old, more efficient governors exist now, however, some people report good results with this. It is very performance driven, just like Ondemand, probably not many battery saving features other than better handling of loads through hotplug and its own queuing techniques.
Intelliactive: a better version of the interactive governor which is an ondemand on steroids, it will boost up very quickly on need but will stay there on timer. Freq will not fluctuate as much as ondemand. It is not a battery killer either because it is not a stupid governor, it will use other tricks to save battery. This governor was designed for quick user responsiveness, and is therefore one of the best "lag-free" governors. Seems to stay at medium frequencies when tasks are needed and not scale down to low frequencies until full rest. More battery friendly than intellidemand.
Intellidemand: based on Ondemand, so a performance governor. Its behavior is linked to GPU, if active GPU (games, etc) then it behaves like Ondemand. When GPU is inactive it will scale max freq differently to save on battery.
Performance: keeps the cores at max frequency. Obviously the best for performance and the absolute worst for battery. Good governor for running benchmarks if you want to study power consumption, etc as it is independent of hotplugs and everything else.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

Hotplugs:

The hotplug will change the performance/battery savings of your governor combinations. But in general, it will compound the differences:
- a battery friendly hotplug with a battery friendly governor will be very battery friendly
- an aggressive hotplug with a performance governor will have very good performance and poor battery
- it gets interesting with other combinations to achieve balance: a battery friendly hotplug and a performance governor (eg: alucard HP + ondemandplus) can give very good balance.

NOTE FOR DORIMANX KERNEL: since you can set your governors independently for each core, make sure you understand how the hotplug works. For example, alucard seems to switch on core 1 then core 2 then core 3 when needed but MSM seems to go to core 3 or core 2 first. So if you want to combine performance and battery governors in your setup make sure you select the right cores to do so based on your hotplug.

Ranked from battery friendly to performance:

Alucard HP: The most battery friendly, does not switch on cores excessively for low load tasks, but does NOT sacrifice performance much. A lot of users use this HP.
Default LG HP: This is NOT the default LG hotplug, but a heavily tweaked version.
MSM HP: The basic hotplug for pure performance. It will switch on more cores very quickly.
Intelligent HP: another good hotplug aggressive but seema to work well, a good alternative to MSM.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

Recommendations:

There are so many things you can tweak in this kernel that everyone has their own versions of what they consider "best". I can't post everyone's suggestions.

Dorimanx himself: uses "performance" profile in STweaks. That's it, no other tweaks. It is a performance focused balanced setup.

My recommendation for you to try, balanced, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1.7/1.5/1.5/1.5 || Governors = Intelliactive/Darkness x3 or Darkness x4 || HP = MSM or Intelligent HP if MSM drains too much battery
- (I have not tested Yankactive/nightmare/ondemand/impulse combinations, feel free).
- GPU: max speed = 389 MHz || min speed = 100 MHz
- MSM hotplug: suspend mode to always active.
- You can set higher frequencies than 1.5, but just try it this way anyway.


Battery friendly : set "battery" or "extreme battery" profile. Max freq = Alucard or Intelimm or yankactive || HP = Alucard
- GPU: max speed = 70,000)
- Keep "max screen off cpu freq" to 1.7 or higher for stability.
- CRON OFF (disabled)
- Sweep2sleep OFF

Balanced on the battery-side:
- Set profile to "default". Max freq = Darkness or Nightmare or OndemandPlus || HP = Alucard (preferred) or Default LG
- GPU: max speed = 2.3 || Governors >= Ondemand or OndemandPlus or Interactive or Impulse or Intelliactive || HP = alucard or intelligent for more performance
- GPU: max speed >= 450 MHz || min speed = 100 MHz
- Additional tweaks: decrease sample rate.

Performance: Just use "performance" or "extreme performance" profile. Max freq >= 2.5 || Governors >= Interactive or Intelliactive or Impulse or Intellidemand || HP = MSM or intelligent for better battery
- GPU: max speed >= 533 MHz || min speed = 200 MHz
- There are a lot of tweaks you can do to make it even faster:
- Important tweaks: decrease sample rate, play around with MSM Hotplug controls (descriptions in STweaks)
- Other tweaks: touchboost, powersave switch to performance, disable power-efficient workqueues.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

BOEFFLA GOVERNORS AND HOTPLUGS:


Governors:

Below is a list of the main governors loosely ranked from battery to performance focus:

NOTE: all governor parameters are tunable in boeffla pro version, so you can change how each governor behaves, only use of you really know what you are doing.

I will start with zzmove because it has the whole range of governor options to select from. They are pretty self explanatory.

Zzmove: Some idle/suspend battery saving features and many performance features in conjunction with its associated hotplug, large focus on "suspended" battery saving. There are many zzmove configurations pre-set in Boeffla kernel. From ZaneZam himself: "Basically this is the ported SGS1 version of the well known "smoove" governor from the good old midnight kernel from Michael Weingaertner (mialwe) with a modified CPU hotplug implementation of the ktoonservative governor from ktoonesz. The original implementation from ktoonesz worked well but I observed that on idle most of the time only one cpu was going to sleep. Well that was not enough for me so I made a modification to put the other cpu's also to sleep (except cpu0). That means that this governor uses more often only one cpu on idle and as a consequence of that it needs less energy. Depending on System load and governor settings all 4 cores will be instantly up again if it is needed." More details here.
IF YOU USE ZZMOVE GOVERNORS IT IS BEST TO ALSO USE ZZMOVE NATIVE HOTLUG.

Battery Governors:
Zzmove battery extreme yank
Zzmove battery yank
Intellimm: "intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations.". It is a battery friendly governor. Difficult to know exactly where it stands with respect to all the zzmove battery governors, but probably on par with battery or yank.
Zzmove battery plus this could be even more battery saving than the other zzmove battery governors, but this is based on a very short test, so could be wrong.
Interactive battery extreme: it is actually very hard to rank all these battery governors, please just see this as a very loosely ranked list, not a tested ranking.
Smartmax: battery oriented but still based on Ondemand with a mix of smartass2, however it seems to be very battery oriented with very slow scaling (?). More details here.
Zzmove battery: the more performing of the battery governors, getting to the grey area between battery and balanced governors.

Balanced Governors:
Interactive battery extreme: despite the title I am pretty sure this one has tipped into the balanced governors, but really on the edge.
Interactive battery: same as above, but more balanced. I would pick zzmove moderate
Zzmove moderate: an updated version of optimal, uses 2 cores most of the time, very good performance and battery saving balance. This and zzmove optimal are preferred choices for most balanced users (that's most of you too) of Boeffla.
Zzmove optimal: good balance governor, needs zzmove native HP for best effect. But see zzmove moderate, a more updated version of this. This one seems to go through more scaling steps. You probably won't see a difference between this an moderate, though. I still don't know which one I would pick.

Performance Governors:
Intelliactive: a better version of the interactive governor which is an ondemand on steroids, it will boost up very quickly on need but will stay there on timer. Freq will not fluctuate as much as ondemand. It is not a battery killer either because it is not a stupid governor, it will use other tricks to save battery. This governor was designed for quick user responsiveness, and is therefore one of the best "lag-free" governors. I would pick this over intellidemand or interactive performance for example, but I am not a game player.
Interactive performance: the basic android governor, based on pleasing users by very quick response to high freq to reduce lag when switching phone on and expecting user will interact with phone quickly (launch app, etc). Obviously performance but seems to use low frequencies more than other performance governors listed below.
Interactive standard : performance oriented, jumps quickly to high frequencies, no much coming back/staying at min freq, but more so that Interactive Performance. Depending on your style of phoning select this one or the interactive performance.
Zzmove performance: aggressive and very high performance governor, but will save battery when inactive compared to other performance governors. Please use zzmove native hotplug of course. I would pick this over intellidemand, interactive standard/performance. I would also probably pick this over slim/wheatley/etc.
Zzmove game: choose this one if you play heavy games. High performance but helps reduce cpu heat during gameplay, which helps save your cpus (thermal engines WILL lower your cpu frequencies when hot, so super heavy performance governors set at 2.5 GHz will NOT be at 2.5 GHz when you're playing).
Intellidemand: Based on Ondemand, so a performance governor. Its behavior is linked to GPU, if active GPU (games, etc) then it behaves like Ondemand. When GPU is inactive it will scale max freq differently to save on battery. try it if you use heavy games a lot, make sure you set your GPU highish.
Interactive performance: very high performance, jumps quickly to high frequencies, no much coming back/staying at min freq.
Zzmove insane: focused on very high performance, probably on par with all the ones this far down in the list. Probably better if used in combination with zzmove hotplug, it probably is much better at saving a little bit of battery when phone idle/suspended/screen ON but not doing much.
Slim: Very performance oriented, no battery saving features at all. A new governor from the cm branch and the slimrom project. A performance optimized governor. Found on newer devices only such as the One Plus One. This CPU governor will fall back to be the performance governor if very high load is detected.
Wheatley: Based on Ondemand, so a performance governor. It simply increases C4 state time of the CPU to save on battery. Might be more battery friendly than slim, but hard to say, these are not designed with battery in mind, just efficiency. Slim is more modern (I think) so would be a better choice in my opinion, but I have really tested them.
Ondemand: One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. But it is not very efficient for performance and certainly pretty bad for battery. Frequency variations are very large. Seems to lie somewhere between interactive standard and performance but you would probably not really notice the difference. I am putting it here because it has less battery savings and modern performance features than its derivatives (slim, wheatley).
Performance: keeps the cores at max frequency. Obviously the best for performance and the absolute worst for battery. Good governor for running benchmarks if you want to study power consumption, etc as it is independent of hotplugs and everything else.


*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

Hotplugs:

Boeffla kernel does not have a large array of hotplugs, but zzmove native hotplug is a great combination with zzmove governors, it will help focus the behaviors of those governors to what they were intended to do. So choose that one if you have a zzmove governor.

Optimized: focuses primarily on battery saving rather than performance, with 1 core max on suspend state (most of the time), but this is NOT a battery saving hotplug, just the more battery saving one here. Could be an alternative to zzmove native hotplug for zzmove battery oriented governors (try and see). Pick this one if you want a battery or balanced lifestyle and are not using zzmove governors.
Default: a balanced hotplug almost by definition. Use this one for performance lifestyles (or balanced with performance focus) if you are not using zzmove governors.
zzmove native: If you use zzmove governors, use this hotplug, it is built to work in conjunction with the governors and will have both performance and battery savings features based on your choice of zzmove governor (however, if you use zzmove battery governors you might want to try optimized hotplug and compare). It is an aggressive hotplug, enables fast scaling of multiple cores for heavy loads but also focus on suspended state battery saving (1 core max). It will save more battery
X core min/max/exact: these hotplugs simply set the minimum, maximum or the exact number of cores active. Of course 1 core only is very battery friendly and 4 cores is very bad for your battery and great for performance. Play around with these if you wish, they are good for running benchmarks when setting the exact number of cores you want to test.

*******************************************************************************************************************************************************************
*******************************************************************************************************************************************************************

Recommendations:

- There is a dedicated thread HERE.

- Boeffla himself: does not use a single setup but varies it. More common would be Interactive gov, max cpu 1,947, noop scheduler, touboost 1294, GPU max 330 MHz.

My recommendation for you to try, performance with battery saving:
NOTE: I am in the beginning stages of trying these configurations. Feedback is welcome and encouraged!
- This is my current trial setup. Set profile to "default".
- Max freq = 1497 MHz || Governors = zzmove performance || HP = zzmove native default
- (I have not tested other similar combinations, feel free and let me know).
- GPU: max speed = 389 MHz || min speed = 27 MHz
- touchboost OFF
- You can set higher frequencies than 1.5, but just try it this way anyway.

Battery Extreme: example from here. Credit @raybit10. CM12 ROM, but should apply to CM11S.
- Max freq = 1,574 || Governors = zzmove battery extreme yank || HP = zzmove native default
- GPU: max speed = 200 MHz || min speed = 27 MHz
- Additionally: Scheduler Zen, readahead 1408, touchboost 1036 MHz, Swipe screen to wake ON, Android logger OFF
- Disable all animations or you will get stuttering, lack of smoothness.
- BEWARE: undervolting light. ONLY APPLY UNDERVOLTING IF YOU KNOW WHAT YOU ARE DOING.
- 10-12 hours SOT achieved with tasker, greenify, massive de-bloating of unused apps.



Battery friendly : Max freq = zzmove battery plus/yank/extreme yank or intellimm or smartmax || HP = zzmove native default or optimized
- GPU: max speed = 578 MHz || min speed = 200 MHz
- Additional tweaks: increase sample rate, touchboost freq

 

[bloof]

GOVERNORS AND HOTPLUGS - SOME VISUALS​

And discussions​

I ran combinations of governors (and some hotplugs) in Vellamo benchmarking tool in an uncontrolled test, purely for comparative purposes, using the "single core" test.
Uncontrolled means the tests were not carried out in the exact same situation each time, this happens mostly because cores heat up during tests and if you do not wait long enough then next test will not be under similar conditions. Also, in between test (or even during) some apps might have started, some RAM be used, and many more things could have changed.

I do not exactly how Vellamo chooses to represent the cpu usage in its "single core" tests, as there are obvious influences of hotplugs and other things.

All that being said, these tests are probably not reproducible exactly by other people, but I would suggest you do your own tests with your kernel to find out more about your various governors, hotplugs and combinations thereof.
I DON'T CARE ABOUT THE SCORE ITSELF! If you control your tests more you might look into some of the score details (example: I/O, etc) and learn something, I did NOT do that.
However, I found the following very useful in visualizing governors and hotplugs.




**************************************************************************************************************************************************
**************************************************************************************************************************************************

GOVERNORS (based on BOEFFLA):

Setup:
- governor: as per name indicates
- hotplug: zzmove native default
- cpu max: 2.8 GHz
Just for reference:
- I/O scheduler: FIOPS
- GPU: 389 MHz

How to read the graphs:
They simply represent 6 different tests that Vellamo carries out in this benchmark. For each, they represent time in state for various cpu clocks, adding all cpus together.
I don't think the large dots are to scale, by that I mean that once they are a certain size they cannot get bigger, so a large dot at min frequency might not mean the same time spent as the same size large dot at max frequency. I just don't know.
So the way I read them is as follows: (again, this is how I read them, if you have other ideas please let me know.
- IMPORTANT: remember that using different hotplugs will change these graphs behaviors (I checked), so please use these comparatively only for your own set ups.
- look for large dots at low frequencies: the more there are, the more battery friendly the governor, even if there are a lot of large dots at max frequency.
- look for dots between min and max frequency: the more there are the more the governor uses all available frequencies steps. This usually means it is less aggressive and would be good for balanced styles with the phone doing a lot of small tasks (playing around with your phone). If a governor does NOT have a lot of small dots between min/max frequencies then it is very aggressive in going to max and can be very good as a balanced style using "performance governor" + "battery hotplug" and underclocked CPUs.
- look for large dots at max frequency: do not be fooled by large dots at max just below highest frequency, that's an artifact of the uncontrolled tests where the cores were probably a bit hotter to start with. Anyway, the more large dots at the top, the more performance driven the governor is of course. But you have to look at the dots at min frequency and the dots in between min/max to really judge a governor as pure performance as most governors will have large dots at the max frequency.

You can easily pick out the Battery versus the Pure Performance governors
Look at intellimm versus Interactive Performance for example.


In alphabetical order.

**************************************************************************************************************************************************
**************************************************************************************************************************************************

"MULTICORE" TESTS FOR HOTPLUGS (based on BOEFFLA):

Setup:
- governor: zzmove battery and zzmove moderate
- hotplug: as per name
- cpu max: 2.8 GHz
Just for reference:
- I/O scheduler: FIOPS
- GPU: 389 MHz

These are the "multicore tests" from Vellamo. They take longer to run so I only did a few. For this one I varied the hotplugs to see the effect.
This test is much more susceptible to the fact this is an uncontrolled test (it runs longer, the cores are hotter, leading to even less similar conditions at each test).

As you can see the effect of the hotplug varies with the governor.

RESULTS:
- zzmove moderate: I believe these show for zzmove moderate that the zzmove hotplug brings out the desired performance factor more than the other hotplugs and seem to make it use intermediate frequencies more. Maybe.
I would rank the hotplugs as optimized/default making the governor more battery friendly (as expected, and also not much difference between the two).
The zzmove native hotplug does it more performance oriented, as expected also.

- zzmove battery: the default HP makes it more battery friendly, BUT THIS IS A SHORT TEST! Don't be fooled. The optimized HP is probably more battery friendly in the long run due to its idle/suspend characteristics (1 core max most of the time). The zzmove native hotplug seems to make it less battery friendly, but probably not by much (my interpretation), but once again this is as expected.

**************************************************************************************************************************************************
**************************************************************************************************************************************************

GOVERNORS (based on DORIMANX):

See above section for details on the runs and plots.

**************************************************************************************************************************************************
**************************************************************************************************************************************************

"SINGLE CORE TESTS FOR GOVERNORS (based on DORIMANX):

If not otherwise noted, hotplug is "Default LG"

 

[bloof]

COMPARISONS
2 CORES HIGH FREQUENCY (2.88 GHz)
VS
4 CORES LOW FREQUENCY (1.5 GHz)​

Similar Performance, Lower Power Consumption​

**************************************************************************************************************************************************
**************************************************************************************************************************************************

SETUP:

Running the great app trepn from qualcomm to monitor power and core frequencies.

For each case:
1. Monitor System with trepn
2. Launch PCMark and run "Work Benchmark"
3. When done, go to Vellamo and run "Multicore" benchmark
4. When done, end System Monitoring with trepn
5. Also for each case run a baseline power consumption (trepn does consume a lot of power): run system monitor and do nothing on the phone. This enables taking out trepn for comparison.

Caveat: I didn't have time to run these in perfect controlled manner. Some heating issues could have come in, some extracurricular apps been launched in the meantime, and some timing issues since I did this by hand.
However, I did wait about 2 hours between runs, and the tests being about 10 minutes removes some of the timing issues.


**************************************************************************************************************************************************
**************************************************************************************************************************************************

Case 1 - 2 Cores at High Frequency:

Setup:
- OnePlus One running Boeffla kernel
- Intelliactive governor
- CPU max frequency: 2.8 GHz
- GPU max frequency: 462 MHz
- Hotplug: "2 cores exact" this also means that cores do NOT go to idle when done with their tasks


Results:

The first graph below show the frequencies for each core during the entire test. As expected 2 cores are never switched on. The other 2 follow the exact same scaling and load (pretty much).

The Second graph shows TOTAL frequency on the left with time (I just added them up) and power on the right as well as cumulative power.

TOTALS:
- Time: 584 seconds
- Power: 14.24748 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 20,001,424,800 (approximate assumption that each data point happens at regular interval, makes life easier)

TOTALS for baseline:
- Time: 316 seconds
- Power: 4.202236(approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 5,183,685,600 (approximate assumption that each data point happens at regular interval, makes life easier)
- Power to subtract for 584 seconds of trepn: 7.766
- Clock Frequencies to subtract for 584 seconds of trepn: 9,579,975,919
- Baseline power consumption per clock: 0.81
- Baseline power consumption per second: 0.0133

=> TOTAL NET POWER CONSUMPTION: 6.48
=> TOTAL NET CLOCK CYCLES: 10.4
=> POWER per clock cycle: 0.623

FULL RUN:

BASELINE:

**************************************************************************************************************************************************
**************************************************************************************************************************************************

Case 2 - 4 Cores at Low Frequency:

Setup:
- OnePlus One running Boeffla kernel
- Intelliactive governor
- CPU max frequency: 1.497 GHz
- GPU max frequency: 462 MHz
- Hotplug: "4 cores min" this also means that cores do NOT go to idle when done with their tasks


Results:

The first graph below show the frequencies for each core during the entire test. As expected 4 cores are always online, no idle core.
core1 seems to have a weird result of going up to 2.5 GHz. Not sure what happened there. graphs from PCMARK and Vellamo do NOT show this.

The Second graph shows TOTAL frequency on the left with time (I just added them up) and power on the right as well as cumulative power.

TOTALS:
- Time: 624 seconds
- Power: 12.45498 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 23,214,439,200 (approximate assumption that each data point happens at regular interval, makes life easier)

TOTALS for baseline:
- Time: 311 seconds
- Power: 3.90047 (approximate assumption that each data point happens at regular interval, makes life easier)
- Clock Frequencies: 7,385,724,000 (approximate assumption that each data point happens at regular interval, makes life easier)
- Power to subtract for 624 seconds of trepn: 7.826
- Clock Frequencies to subtract for 624 seconds of trepn: 14,818,944,617
- Baseline power consumption per clock: 0.53
- Baseline power consumption per second: 0.01254

=> TOTAL NET POWER CONSUMPTION: 4.629
=> TOTAL NET CLOCK CYCLES: 8.39
=> POWER per clock cycle: 0.552



FULL RUN:

BASELINE:

**************************************************************************************************************************************************
**************************************************************************************************************************************************

Conclusions:

Baselines:
- Difficult to compare since anything could have been happening to the phone while this was carried out (emails, syncing, etc).
- However, 2 cores at 2.8 GHz show higher consumption. Since is true: 2 cores were idle at 0 whereas the 4 cores baseline had all cores switched ON. Allowing cores to go back to idle would have favoured the 4 cores case and the difference in power consumed would have been greater.
- I could remove all 300 MHz frequencies and redo everything but I won't, don't have time.


Power consumption:
- I will assume that each run performed the exact same tasks.
- Without removing baselines, the 4 cores at low frequency consumed 13% less power
- Removing baselines, the 4 cores at low frequency consumed 30% less power
- However, the 4 cores at low frequency took 7% longer to achieve the task


It would be great if some of you could test this in your own setups for daily life! And let me know how it goes.

 

[bloof]

BATTERY SAVING TIPS AND SMOOTHNESS TIPS​

RULE NUMBER 1: There are no miracles when it comes to this. It is always a compromise, on performance for battery savings, and on animation and beauty for smoothness/lag-free.
RULE NUMBER 1b: However, I believe there are ways to achieve the same performance with less battery consumption.
RULE NUMBER 2: If you play intensive games (either AI or graphic intensive), expect 1% battery drain per minute.
RULE NUMBER 3: There is not much you can do about RULE No 2. You either have a longer game (AI takes longer to respond) or worse visual experience (lower Frames Per Second).

See attached picture of relative power consumptions of various aspects of the phone in idle (on, but no apps running) and suspended (off).
Screen and network are the worst offenders as everyone knows.

However, this is without apps running. Depending on what you use your phone for your battery life will vary greatly.
Battery unfriendly tasks:
- intensive gaming (either graphic intensive or AI intensive).
- photo/video taking, editing, viewing (ie: looking at your photos, zooming, scrolling, panning, etc). However, watching videos is NOT a very intensive activity.
- internet browsing, especially with 20,000 tabs open.
- downloading, syncing (folder sync, utorrent, etc).


************************************************************************************************************************************************
************************************************************************************************************************************************
SMOOTHNESS AND LAG-FREE:
If you want a lag-free experience, the most important aspect apart from CPUs and GPU is to remove the useless extras, but with the machines we have (G2, OPO) you can actually have it all!

Home Screen:
- Home screen lag: avoid using the default launchers (LG default or OPO Trebuchet). These are horrible, lack customization and are much worse than the good launchers out there. Default launchers are terrible. Some launchers such as themer use very large widgets and can have some lag.
- Animations: remove completely, or reduce animation speeds in "Settings => developer options => animation scale". You can also usually reduce/remove animations in your launcher's settings (apex, nova, buzz, etc).
- Xposed framework: avoid using theme related hacks, statusbar/navbar, etc. It is more battery and performance friendly to simply apply a MOD, but it is more of pain to do so.
- Theming engines: the CM theming engine is fantastic, I use it extensively. However, you will notice improved home screen performance if you simply have the default theme.

Applications Launching and Loading:
- See the rest of this thread.
- Use a good kernel, they include re-written drivers/code that will make your machine better.
- Use aggressive governors that scale quickly to max freq.
- Use touchboost options in your kernel.
- Use 2 cores minimum for your hotplug, this is the least battery-friendly option.


************************************************************************************************************************************************
************************************************************************************************************************************************
BATTERY SAVING TIPS:

You will find ten million pages on this on the internet. I will not repeast what you can find in under 1 minute using google.

Screen brightness:
The biggest culprit is of course your screen. The power consummed by the screen raises quickly with brightness, it is close to linear in theory, but in practice I do not believe that brightness % is a linear scale on the phones, your brightness slider does NOT cover the whole range, your hardware CANNOT cover true black to true white, etc. See below for how some phones take care of low level brightness.

See attached picture of brightness vs power usage. A phone brightness slider will not cover the whole range.

Reduce your brightness setting to something useable (no point destroying your eyes to save battery), you'd be surprised that 50-70% brightness works very well (for LG G2). It depends on your machine, your eyes and what you do with it. For OPO there is no brightness %, mine is almost a third to the left and brightness is perfectly fine. The OPO also has a very good Auto-Brightness engine.

However, turning your screen brightness to a very low level does not necessarily reduce power consumption. The hardware (LEDs, whatever) cannot produce light levels that are so low and the phone will simply display a more or less dark grey layer over the screen to reduce the brightness. That does not reduce power consumption AT ALL. It doens't mean they're useless settings, they are still useful at night for example to reduce eye strain.

Some machines have very good "auto-brightness" engines, others have crappy ones. Try them if you want.

You can play around with your phone's brightness and take screenshots of a black/white picture then use a photo editor app to see what the color is of the white that is now grey. Use the 00 (black) to FF (white) as a scale and use that to see how much % reduction. See if that matches your brightness level percentage reduction.


Network settings:
The network, wifi or LTE or GSM, will also use a lot of power in idle (ON, but no apps running) or suspended state (OFF).
- The signal quality is the most important part of this. If you are on the edge of a wifi network your phone will drain battery quite quickly trying to maintain a connection.
- Airplane mode can help if you don't need a connection.
- Move closer to a tower.
- Switch off wifi when you are out and about.
- Play around with your TCP NET CONGESTION settings, but that will probably not do much.

Kernel settings:
- UNDERCLOCK!!!!!!!! You don't need that 2.8 megagigacrazyhertz.
- Also underclock your GPU, unless you play stupidly intensive graphic games, especially the min frequency. Your video playback will NOT be affected if you underclock your max GPU frequency, but you might have more lag in forward/reverse scanning.
- GAMING: have a charger nearby. But also play with kernel settings, there should be a level at which you can have decent FPS with some power consumption reduction. Here I would actually recommend some benchmarking tools to test your FPS for various kernel settings, as that would be close to your real world user experience.


Greenify:
Use it.


Task killer apps:
Use the automated killing features if you want, nothing wrong with that. Does create wakelocks on idle, but probably saves more battery in the end. I never measured.
It might even save on wakelocks by killing apps that didn't die properly and are still waiting for something and keeping your phone awake.


************************************************************************************************************************************************
************************************************************************************************************************************************
Further Reading:
There are about ten million pages dedicated to this on google.
For Dorimanx users, (but also some good tips for others): The Dorimanx Q&A thread in general, tehbigbug write this.
For Boeffla users, it is of course very useful to read the main thread and linked FAQs.

 

[bloof]

TCP NET CONGESTION​

A very quick description of some TCP net congestion algorithms and especially how to find out which one works for you.


TCP Congestion Avoidance Algorithms:

You can find more detailed descriptions here for example, or here.
(Credits: richteralan, other linked in his/her post)

Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.

Reno:
Basically the same as Taho, but.. if 3 of the same packets are received, it will halve the window, instead of reducing it to one MSS. It changes the slow start threshold equal to that of the congestion window.

Vegas:
One of the smoothest (next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.

Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.

Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.

Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date."

**********************************************************************************************************************************************************
**********************************************************************************************************************************************************
WHICH ONE TO USE?

It all depends on your local network situation. It might vary from your home to your local jail or work place.

Only one way to find out: test your internet speeds.
Credits: Dorimanx:
"you need to run net speed tests with each protocol at least 3 times to compare the average, and use best performing protocol for YOUR network."

Don't be surprised if you end up using CUBIC or WESTWOOD.

 

[bloof]

I/O SCHEDULER​

I don't actually know much about this, so will just repeat what I see elsewhere. However, all tests I have done were not as conclusive as I would have hope.
This will not change your life. Don't expect I/O scheduler to have any drastic effect on your phone experience unless you've been using a crappy one.

*************************************************************************************************************************************************************
*************************************************************************************************************************************************************

SUMMARY:
ROW vs FIOPS:
FIOPS is better performance and battery but not for multitasking.
ROW is a very good balanced scheduler.
THERE ARE OTHER OPTIONS, see below.

What matters:
- external SD card or not
- multitasking or not
- whether you care about battery life or not
- your machine

*************************************************************************************************************************************************************
*************************************************************************************************************************************************************

WHICH ONE TO SELECT?
I will link to someone else's work:
http://androidmodguide.blogspot.co.uk/p/io-schedulers.html
credit to the author, who I am sure is lurking around here in xda.

Please read his article.

Results (again, not mine):
Recommended IO schedulers:
For everyday usage:
- SIO (My personal favourite)
- NOOP
- CFQ (Third choice)
- Deadline (Forth choice)
- ROW (My second choice)
- ZEN


For battery life:
- SIO (First choice)
- FIOPS
- NOOP (Second choice)
- ROW (Third choice)
- FIFO


For gaming:
- Deadline (First choice)
- CFQ (Second choice)
- ROW (Third choice)


For performance(Benchmarking):
- VR
- SIO (Third Choice)
- Deadline (Second choice)
- FIOPS (First choice)


For multitasking:
- BFQ (Third choice)
- Deadline (Second choice)
- CFQ (First choice)


IO Scheduler Comparison:
Overall performance:
BestWorst
FIOPS> Noop > ZEN >SIOplus > SIO > ROW > Tripndroid > VR > Deadline > BFQ > CFQ

Multitasking performance:
Less AppsMany Apps
Noop < FIOPS < SIO < SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < CFQ < BFQ


Battery life:
Best Worst
Noop > FIOPS > SIOplus > SIO > ROW> ZEN > Tripndroid > Deadline > VR > CFQ > BFQ


*************************************************************************************************************************************************************
*************************************************************************************************************************************************************

Read-ahead:
http://andrux-and-me.blogspot.fr/2014/06/various-conditions-and-io-performance.html
The usual answers I see seem to indicate that you should leave at default, whatever your kernel maker seems to think is best.
Having too high a number can lead to issues if the I/O needs to read/write a lot of things on the fly with streaming going on and multitasking.


*************************************************************************************************************************************************************
*************************************************************************************************************************************************************

Further Reading:
If you use google you will easily find a lot of material on I/O schedulers.
Here is a page with some descriptions and advantages/disadvantages: http://tinzdroid.blogspot.co.uk/2012/07/android-kernel-governors-modules-io.html
Another link: http://androidmodguide.blogspot.co.uk/p/io-schedulers.html

 

[d00lz]

UPGRADE/DOWNGRADE bootloaders/recovery/kernels and flash ROMs​

THIS GUIDE WAS WRITTEN FOR DORIMANX KERNEL AND LG G2, BUT THE STEPS SHOULD BE THE SAME FOR ALL.

JUST MAKE SURE YOU USE THE RIGHT FILES FOR YOUR DEVICE!!!!!!!!!!!​

I WILL REPEAT: MAKE SURE YOU USE THE RIGHT FILES FOR YOUR SPECIFIC PHONE!!​

Files for LG G2: http://www.dorimanx.com/LG/

NOTE: This is for D802, if you have another variant just substitute "flash KK bootloader" or "flash JB bootloader" with the following (from OP):
"I have created ONE flash zip with all that needed for D802, including stock stuff from 20D KDZ image.
find for your model, extract needed partitions as in my zip, replace and flash.
too hard??? leave it alone and keep using JB bootloader till you find mind power to do it".
This means: download the D802 KK bootloader flash file, download your model's kdz, extract the files needed (same as in the D802 KK booloader flashfile), replace them in the zip and flash or install everything manually.
Same for JB bootloader zip file.
If you are reading this then you know how to do this. If not then just stick to JB or buy a D802.

IMPORTANT: if you do NOT know how to unbrick a phone through download mode and installing custom KDZ and all the rest of it then please don't blame anyone. There are threads in xda for un-bricking.


************************************************************************************************************
First I repeat the steps for installing BUMPED KK bootloader:
Phone status: non-bumped recovery, non-bumped kernel, JB bootloader, stock-based ROM
You want to: install KK bootloader
1) reboot to recovery
2) flash bumped TWRP 2.8.1.1
3) reboot to recovery
4) flash Dorimanx 9.1 kernel
5) flash KK bootloader
6) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************

IMPORTANT: After you have installed BUMPED TWRP, you NEVER need to replace it with non-BUMPED version. It works with JB bootloader too.


************************************************************************************************************
Installing a new/different stock-based JB ROM (or dirty flash or clean flash existing ROM) but want to keep KK bootloader:
Phone status: Bumped recovery, bumped kernel , KK bootloader , stock-based ROM (ie: you just did all the steps above)
1) reboot to recovery
2) flash stock-based JB ROM as per OP (inc wipes if necessary)
3) flash BUMPED dorimanx 9.1 kernel BEFORE REBOOT TO SYSTEM
4) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************


************************************************************************************************************
Returning to JB bootloader with your current ROM:
Phone status: Bumped recovery, Bumped kernel, KK bootloader , stock-based ROM
1) reboot to recovery
2) flash JB bootloader
3) reboot to system
You now have: bumped recovery, bumped kernel, JB bootloader, same ROM as before
************************************************************************************************************


************************************************************************************************************
Installing JB AOSP ROM (with non-bumped kernel):
Phone status: Bumped recovery, Bumped kernel, KK bootloader , stock-based ROM
1) reboot to recovery
2) flash JB bootloader
3) flash JB AOSP ROM as per OP (inc wipes if necessary)
4) reboot to system
You now have: bumped recovery, non-bumped kernel, JB bootloader, AOSP ROM
************************************************************************************************************


************************************************************************************************************
Installing stock-based JB ROM and go to KK bootloader from AOSP ROM:
Phone status: Bumped recovery, non-bumped kernel , JB bootloader , ANY ROM
1) reboot to recovery
2) flash stock-based JB ROM as per OP (inc wipes if necessary)
3) reboot to system
4) install ROM, let it settle for 5 minutes
5) reboot to recovery
6) flash BUMPED dorimanx 9.1 kernel
7) flash KK bootloader
8) reboot to system
You now have: bumped recovery, bumped kernel, KK bootloader, stock-based ROM
************************************************************************************************************

PS: thanks to vpro97 for checking and Dorimanx of course for making all this happen

 

[bloof]

BENCHMARKS​

Please don't. Nobody intelligent gives a crap.


"Benchmarking:
The next possible answer for measuring CPU speed and overall system performance is benchmarking.
Unfortunately, benchmarks are necessarily flawed. A benchmark can only prove how quickly a system runs the benchmark. A benchmark cannot show how quickly a system will run a user’s mix of applications in the real world."
(http://www.tech-faq.com/cpu-speed.html)

"With that said, synthetic benchmarks by definition are not real-world applications and they can be misleading and abused. It is ideal to test applications that represent end user experience".
(qualcomm.com/power-versus-performance-management-cpu)

Benchmarks have their uses in comparative studies under same conditions, but they will not tell you anything about how to setup your governors/hotplugs/frequencies.
Example of the proper use of a benchmarking tool (antutu, and you won't see a single score): http://www.bu.edu/peaclab/files/2014/06/Cotler-RISE-Poster.pdf

The best end-user experience benchmark is yourself. If you can't tell the difference in day to day use then why bother with more battery consumption?

If you want to test the thermal engines, undervolting reliability (please don't undervolt), use something like "stability test". You won't get a score to post on facebook but you will actually learn something useful.

******************************************************************************************************************************************************
******************************************************************************************************************************************************
If you insist:

Settings for facebook-friendly benchmark scores:
1. your thermal engine is your worst friend. Disable it/increase limit and destroy your cpus, or (SERIOUSLY) run your benchmark with the phone in the freezer/fridge (leave it there a couple minutes before starting, maybe use a ziplock bag so it doesn't get wet). BUT DON'T FORGET TO NOT BLAME ME FOR ANYTHING THAT HAPPENS TO YOUR PHONE.
Note: I never ran my phone in freezer, but have done many times in the fridge when doing TWRP backups or flashing ROMs to speed up the process and avoid overheating/pixel destruction.

2. set a hotplug with ALL CORES ONLINE all the time. Like "4 cores min".

3. set the governors to "performance", this usually sets the cpus at their max frequencies forever.

4. set the max frequency to the highest possible frequency.

5. don't forget the GPU, this is a big score for antutu and others. Set min GPU to the max possible allowable for your kernel and the max GPU to the max possible.

6. DON'T kill all the tasks before you start a test, the phone will be busy restarting them. If you want to kill tasks, then please do but then wait a few minutes before doing your test. Same if you reboot, wait several minutes after reboot to start your test.

7. And then don't forget to NOT BLAME ME.

 

[bloof]

COOL TOOL custom labels GPU freq, CPU temp, CPU 1/2/3 on/off state​

I have put in one place three custom labels that are often asked for but answers are spread through several posts. I hope this will help future people find everything in one place.

I did NOT do these myself, just reporting them here. Credit goes to the people who created cool tool and

App: cool tool from play store
Quick tutorial: you need to go to Labels -> Fine tuning (at the bottom) -> Click on Custom label -> enter settings as shown below
You can modify the prefix and postfix as you like.
************************************************** ********
1. GPU freq
Prefix: GPU:
Postfix: MHz
Path: sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/gpuclk
Regex: (\d+)\d{6}
Replacement pattern: $1
************************************************** ********
2. CPU temperature:
Prefix: T:
Postfix: *degrees symbol* C (or just "C")
DORIMANX KERNEL on LG G2: Path: /sys/class/thermal/thermal_zone5/temp
BOEFFLA KERNEL on OPO: Path: /sys/class/thermal/thermal_zone2/temp
Regex: (\d+)\d{3}
Replacement pattern: $1
NOTE: zone5 is global temperature tested by driver. zone0 is cpu0.
************************************************** ********
3. CPU 1/2/3 on/off state
Unfortunately it is not possible yet to display CPU1/2/3 freq. What can be done is to display a "0" or "1" state which corresponds to "OFF" and "ON".
Prefix: CPU1:
Postfix:
Path: /sys/devices/system/cpu/cpu1/online
Regex:
Replacement pattern: $1
NOTE: replace "1" in prefix and path to "2" or "3" for CPUs 2 and 3.
************************************************** ********

keywords for search results:
cool tool, cooltool, GPU freq frequency, CPU temp temperature, CPU online state on off, custom labels

 

[Tinchoska]

Awesome dude!!!!!! Can I suggest something? Alucard hotplug and Ondemand plus gov is more battery friendly than Alucard/Alucard...

 

[tehbigbug]

@bloof

Check out the post linked in my signature. I'm sure there are a few things there that you could add to post #5.

 

[d00lz]

@bloof

May I add a very helpful link, Android Kernel-Governors, Modules, I/O Schedulers. It has heaps of detailed, in-depth information about Kernel-Governors, Modules and I/O Schedulers from a very Beginner-Friendly point of view .

 

[bloof]

OK, I am done for now, first draft of this thread is UP. Please provide comments/feedbacks/additional knowledge.

have fun

 

[Saber]

Hi there,

I'm gsstudios and I'm the creator of the android modders guide website (androidmodguide.blogspot.com). Please mention my name in the OP. This isn't a fake message that I've sent, as I have referenced on my website that it was created by myself.

Thanks, gsstudios

 

[bloof]

Hi there,

I'm gsstudios and I'm the creator of the android modders guide website (androidmodguide.blogspot.com). Please mention my name in the OP. This isn't a fake message that I've sent, as I have referenced on my website that it was created by myself.

Thanks, gsstudios

DONE and thanks for that guide, the most up to date I found. When creating this thread I checked so many sites and links I ultimately lost track and gave up on re-opening every link.
I'm glad you mention it and happy to give credit of course, it needs to go where it is due.

 

[iall5tar]

Well done buddy!

Appreciate your effort to make this thread awesome!

This is a must read for everyone!

Hats off!

 

[60nine]

this shoud be stickied - well done @bloof ...