Right i am not going to bore you with long ass intros or long essays on how to do this and how to do that. All i did was share my results on a thread and people started messaging me about my settings and what configurations i use. So i will make it all simple for you. I am opening a thread so you can see what settings i am using and use it as a guide and adjust them or use my own settings if you want to get the best out of your battery and enjoy more your baby. Plus this thread is for you guys to stop private messaging me as i am getting loads of messages and hardly have time to reply to you all.
First off and call it a disclaimer if you want, what WORKS on my phone might not work for yours. So as i said above, use my settings if you want, but if you have problems then tweak them to an effect your phone runs smoothly. Infact with my settings you get the balance of both worlds, Performance and battery life. But let me say this i am just providing you guys with my settings and what works for me. Now if you get any problems or errors which you should not do not come here crying as i have not forced these settings on anyone. The below settings are for people like myself who do not know how to use a script to tweak a governor, and by having this app makes life a lot easier and by me helping with my settings i hope it can provide the balance of good battery life and performance to people.
I know Geko95gek has his MagicConfig thread and my thread is different to his, as my thread is just to help people with the Lulzactive app settings and give them a guide on how to start and use it and how to get the best out off it. His is more to do with voltages of cpu and GPU. You can use his MagicConfig and use my Lulzactive apps settings if you want. Big shout out to him for his magic.
Please also follow the bottom link for a bit more in depth info on a How to guide for undervolting.(many thanks to Eric-filth)
http://forum.xda-developers.com/showthread.php?t=1532999
Anyway here are the settings that i use and please use as a guide:
Lulzactive app Settings:
inc_cpu_load: 75%
pump_up_step: 3
pump_down_step:2
screen_off_min_step: 4,@200MHz
up_sample_time: 50000
down_sample_time: 30000
debug_mode: 0
Setting up your Lulzactive app with your configurations:
To be able to use the above settings as already stated you need the Lulzactive application were it can be found here:https://play.google.com/store/apps/details?id=com.tegrak.lulzactive&hl=en.
Once you have installed it then you need to have Voltage Control which i recommend or any other cpu tuner program installed on your phone like(SetCpu, NoFrills, Tegrak OC) to be able to set lulzactive governor as default.
Once you have done that then go ahead and input my settings or your own. The exact way i have it laid out, is the same on the app.
Once you have done inputting the settings always make sure you have SET ON BOOT ticked.
Come out of the app and reboot. Wait for the phone to load up properly then go back into the application to make sure the settings have been set up properly and stayed. And that is it. :
Voltage Control Configuration:
*Governor: Lulzactive (of course)
*Scheduler: VR - Noop
Voltages
1200Mhz - 1150mV
1000Mhz - 1050mV
800Mhz - 1000mV
500Mhz - 950mV
200Mhz - 900mV
100Mhz - 850mV
GPU ControlLow power state - High power estate114Mhz - 950mV / 267Mhz - 1050mV
Now i will present to you settings that you can use with a different governor and scheduler. Call this Rock Solid Config v1.1 if you like.
Voltages
1200Mhz - 1175mV
1000Mhz - 1100mV
800Mhz - 975mV
500Mhz - 950mV
200Mhz - 850mV
100Mhz - 850mV
GPU Control:Low Power state: 133Mhz - 900mV
High Power State: 267Mhz - 1000mv
Scheduler: Noop
Governor: Conservative
Misc Tweaks: Ext4 Boost- Sched_Mc
So there you have it. Those are my settings that i use currently with NEAK kernel and work like a charm for me. Feel free to use my configuration if you like but please consider that everyones phone is different. So feel free to use mine as a guide and either feel free to undervolt more if you like or if you find that you are getting freezes then up the steps by either 25mV or 50mv
Feel free to post your results here as i would like to know if my settings work or not and also your battery results to show if my settings actually do something towards your battery.
Just a few thanks in order as well i think:
Simone201: for his awesome kernel and configurator.
Tegrak: For his awesome lulzactive app(makes my life alot easier to tweak it this way instead of scripts)
Gokhanmoral: just for his siyah kernel and i have all the time in the world for that guy as he is a legend in my eyes
Geko95gek: for being just a crazy ass Yoda and providing everyone with his MagicConfig
GC and LeoMar75: For the awesome rom
So_ony: cause i have to say it was her idea behind this brainchild of a thread.
Droidphile: For his awesome thread regarding all the information you need regarding kernels
And to you all who keep pestering me for my settings this thread is for you guys.
Information on misc tweaks, plus my favorite governors and schedulers i recommend
Abit more info regarding what are the misc options in the NEAK configurator application. (Many thanks to Droidphile for all the information)
Q. "What are these modes: IDLE, LPA and AFTR?"
A. Between screen off and deep sleep states, there are some idle modes supported by cpuidle driver. They are IDLE aka Normal Idle, LPA aka Deep Idle and AFTR aka ARM Off Top Running. Race to idle by CPU is implemented for power management.
In IDLE state, CPU is not clocked anymore, but no hardware is powered down.
In deep idle (LPA),a state after IDLE, again, the cpu is not clocked anymore like we guessed but some parts of hardware are powered down. Deep idle brings in real power savings and there is no need of putting a hard limit to frequency during screen-off; using a screen-off profile. (Good practice is to use a governor with built in screen off profile, than using an user-configured screen-off profile by putting a hard limit on frequency). Deep idle is not used when device is entering deep sleep and also when device is woken from suspend/deep sleep. While entering/exiting DEEP IDLE, CPU is set statically to SLEEP_FREQ and is not clocked below or above until it exits this state.
AFTR is a patch to support Top=Off mode for deep idle. Level 2 cache keeps it data during this mode.
We can have IDLE or AFTR modes with LPA enabled or disabled. (Obviously it is not possible to have IDLE and AFTR together)
Values:
0: IDLE
1: AFTR
2: IDLE+LPA
3: AFTR+LPA
Q. "What idle modes are recommended for power saving? How do i change it"?
A. Recommended for power saving is to enable AFTR and LPA, ie value 3
Example:
echo "3" > /sys/module/cpuidle/parameters/enable_mask
Q. "What is sched_mc?"
A. Linaro team invented sched_mc or Schedule Multi Core to make process scheduling multi-core aware. ie, utilize both cores wisely to save power and balance performance. Even though sched_mc is sort of an alternative to cpu hot plugging, we can use sched_mc with the default hot plug mode.
Possible Values:
0 : No power saving load balance, default in our exynos4210 Soc.
1 : Fill one thread/core/package first for long running threads. In our single-CPU dual-core device, multithreading does not come into picture, so load balancing is almost redundant to hotplugging.
2 : Also bias task wake-ups to semi-idle CPU package for power savings. (Bias new tasks to cpu1 if cpu0 is mostly filled with running tasks). This is 'overloading' CPU0 first.
Q. "What value is recommended for sched_mc?"
A. 1) If you find advantages to sched_mc, use sched_mc=1 for a possible battery saving. Anyhow since load-balancing is reduntant on hotplugging, it may not have any advantage on exynos chip.
2) For performance use 2. But do remember that loading CPU0 and leaving CPU1 can not do justice to hitting deep idle states sooner since second core can not enter deep idle. So extra performance or no performance, value 2 will drain some more battery, in the context of delayed didle.
3) To do justice to hotplugging, use value 0.
Example:
echo "0" /sys/devices/system/cpu/sched_mc_power_savings.
Schedulers that i recommend to use. Again massive thanks to Droidphile for the information.
Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
Governors that i recommend to use. Information again by Droidphile.
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
Do not forget to enable the Lionheart tweaks you must have Conservative governor enabled through the configurator application and then select Lionheart tweaks
Links
*N.E.A.K kernel:
http://forum.xda-developers.com/showthread.php?t=1411788
*Droidphile thread regarding more info about governors and schedulers and more tweaks
http://forum.xda-developers.com/showthread.php?t=1369817
*Ext4 Optimization information
http://kernelnewbies.org/Ext4
*N.E.A.K Configurator App.
https://play.google.com/store/apps/details?id=com.neak.NEAK_Configurator
*If you want to try alternative settings from mine and try settings near stock default go to the following thread by Geko95gek and check his great thread out.
http://forum.xda-developers.com/showthread.php?t=1466017
And your voltage conttol settings??
Tapatalk on SGSII (Powered by CheckROM RevoHD V6, SiyahKernel 2.6.12 + MagicConfig 0.3.1, Modem KI4)
edwardeutsch said:
And your voltage conttol settings??
Tapatalk on SGSII (Powered by CheckROM RevoHD V6, SiyahKernel 2.6.12 + MagicConfig 0.3.1, Modem KI4)
Click to expand...
Click to collapse
start with the MagicConfig mate. That should be good enough.
Great thread to start tweaking with Lulzactive governor. Should make life easier for a lot of people, gives them the opportunity to gain extra battery juice without too many headaches.
geko95gek said:
Great thread to start tweaking with Lulzactive governor. Should make life easier for a lot of people, gives them the opportunity to gain extra battery juice without too many headaches.
Click to expand...
Click to collapse
Thanks mate. And with your magic config people can have the best of both worlds. Shame we can't merge the two...Anyway thanks mate much appreciated for your kind words
Why pump up 4 steps? For performance or? The rest of the settings i can see the meaning in, but why pump up four steps?
Else, awesome thread! God starting point for many!
Pennywice said:
Why pump up 4 steps? For performance or? The rest of the settings i can see the meaning in, but why pump up four steps?
Else, awesome thread! God starting point for many!
Click to expand...
Click to collapse
Thanks mate...For performance yes but also if you see the other settings you will see they are leaning more towards the battery side. Hence why i wanted to go for a balance between the two if that makes sense. I will be trying different settings and i will provide screenshots of my results and will provide the settings for each result i do.
Stifler69 said:
Thanks mate. And with your magic config people can have the best of both worlds. Shame we can't merge the two...Anyway thanks mate much appreciated for your kind words
Click to expand...
Click to collapse
i see you have listen to me and you have opened a new thread nice mate
so_ony said:
i see you have listen to me and you have opened a new thread nice mate
Click to expand...
Click to collapse
check OP
Stifler69 said:
check OP
Click to expand...
Click to collapse
oh how cute thanks hehe =) geko didn't answer my email :/
your description is short but everything is described very well !
so_ony said:
oh how cute thanks hehe =) geko didn't answer my email :/
your description is short but everything is described very well !
Click to expand...
Click to collapse
any ideas on how to get this thread going please let me know..and glad you liked my OP
so_ony said:
oh how cute thanks hehe =) geko didn't answer my email :/
Click to expand...
Click to collapse
So sorry for the delay. Please feel free to punish me.
I want understand one thing sorry my noobless.
What magic have in magicConfig from geko?
Enviado do meu nokia 3320 modificado por laboratório usando Tapatalk
great...now something to use when im on check and neak...nice work stiffy!!!
Good work Stifler, im trying your magic configuration and it Owns..!! Just right now im experiencing a little more battery drain against just the +conservative+lionheart+ext4+AFTR config.
Ill give it some days with full charge and check.
Stifler69 said:
Anyway here are the settings that i use and use as a guide:
Lulzactive app Settings:
inc_cpu_load: 95%
pump_up_step: 4
pump_down_step:1
screen_off_min_step: 4,@200MHz
up_sample_time: 20000
down_sample_time: 40000
debug_mode: 0
Click to expand...
Click to collapse
Out of curiosity what are the default Lulzactive settings on NEAK 1.4 compared to those above???
Those lulzactive setting seem to be replicated from ThunderBolt! ain't it. Down to the last setting :/
pikachu01 said:
Those lulzactive setting seem to be replicated from ThunderBolt! ain't it. Down to the last setting :/
Click to expand...
Click to collapse
Hey mate. Actually I have never seen you around on any posts sharing these settings or even opened thunderbolt scripts to see how you tweak lulz governor. I have nothing but for respect for you Pika as I see how great you thread is and how popular your scripts are. These settings that I am using are a start up from me from playing around with the app and sharing my findings with friends. If it brings offence to you I will bring it down. But I swear to you I have never used your scripts as one I do not how to use them and two I prefer apps to do the work for me as I hate to many scripts in my phone. I would love your help here if possible on what to help people though
eric-filth said:
I want understand one thing sorry my noobless.
What magic have in magicConfig from geko?
Enviado do meu nokia 3320 modificado por laboratório usando Tapatalk
Click to expand...
Click to collapse
well just take a look at his thread my friend. his voltage control settings are shared nearly by 700 users on xda and have reported nothing but good stuff from it. i do not want to share my settings as i Undervolt quite heavy so my settings would not work with most on here. so i used his thread for people who would ask for settings apart from my lulz app ones.
jermitano said:
great...now something to use when im on check and neak...nice work stiffy!!!
Click to expand...
Click to collapse
Thanks mate. first post settings are just a start up. i will be trying different settings with different kernels and still use Lulzactive as i want to show people my results and they can choose what settings to go for. i will always post a little review as well so users can decide which one to go for.
Honchay said:
Good work Stifler, im trying your magic configuration and it Owns..!! Just right now im experiencing a little more battery drain against just the +conservative+lionheart+ext4+AFTR config.
Ill give it some days with full charge and check.
Click to expand...
Click to collapse
You would get a bit of drain my friend but again it is all about how you have your phone setup and what settings in VC you are using. but hope the settings have some benefit for you though
kersey said:
Out of curiosity what are the default Lulzactive settings on NEAK 1.4 compared to those above???
Click to expand...
Click to collapse
not sure mate.
Battery Optimazatin
Disclaimer alert: I am in no way responsible for any damage inquired while performing any of the changes listed below. This is just an option and it is something I have tried on S3 i9300 international version with success. Results will vary depending on your device
I have NeatRom Lite v1.1 + Siyah Kernal installed on my phone. Samsung's stock kernal has been replaced by Siyah's kernal SGS3v.1.8.4. To tweak the kernal, I installed STweaks (from the market).However if you feel bold you can tweak the kernal using STweaks and also tweak the governor (I am using peqasusq as my defualt governor). Additional tweaks for performance and gamers are avaliabe to Siyah S3 i9300 thread (http://forum.xda-developers.com/showthread.php?t=1709686). Governor tweaks can be performed either via a script in init.d or by SetCPU. I assume kernels with peqasusq can be tweaked with the settings below ( have not tried it out yet). These are my settings below ( they are by no means a rule of thumb). Note if you experience reboots while UV CPU ( try -50Mv or -75Mv).
STweaks settings can now be saved using a STweaks Profiles app by Droidphile (http://forum.xda-developers.com/showthread.php?t=1179809)
Battery Saving Tips
The screen causes excessive battery drain. You will need to reduce your screen brightness to about 30-40% instead of being at automatic.
Disable hepatic feedback
Use a dark back ground. Using a live wall paper wil also drain your battery
Turn WiFi off
GPS or location by network off ( use GPS only when needed)
There are other factors that affect battery consumption on your phone, these includes AutoSync Mail, apps like facebook, Whatsapp, Google + and Maps. You can disable auto sync feature for your gmail or get a better email app. Autostarts App can be used to disabe certain apps from autostarting. Cautiously disable apps, if in doubt don't touch it.
To get an idea of what is causing battery drain (Wakelocks), I suggest downloading Better Battery from the play store (Paid app) and view a dumpfile after 1-4 hours of your phone on idle. Once you have BBS you can determine what you want to disable or enable. If you need additional help reading the file you can head over to BBS thread (http://forum.xda-developers.com/showthread.php?t=1179809)
How to use Autostarts
Once you have this app, you can prevent some of the programs/operations from auto starting even when not in use.
Select the meu option and choose group by application
You can go down the list of apps and disable the notorious apps that you find running during auto starts (Maps, Google+, Facebook, Whatsapp). Here is Karpfenhai's example of how to disable Maps.
I have also disabled apps that auto start when connection changes, power disconnections. Disable apps or background operations can be enabled anytime.
Please note, some might cause havoc when disable do this with caution.
STweaks Settings
Quad Core Setting
SETTINGS (CPU):
CFS (Settings) GENTLE_FAIR_SLEEPERS = On
CPU IDLE Mode = IDLE+ LPA (default)
SCHED_MC = 0
CPU Undervolting = -100mV ( -75 if your phone freezes or reboots)
Max CPU Lock = Quad Core mode
Default CPU Governor = pegasusq
Scaling Max Freq = 1200Mhz
Scaling Min Freq = 200Mhz
SETTINGS (GPU freq):
GPU Freq Step 1 = 108Mhz
GPU Freq Step 2 = 160Mhz
GPU Freq Step 3 = 266Mhz
GPU Freq Step 4=300Mhz
GPU Freq Step 5=333Mhz
SETTINGS (GPU voltages):
GPU Voltage Level 1 = 825mV
GPU Voltage Level 2 = 850mV
GPU Voltage Level 3 = 875Mv
GPU Voltage Level 4 = 900mV
GPU Voltage Level 5 = 925MV
GPU Thresholds
GPU Threshold 1 Up = 70
GPU Threshold 2 Down =60
GPU Threshold 2 Up=70
GPU Threshold 3 Down=55
GPU Threshold 3 Up=80
GPU Threshold 4 Down=65
GPU Threshold 4 Up=80
GPU Threshold 5 Down=75
SCREEN
Touch Boost Level =600MHz (If there is lag try 700MHz)
Default CPU Scheduler = sio/Deadline
Init.d Tweaks
echo "80" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold
echo "60000" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/pegasusq/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/pegasusq/down_differential
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_step
echo "10" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_up_rate
echo "20" > /sys/devices/system/cpu/cpufreq/pegasusq/cpu_down_rate
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/freq_for_responsiveness
echo "50" > /sys/devices/system/cpu/cpufreq/pegasusq/up_threshold_at_min_freq
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_1_1
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_2_0
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_2_1
echo "300000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_3_0
echo "1000000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_3_1
echo "400000" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_freq_4_0
echo "150" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_1_1
echo "150" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_2_0
echo "250" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_2_1
echo "200" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_3_0
echo "400" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_3_1
echo "300" > /sys/devices/system/cpu/cpufreq/pegasusq/hotplug_rq_4_0
echo "1" > /sys/devices/system/cpu/cpufreq/pegasusq/io_is_busy
echo "0" > /sys/devices/system/cpu/cpufreq/pegasusq/max_cpu_lock
note script is only for quad core settings, if used for dual core may cause fast battery drain
Click to expand...
Click to collapse
Dual Core Settings This will should give you more battery savings
SETTINGS (CPU):
CFS (Settings) GENTLE_FAIR_SLEEPERS = On
CPU IDLE Mode = IDLE+ LPA (default)
SCHED_MC = 0
CPU Undervolting = -100mV ( -75 if your phone freezes or reboots)
Max CPU Lock = Dual Core mode
Default CPU Governor = pegasusq
Scaling Max Freq = 1000Mhz
Scaling Min Freq = 200Mhz
SETTINGS (GPU freq):
GPU Freq Step 1 = 108Mhz
GPU Freq Step 2 = 160Mhz
GPU Freq Step 3 = 200Mhz
GPU Freq Step 4= 266Mhz
GPU Freq Step 5=300Mhz
SETTINGS (GPU voltages):
GPU Voltage Level 1 = 825mV
GPU Voltage Level 2 = 850mV
GPU Voltage Level 3 = 875Mv
GPU Voltage Level 4 = 900mV
GPU Voltage Level 5 = 925MV
GPU Thresholds
GPU Threshold 1 Up = 70
GPU Threshold 2 Down =60
GPU Threshold 2 Up=70
GPU Threshold 3 Down=55
GPU Threshold 3 Up=80
GPU Threshold 4 Down=65
GPU Threshold 4 Up=80
GPU Threshold 5 Down=75
SCREEN
Touch Boost Level =600Mz (If you experience a lags try 700Mhz)
Default CPU Scheduler = sio/Deadline
Click to expand...
Click to collapse
Images
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Special thanks to
Siyah for the kernel
Droidphille for correcting my initial governor tweaks
Sale for Neat Rom
Click to expand...
Click to collapse
I prefer to sell my phone and go through all this hassle
Sent from my GT-I9300 using Tapatalk 2
tarif said:
I prefer to sell my phone and go through all this hassle
Sent from my GT-I9300 using Tapatalk 2
Click to expand...
Click to collapse
It is really not as bad as you think. Give it a try
I will try it in a while and will post how it goes. Thanks mate. Keep up the good work
Thx for this interesting post ...but instead of just Uv all frequencies I did uv on each frequencies manually and stress it with set cpu to see if its stable for example im runing 1.4Ghz at 118750mv and can go up to 1.6 Ghz at just 126200mv very stable since I did 25min of stress test on setcpu and since 2days im runing at this speed with that voltage with no problem at all and of course with Siyah kernel
If you guys are interested and I can post all my current voltages at each frequencies
Cheers
Sent from my GT-I9300 using xda premium
G4neStarT said:
Thx for this interesting post ...but instead of just Uv all frequencies I did uv on each frequencies manually and stress it with set cpu to see if its stable for example im runing 1.4Ghz at 118750mv and can go up to 1.6 Ghz at just 126200mv very stable since I did 25min of stress test on setcpu and since 2days im runing at this speed with that voltage with no problem at all and of course with Siyah kernel
If you guys are interested and I can post all my current voltages at each frequencies
Cheers
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
The good thing about this thread is that it is created to share ideas. So feel free to share your settings with everyone. I stressed mine using glbench mark from google play. This settings seemed to work out well without any crashes or SOB . Siyah uses a different mehod so the UV values are not set on boot up. However, the new kernel has the option of uv for any step you want at boot.
Sent from my GT-I9300 using Tapatalk 2
Thanks mate
Enviado desde mi GT-I9300 usando Tapatalk 2
Hi I tried the settings you said above with Siyah 1.8.6 but the phone warmed too! very much! to just use WhatsApp or Kik messenger programs that are not demanding much processing.
I went back to the settings of Stweaks defaut and everything returned to normal.
As for the expense, I have 24 hours of use, 3 hours of screen and 34% of battery.
Very good too, right?
hooliganx said:
Hi I tried the settings you said above with Siyah 1.8.6 but the phone warmed too! very much! to just use WhatsApp or Kik messenger programs that are not demanding much processing.
I went back to the settings of Stweaks defaut and everything returned to normal.
As for the expense, I have 24 hours of use, 3 hours of screen and 34% of battery.
Very good too, right?
Click to expand...
Click to collapse
Strange but I didn't get any of that with my phone. Which of the settings did you use?
Sent from my GT-I9300 using Tapatalk 2
Hi Red Hat,
I'm not having a go (I'm a fellow red), and I know you're trying to help, but steps 1-5 are all complete non starters for me.
What's the point in buying a phone like this if you're going to turn off a bunch of the best functionality? Might as well go and buy something cheaper that doesn't have those functions...
seems a hell of a lot of hassle to go through to get worse battery life than i get at the moment. Just use a stock rom with siyah set at lulzactive and deadline profiles gets me 1d 7 hours with 5 hours screen time. Fine for me.
To avoid this hassle I have bought a spare battery.
Sent from my GT-I9300 using xda premium
skimminstones said:
seems a hell of a lot of hassle to go through to get worse battery life than i get at the moment. Just use a stock rom with siyah set at lulzactive and deadline profiles gets me 1d 7 hours with 5 hours screen time. Fine for me.
Click to expand...
Click to collapse
Ok guys, I am sharing my findings and what I have done to obtain good battery life. This is not a standard or a rule of thumb. For starters, I use my phone a lot and can barely get through a 24 hour day without a needing a charge. So I came up with this and it worked well for me. This is based on what I read from Droidphile and sample from Siyah kernel's battery tweaks. This is my second thread on the issue and it worked well on S2. If you are getting better battery life please share with the rest of us as it will only enable others and myself to learn.
Thanx for the feed back.
Rabangus said:
Hi Red Hat,
I'm not having a go (I'm a fellow red), and I know you're trying to help, but steps 1-5 are all complete non starters for me.
What's the point in buying a phone like this if you're going to turn off a bunch of the best functionality? Might as well go and buy something cheaper that doesn't have those functions...
Click to expand...
Click to collapse
Functionality wise the phone does the same thing it did when I purchased it. Using autostart allows you to stop programs that run in the back ground without when you don't need them. Think of it as an extra hall monitor
Sent from my GT-I9300 using Tapatalk 2
Ehm ehm..! Excuse me!!
I don't know why your guys feeling like getting a good battery life is difficult in this awesome device!
Ultimate rom 7.1 with persues kernel thats all! Nothing much or less than this.
Sent from my GT-I9300 using xda premium
To all my friends wishes of a Happy, Healthy, Successful and a Peaceful New Year
skimminstones said:
seems a hell of a lot of hassle to go through to get worse battery life than i get at the moment. Just use a stock rom with siyah set at lulzactive and deadline profiles gets me 1d 7 hours with 5 hours screen time. Fine for me.
Click to expand...
Click to collapse
wanam's deodexed stock+siyah set with with lulzactive (using droidphile's script) and deadline had given me 2-3% discharging during 11-12 hours sleep whilst any operation resulted in quicker battery drain. With same settings incroporated to Ultima 7.1 the operation-time battery drainage seems to be slowed down with same deep sleep drain.
Will it work well in cm10.1?
Enviado desde mi Tamagotchi usando Tapatalk
kylesinho21 said:
Will it work well in cm10.1?
Enviado desde mi Tamagotchi usando Tapatalk
Click to expand...
Click to collapse
It should work as long as you are running a Siyah kernel (for the stweaks setting) or pegasusq governor. Please try it and post it your results.
Sent from my GT-I9300 using Tapatalk 2
thanks you man!! i'll try it!! :good:
thekoRngear said:
wanam's deodexed stock+siyah set with with lulzactive (using droidphile's script) and deadline had given me 2-3% discharging during 11-12 hours sleep whilst any operation resulted in quicker battery drain. With same settings incroporated to Ultima 7.1 the operation-time battery drainage seems to be slowed down with same deep sleep drain.
Click to expand...
Click to collapse
is there a reason you're quoting my post while saying this?
Alright, below this, I will include an almost full guide to setting up STweaks (for those who do not want to use the provided profiles)
The CPU section contains the frequencies and voltages that you want to run at.
200mHz is the minimum speed, 1800mHz is the maximum speed. You can change these to affect your overall performance or battery life. Mine is currently set to 200mHz minimum, 1800mHz maximum. I have seen no hit on battery life at all (might be miniscule.)
Now for the Voltages.. Each and every person will have a different set of voltages, as every CPU will be a little bit different. You can manually set your frequency to a certain level, use a CPU stress testing app (stability test) and drop the voltage by SMALL increments until you start to lose stability (system crashes, app force closes, etc.) I usually go UP one voltage step over the borderline stable voltage. I will post my voltages, but take caution, as my voltages are set pretty low compared to stock values on the kernel.
1800mHz - set to 1200000 uV or 1.2 volts.
1704mHz - set to 1175000 uV or 1.175 volts.
1600mHz - set to 1112500 uV or 1.1125 volts.
1500mHz - set to 1100000 uV or 1.1 volts.
1400mHz - set to 1062500 uV or 1.0625 volts.
1300mHz - set to 1025000 uV or 1.025 volts.
1200mHz - set to 1000000 uV or 1 volt.
1100mHz - set to 975000 uV or 0.975 volts.
1000mHz - set to 962500 uV or 0.9625 volts.
900mHz - set to 937500 uV or 0.9375 volts.
800mHz - set to 912500 uV or 0.9125 volts.
700mHz - set to 887500 uV or 0.8875 volts.
600mHz - set to 862500 uV or 0.8625 volts.
500mHz - set to 837500 uV or 0.8375 volts.
400mHz - set to 812500 uV or 0.8125 volts.
300mHz - set to 800000 uV or 0.8 volts.
200mHz - set to 787500 uV or 0.7875 volts. * BE CAREFUL WITH THIS ONE, it can cause your device to lock up when the screen is off, and need a battery pull if the voltage is too low.
CPU Scaling Section - This controls how your device will turn up the speed when it needs to.
Governor - This contols how the device will respond overall (power management, sleep, etc.) I will keep mine set to the Pegasusq governor unless I am running a benchmark, in that case, use perfomance (which locks the device to full speed and all 4 cores online)
Sampling Rate - how often the device will 'think' about changing the CPU speed. I have mine set to 15000 uS (15 milliseconds) so it is more responsive.
Sampling Down Factor - This enables you to create 'lag' when the device is at full speed, so it doesn't jump down frequencies when you don't want it to. I leave mine at default 1 sample, because I see no need for this.
Up Threshold - When a core hits this % utilization at a set frequency, then it will scale up to the next frequency. I have mine set to 96%, so the device will scale up slower and more reliably (keep in mind it makes this decision every 15 milliseconds.)
Down Differential - When the device scales down, (drops frequency) it must get below this % utilization to scale down ( UP THRESHOLD minus DOWN DIFFERENTIAL ) I have mine set to 5%, so it drops frequency at or below 91% utilization.
Frequency for Responsiveness - This helps keep the device smooth at lower frequency, and when the frequency is below the set spot, it will use a DIFFERENT up threshold so the device scales up faster and doesn't lag. My frequency setting is 500mHz, and the up threshold for it is set at 70%.
Frequency for Fast Down - this sets the frequency at which the device can use aggressive down scaling, much like the opposite of frequency for responsiveness. I have mine set to 1400mHz, and the up threshold is set to 98%, so the device only scales up if it really needs to.
Frequency Step - This applies to the Fast Down setting, and whenever the device gets above 98% utilization, then it will increase the frequency by a SET percentage of the maximum frequency. So if you set 10%, and are have 1800mHz max, it will increase to the closest step that adds 180mHz. I have mine set to 6%, so it increases by 108mHz.
The up threshold and frequency step decrease confuse me for this, but I have the up threshold set to 2%, and the frequency step set to 3%.
I didn't touch the flexrate settings, as everything else should control this area.
CPU Hotplug - This section will control how the device turns its cores on and off.
CPU Up Rate - How many samples you want to take until a core decides to turn on. (Sampling rate times your setting) I have mine set to 12, so if the conditions are correct, it takes 180 milliseconds to turn a core on.
CPU Down Rate - How many samples you want to take until a core decides to turn off. (Same thing as CPU up rate) Mine is set to 10, so it takes 150 milliseconds to turn off a core if it isn't being used.
Core Upbring Count - How many cores you want to bring online when the conditions are right. Mine is set to 1, I'm sure more will increase performance and hurt battery life.
Configuration Overrides - These can set you device to always have a certain amount of cores online, I don't use them (leave at 0.)
Hotplug Conditionals - These perameters are set to control when the cores turn on and off. Below are MY values
Hotplug 1 Core to ONLINE (make 2 cores online) - 600mHz
Hotplug 2 Cores to OFFLINE (make 1 core online) - 500mHz
Hotplug 2 Cores to ONLINE (make 3 cores online) - 700mHz
Hotplug 3 Cores to OFFLINE (make 2 cores online) - 600mHz
Hotplug 3 Cores to ONLINE (make 4 cores online) - 800mHz
Hotplug 4 Cores to OFFLINE (make 3 cores online) - 700mHz
The rest of this section, I left at DEFAULT values, because I did not understand them.
GPU - This section controls the frequencies and voltages of your GPU.
Maximum Frequency - How high you want your GPU to clock to, mine is set to 733mHz.
Minimum Frequency - How low you want your GPU to clock to, mine is set to 108mHz.
Up Threshold - Like the CPU setting, the percentage of utilization you achieve before the GPU scales up. Mine is set to 90%.
Down Differential - When you want your GPU to scale down lower, (Up threshold minus down differential.) Mine is set to 10%, so when the GPU hits 80% utilization on a speed, it drops to a lower frequency.
Utilization Timeout - Basically is the sampling speed of the GPU (how fast you want it to make decisions to change speed.) Mine is set to 25 milliseconds.
Voltages - Test these the same way as the CPU, get a GPU stress testing app, and set a certain frequency. When you see artifacts or glitches on your screen, then the voltages are too low. Below are MY values.
54mHz - 800mV
108mHz - 800mV
160mHz - 900mV
266mHz - 925mV
350mHz - 975mV
440mHz - 1025mV
533mHz - 1050mV
640mHz - 1075mV
733mHz - 1125mV
800mHz - 1150mV (This clock speed proved to be slightly unstable at 1175mV, though still usable)
I/O section - These values/settings control how your device writes/reads things from the SD card, or internal storage.
I left both of my storage schedulers at ROW but you can change them and play around. I believe that deadline is the best for overall performance, but can be unstable sometimes.
I/O Read Ahead - These control the cache file on the internal/external storage. I have my internal set to 1536kB, and external set to 2048kB, because those values gave me overall good write/read speeds.
Dynamic Fsync - From what I know, this helps keep the data from being corrupted by creating a buffer between data being written and the storage. Correct me if I'm wrong. I kept it enabled.
The entire audio section is pretty self explanatory, and I'm getting tired of typing all of this, so if you need help, PM me or comment.
Again, take this entire post with caution. What works with my device, may make yours unstable. I only provided mine to give you a baseline, my values offer good performance and battery life anyways. Feel free to correct any of my errors by PM or comment, and I will gladly change my post to accommodate for my errors........
Creditx Goes To - CW ||
Great guide man!
Can I suggest you BOLD each features like this,
Governor - This contols how the device will respond overall....
Otherwise it's hard to read in one big block.
Or you could just separate them.
Good job:good:
Kremata said:
Great guide man!
Can I suggest you BOLD each features like this,
Governor - This contols how the device will respond overall....
Otherwise it's hard to read in one big block.
Or you could just separate them.
Good job:good:
Click to expand...
Click to collapse
Done....
Here's my more performance oriented settings. Averages 19500 on Antutu, and 7400 on Quadrant Standard (Advanced version adds 1000 to score) This doesn't lag at all between screens, animations, etc. The only lag I've seen is when my apps rarely crash.
CPU Max - 1800mHz
CPU Min - 200mHz
Voltages from OP
Pegasusq governor
Sampling Rate - 15000uS
Sampling Down Factor - 1
Up Threshold - 90%
Down Differential - 10%
Frequency for Responsiveness - 600mHz
Up Threshold @ Min Freq - 60%
Frequency at Fast Down - 1400mHz
Up Threshold at Fast Down - 94%
Frequency Step - 25%
Up Threshold Differential - 5%
Frequency Step Decrease - 10%
Flexrate Enabled - 700mHz, 10000uS
CPU Up Rate - 8 samples
CPU Down Rate - 10 samples
Core Upbring Count - 1
*Default Configuration Overrides*
1 Core to Online - 300mHz
2 Cores to Offline - 200mHz
2 Cores to Online - 400mHz
3 Cores to Offline - 300mHz
3 Cores to Online - 500mHz
4 Cores to Offline - 400mHz
*Runqueue Depths*
1 Core to Online - 155
2 Cores to Offline - 155
2 Cores to Online - 250
3 Cores to Offline - 250
3 Cores to Online - 340
4 Cores to Offline - 340
CPU Online Load Bias - 2 cores
CPU Online Bias Up Threshold - 50%
CPU Online Bias Down Threshold - 30%
GPU Max - 640mHz
GPU Min - 160mHz
Up Threshold - 85%
Down Differential - 5%
Utilization Timeout - 25ms
Voltages from OP
Internal/SD Card Schedulers - SIO
Internal/SD Card Read Ahead - 2048kB
Dynamic FSync - Enabled
Detailed guide
I have found this guide very detailed and useful. Thanks for taking your time to make this thread.
krishelnino said:
I have found this guide very detailed and useful. Thanks for taking your time to make this thread.
Click to expand...
Click to collapse
If I've done something you Appreciate, please hit the ":good:THANKS" button
hellDr0id said:
If I've done something you Appreciate, please hit the ":good:THANKS" button
Click to expand...
Click to collapse
Same for you. lol
Kremata said:
Same for you. lol
Click to expand...
Click to collapse
:good:
You copy all this from the thread i created yesterday under the Help section? LOL Nice try...
ahkiongkc said:
You copy all this from the thread i created yesterday under the Help section? LOL Nice try...
Click to expand...
Click to collapse
trolled Nice try
I've just bump this thread with Creditx LOL ::::...
. . . .. People should take a look at this!
And yea for ua kinda info i didnt even know about your thread so Pls dont spam lol
hellDr0id said:
trolled Nice try
I've just bump this thread with Creditx LOL ::::...
. . . .. People should take a look at this!
And yea for ua kinda info i didnt even know about your thread so Pls dont spam lol
Click to expand...
Click to collapse
It's funny how when you try to make a nice thing and help people there is always one to come and try to discredit. I have the same problem with my recovery guide.
Kremata said:
It's funny how when you try to make a nice thing and help people there is always one to come and try to discredit. I have the same problem with my recovery guide.
Click to expand...
Click to collapse
Here thing is totally different, what I know about your recovery guide is no one gave you discredit. When you publish any guide on public forum, sure someone will put their ideas and only that way discussion goes on. Basically public forum is meant for such things. I have wrote many guides having million viewership, thousand thanks, still people suggest me when something better they found, and I love to exchange idea, but it's ultimately you have to decide which one is better. We should have to remain open to discuss on topic we have created.
As far as my comments have concerned, I have discussed point to point why I found other thing is better, if you targeting that then better if you show some nice point to make me convince on your point of view rather complaining to other post. If you targeting else I am sorry.
Does you feel anyone have troll on your post?
I don't think so.
Sent from my GT-N7100 using xda premium
dr.ketan said:
Here thing is totally different, what I know about your recovery guide is no one gave you discredit. When you publish any guide on public forum, sure someone will put their ideas and only that way discussion goes on. Basically public forum is meant for such things. I have wrote many guides having million viewership, thousand thanks, still people suggest me when something better they found, and I love to exchange idea, but it's ultimately you have to decide which one is better. We should have to remain open to discuss on topic we have created.
As far as my comments have concerned, I have discussed point to point why I found other thing is better, if you targeting that then better if you show some nice point to make me convince on your point of view rather complaining to other post. If you targeting else I am sorry.
Does you feel anyone have troll on your post?
I don't think so.
Sent from my GT-N7100 using xda premium
Click to expand...
Click to collapse
Hmm I also don't think so. .
Sent from my GT-N7100 using xda premium
what Kernel is the best one to use for longer battery time and smoothness and over clocking
youngblood68 said:
what Kernel is the best one to use for longer battery time and smoothness and over clocking
Click to expand...
Click to collapse
I Highly recommend ....
Go for Perseus Kernel you'll love it . . .
Sent from my GT-N7100 using xda premium
Nice explanation about all the options in stweaks, thanks for that, sadly my CPU won't accept voltages as low as yours. Only I think your GPU voltages are a little high, some of them are even slightly higher than the default values, why is this?
Sent from my GT-N7100 using Tapatalk 2
pimjai said:
Nice explanation about all the options in stweaks, thanks for that, sadly my CPU won't accept voltages as low as yours. Only I think your GPU voltages are a little high, some of them are even slightly higher than the default values, why is this?
Sent from my GT-N7100 using Tapatalk 2
Click to expand...
Click to collapse
GPU voltages are perfect mate ...
all voltages are low compared to Default
Here's screen shotx
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my GT-N7100 using xda premium
Did OP literally just copy and paste this from the other subforum? what the
ungraph said:
Did OP literally just copy and paste this from the other subforum? what the
Click to expand...
Click to collapse
Wtf... :banghead:
Are you a idiot or something like that ?
Or you know everything about stweaks :lol:
Ohh I thik you didn't like that people's specially noob know more about tweaking and all .... that's why u pointing out on copy paste. ...
Unfortunately I love sharing so I shared this post also. .....
i think you are copied from others post.
http://forum.xda-developers.com/showthread.php?t=2079311
http://forum.xda-developers.com/showthread.php?t=2079311&page=10
GENERAL GUIDE TO KERNEL SETTINGSsome focus on Dorimanx and Boeffla KernelsPOWER CONSUMPTION VS PERFORMANCEGOVERNORS AND HOTPLUGSI/O SCHEDULERS, NET CONGESTION, BENCHMARKSUPGRADE/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
PERFORMANCE AND POWER CONSUMPTION BASICSAnd 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.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
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
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.
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
GOVERNORS AND HOTPLUGS - SOME VISUALSAnd 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"
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.
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.
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.
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
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
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.
COOL TOOL custom labels GPU freq, CPU temp, CPU 1/2/3 on/off stateI 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
Awesome dude!!!!!! Can I suggest something? Alucard hotplug and Ondemand plus gov is more battery friendly than Alucard/Alucard...
@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.
@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 .
OK, I am done for now, first draft of this thread is UP. Please provide comments/feedbacks/additional knowledge.
have fun
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
gsstudios said:
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
Click to expand...
Click to collapse
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.
Well done buddy!
Appreciate your effort to make this thread awesome!
This is a must read for everyone!
Hats off!
this shoud be stickied - well done @bloof ...