What can you expect from these tips?
*Increase battery life by 3 times compared to a situation without any tip implemented!
My target is to unplug my phone at 6am in the morning and have it around 10% at 11pm. The below tips enabled me to reach this target whereas, without them, I would run out of battery at noon (same usage, of course)!
Disclaimer: I consider that manually "swith off location" or "switch off wifi" as well as having Juice Defender on "extreme" are not acceptable. Why? Because we all need tips that enable battery savings without decreasing the user's experience! If you need to operate manually each time you want to connect and/or have 3G... this is not a solution. If Juice Defender just cut-off every communication and don't let e-mails flow, etc... this is not a solution!
However, for those who want those kind of tips, I created a special section in post 2!
Red % signification: Well, those % in red are gut feeling of "tip contribution" to the total battery saving.
My settings which enable best battery savings without reducing user's experience!
1. Use a NAND ROM
2% of battery improvement
Yes, compared to an SD ROM, a NAND ROM is less battery demanding. But as you can see, 2% is not a big part of the total improvement.
2. Use "SetCPU" with appropriate settings
5-10% of battery improvement
My Main is:
Max: 1190400 / Min: 245000 / Scaling: ondemand - yes! I want light speed HD2!
Click to expand...
Click to collapse
My profiles are (in order - this is important):
Screen Off
Max: 384000 / Min: 245000 / Scaling: ondemand
Battery <5%
Max: 614000 / Min: 245000 / Scaling: powersave
Battery <15%
Max: 614000 / Min: 245000 / Scaling: ondemand
Battery <30%
Max: 806000 / Min: 245000 / Scaling: ondemand
Click to expand...
Click to collapse
Click to expand...
Click to collapse
3. Lower VDD values as low as you can (till device becomes unstable)
5-10% of battery improvement
I am using Tyween settings from his ROM Typhoon.
Code:
#!/system/bin/sh
# set vdd_levels on boot by tyween (XDA Developers)
echo '245000 850' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '384000 875' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '422400 900' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '460800 925' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '499200 950' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '537600 975' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '576000 1000' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '614400 1025' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '652800 1050' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '691200 1075' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '729600 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '768000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '806400 1125' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '844800 1150' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '883200 1150' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '921600 1175' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '960000 1175' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '998400 1200' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1036800 1200' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1075200 1225' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1113600 1225' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1152000 1250' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo '1190400 1275' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
I tested even lower values, but my phone was not stable.
I read that each single piece of hardware is unique and could have its own minimum values, so your device could accept lower values (i.e. you're lucky compared to me) or on the contrary higher values (here I am luckier than you are )
Tip "easy way to test a new set of undervolting values": If you want to test undervolting values, themadproducer recommends to use the CONSERVATIVE CPU profile. Why? Because CONSERVATIVE seems to use the full range of scaling frequencies as it climbs up to MAX and falls back down to MIN. This way, if any particular frequency is set too low, it will complain and freeze the CPU. ONDEMAND and SMARTASS would skip over these middle frequencies or at best, never use them for more than an instant.
4. Use "Setting Profiles" for location-based WiFi
10-15% of battery improvement
This soft enables you to switch on/off wifi according to your location (based on cell towers - which does not use battery!).
Be careful: if your location is determined by GPS (instead of cell towers) than you will use more battery through GPS than you save by switching off wifi!!!
Example: you can define to have wifi ON when you are at home, and OFF when you leave home. Same with "work" or any other place where you know there's a wifi network to which you can connect.
Setting Profiles can also be used for automatic phone profiles switching (all kind of opitions from volumes, ringtones to screen brightness airplane mode, etc...)
However, I recommend you let Setting Profiles governing the wifi only. For phone profiles, I use Pocket weaver which is better I think - it can trigger profiles according to Touchdown calendar for example. Moreover, I need wifi on/off independently from hour or calendar status and these apps don't do well when it comes to integrate several conditions together.
5. Use "Phone weaver" for a night phone profile
% of battery improvement depending on situation
I am using a night profiles which goes "Air plane mode" from 11pm to 7am. But usually, I plug my phone overnight, so battery consumption is irrelevant overnight - my night profile is just to prevent radio waves to kill my brain too prematurely as the phone is nearby for morning alarm!
6. Properly setup your Internet apps
% of battery improvement depending on situation
Sounds obvious, but still! Do you really need your phone to check e-mails each 5 minutes? Or would 15 minutes be ok and in return get instantly a lot more of battery life?
Seriously, you need to setup your apps wisely.
e.g.: for those who use Touchdown (exchange sync), this app has awsome options: you can define "peak hours" during which you have a certain setting and the rest (off-peak hours) you will have another setting + the "push" option is very clever: it does not use much battery and on the top of the push option, you setup a period when it will go and check e-mails...
7. Use Auto brightness for your screen
10% of battery improvement
If your are running CM7, there is a function that let you set your own auto-diming values.
First you need to enable auto-dimming in Settings/Brightness and then check the box. After that, go in Settings/CyanogenMod settings/Display/Automatic backlight and set the following:
Light sensor filter=enabled
- Activated: checked
- Window length = 10 s
- Reset Threshold = 400 lux
- Sample interval = 0.5 s
Light levels
- Use custom = checked
- Screen dim level = 1
- Edit other levels…
Lower / Upper / Screen / Buttons
0 / 10 / 1 / 255
11 / 149 / 20 / 255
150 / 229 / 40 / 0
230 / 499 / 50 / 0
500 / 999 / 60 / 0
1000 / 2999 / 100 / 0
3000 / 9999 / 200 / 0
10000 / infinite / 255 / 0
Set number of levels = 8 (you need to set this before editing levels above)
(hit Save & Apply)
- Allow light decrease = checked
- Decrease hysteresis = 20%
Click to expand...
Click to collapse
Click to expand...
Click to collapse
If you are not running a CM7 ROM, then just enable auto-dimming in Settings/Brightness and then check the box.
8. Use "Juice Defender Ultimate" + "Juice Plotter"
50% of battery improvement
All of the above tips are very useful. However, this one is the one tip! I came to it almost depressed by my battery life (I had all of the above tips in place already).
I did not believe this soft could really help, and I thought "ok, yeah, this app will just cut-off all communication etc... but then I will have no more auto-sync and/or push e-mail"... I thought it would be a kind of "well just don't use your phone and you will get great battery life!"...
I was wrong. This app is a must! There are all kind of options in settings. Of course the first time you have to go through it and read-read-read learn-learn-learn. But in basically 20 minutes, you are setup and you have a huge battery life improvement! I can share my own settings if anybody is interested.
And the beauty of it, is that in the huge amount of options available, Juice Defender sort out everything by itselft and as a result - I don't feel the difference from a usage point of view (K9 e-mail flowing, Touchdown is pushing e-mail, everything works like a clock). From a battery point of view: wow! The app says it increases my battery life by a 2.5 factor! And this is pretty much what I observe!!!
Juice plotter is also a must: it tells you how long you will last on your battery and I find it to be the most accurate app of this kind!
9. Condition / Calibrate your battery
This one is also a must – and you should do it time to time, let’s say once a month and always first thing to do after you flashed a new ROM!
1. Plug the phone overnight.
2. In the morning: don’t unplug! Check you have 100%, check you have CurrentWidget showing 0 mA if yes/yes, restart the phone / if not, wait until you got a yes/yes answer.
3. After reboot, don’t unplug! Wait again 15 minutes charging. Check you have 100%, check you have CurrentWidget showing 0 mA if yes/yes, go to step 4 / if not, wait until you got a yes/yes answer.
4. Don’t unplug! Clear battery statistics: use a small app named “BatteryCalibration” for that!
5. Unplug your phone, use throughout the day - Don’t charge until you reached 0% battery (when the phone switches-off itself).
6. Charge again overnight up to 100% and CurrentWidget at 0 mA.
7. You’re good to go, on daily use, you can charge upon need even if not at 0%.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
By the way, if you use GPS navigation and/or Bluetooth system in your car, you must invest in a car charger – and plug the phone every time you are in your car (if not the day during which you are calibrating)… it’s another way of increasing battery life – ok, I admit, it’s more a “trick”!
10. Use small apps that help switch on/off the screen when needed
I also tested 2 small apps that actually could help battery saving on the one side, but also increase the user experience on the other side.
Screebl pro: this app is just fantastic! According to screen orientation, it senses if you are using your phone or if it is resting (lying) on the table.
Before screebl: in order to save battery I had the screen timeout set to minimum (15sec). But each time I was reading a long e-mail, I was "playing" with the screen (up-down-up-down) in order to prevent the screen to switch-off and then unlock, etc... This was really annoying. And disturbing: I could not read an e-mail or a webpage without think: "oh, I need to play with the screen somehow or it will switch-off very soon"...
After screebl: the screen timeout is now 5sec! (through screebl) so if the phone is resting, it switches-off more rapidly = you save more battery! And when I read an e-mail or a webpage, I just relax, concentrate on the content! Anyway, the "ON" time is the same because you had to read this e-mail anyway...
ProximityScreenOff:this is also an app to have. It switches-off the screen according to the proximity sensor status: if proximity is detected, the screen goes off. If you are left-handed as I am, you need to take care of not hiding the proximity sensor when you drag the notification bar down, but it is manageable. Not only it is easier to switch-off screen now. It is also saving battery if the phone accidentally switches-on in your pocket! We already had the lockscreen which prevent your phone doing silly things in your pocket. Now even better: in your pocked, the screen switches-off almost instantly!
There is also an option to switch screen ON when proximity is detected, but warning! this drains battery - so I don't use it!
And last but not least...
11. Track any bad app
% of battery improvement depending on situation
Yes, you should know about the Email.apk bug (thanks to themadproducer - I think you learn me that). And generally: you should monitor what is going-on.
I use Watchdog which will alert you as soon as an app uses CPU above a certain threshold that you set. So you know for example that a particular app eats a lot of CPu, which means battery! Watchdog also has a "white list" function for those app that you know are consuming quite a bit of CPU but that you absolutely want to keep!
Go time to time in Spare parts / Battery history / partial wake usage and see which apps are preventing your phone to sleep - they are eating your battery instead!!!
Use CurrentWidget (with log if you want) in order to track instant high current consumption but remember you have to double check with the other above tools as current might be quite high time to time, but it is a normal situation.
Edit: I had an issue with CurrentWidget. In my case, I was logging too much and in Settings / About Phone / Battery usage, CurrentWidget was showing 12%!!! Unistalling / reinstalling might correct the issue (to be confirmed).
Use Battery Monitor Widget Pro: this will draw a graph with the battery % history in a widget, so that you can see at a glance if your battery have been decreasing with a higher rate than usual (by checking visually the slope of the curve). This also to alert you that there is something to track!
I recommend you read this thread which completely describes in a very comprehensive way how to track a battery drain!
Additional thoughts
Of course, if you are on this forum, there is a chance that you like flashing ROMs, tweak it, change settings, etc… All these activities of course use more battery than what I would call the “normal” use…
Also, some activities literally pump out the battery: games, movies, camera, camcorder, GPS navigation, bluetooth headset/earset/car system… There’s no much to do about that – just just need to be aware that they use a huge amount of battery to run; after that you make your choice: game or battery / movies or battery / do I really need the GPS navigation from work to home / etc…
Additional improvements for your phone
I strongly recommend the use of Tyween's Typhoon NAND ROM it is the most stable and complete ROM ever. I tested all of them and as soon as I flashed Typhoon, I understood it was the best... I then continued testing others, but eventually, I went back to this one!!! It is fast, reliable and updated very often! Tyween's Typhoon is here.
My Juice Defender settings
Status Tab
JuiceDefender Ultimate: Enabled
Profile: Advanced
Control Tab
Mobile Data: Enabled
WiFi: Enabled
Options: wifi preferred
3G: not working on Typhoon
AutoSync: ping
Keep enabled: none
Timeout: disabled
Keyguard: none
Home WiFi network: your home network
Brightness/CPU/Speeds/Governor: none
Schedules Tab
Schedule: enabled
Frequency: 1h
Duration: 2m
Controls: default
Night: enabled
Start/End: 0:00 -> 7:00
Adaptive start/end: start +1h max, end -1h max
Option: none
Peak/Frequency/Duration/Controls: disabled
Weekend: disabled
Triggers Tab
Battery: enabled
Battery threshold: 15%
Charger: usb ac
Screen: enabled
Options: ignore on low battery
Controls: default
Traffic: enabled
Traffic threshold: Normal / 15s
Apps: enabled
Configure: interactive
Controls: default
Location: enabled
Properly setup "SettingProfiles"
1. Open SettingProfiles
2. Go on the "Locations" tab
3. "Menu/New Location"
4. In the pop-up menu select "Cell Towers identified" (do not select "Lat/Lon Identified": this would deplete your battery)
5. A window opens-up with the current cell tower id open "Menu/Save as Cell Location"
6. In the pop-up menu, give a name to this location: e.g. "Home" or "Work" depending on the place you are right now
7. Still in this menu, you can check the "auto-save for 60 minutes". If you do so, then during the next hour, all new cells that are seen will be saved automatically as a cell for the just created location. Be careful: if you check this function, you need to be sure you will stay in this very location (e.g. stay at home) during the next hour.
You're done the "Location" is created and and several Cell Towers are saved for this location. Now it appears in the list in the Location tab.
After that, you need to do the following:
1. In the "Profiles" tab, create a profile named "Wifi ON" which leaves everything as it is except Wifi that it will switch-on
2. Still in the "Profiles" tab, create a profile named "Wifi OFF" which leaves everything as it is except Wifi that it will switch-off
3. In the "Rules" tab, create a new rule. Add condition: "Location" and then select the appropriate location where you want Wifi on. Add action: "Activate profile" and then select "Wifi ON". Back key: your rule is appearing now in the "Rules" tab.
4. Still in the "Rules" tab, create a new rule. Add condition: "Location" and then select the appropriate location where you want Wifi off and check "inverse logic". Add action: "Activate profile" and then select "Wifi OFF". Back key: your rule is appearing now in the "Rules" tab.
You're all set!
The beauty of SettingProfiles is that in the rules created on point 3 and 4, you can add several locations in the same rule. e.g. it will activate "Wifi ON" when you are at Home or at Work...
Follow-up: if in future you realize that SettingProfiles has selected "Wifi OFF" when it should have selected "Wifi ON", it means that there is a new Cell Tower accessible from (let's say) Home. In this case, go on the "Locations" tab, click on "Home" and if this Cell Tower is not in the list, there will be automatically a "save" button on the top of the list. Hit "save" to say to the app that this Tower is also part of "Home".
If you realize that SettingProfiles has selected "Wifi ON" when it should have selected "Wifi OFF", well that's nothing to do about. A Cell Tower that is accessible from (let's say) Home can also be accessible 1km from Home... However, this is not a major drawback: you are experiencing this situation only during commuting transitional times.
Extreme Users section
For those users who are ready to decrease their user experience (refer to disclaimer in post 1) here are additional settings!
Warning: if you apply these tips, you may not be happy with:
* too much involvement from your side (go switch-on switch-off things)
* widgets and other functions not properly working (i.e. auto location)
* e-mail that are not flowing / not syncing with the period you defined
Tips:
A. Turn off network location, GPS and auto sync (dorimanx)
B. South to 2g (dorimanx)
C. Set Juice Defender on "extreme" (beston94)
D. ... suggest yours!
Changelog
July 12th
* Added tip #10: Use small apps that help switch on/off the screen when needed
* Moved old tip #10 to #11: Track any bad app
July 6th
* Added the "Properly setup SettingProfiles" in post 2
July 1st
* Added disclaimer and "red %" signification in beginning of post 1
* Updated SetCPU profiles (Tip 2)
* Tips to test Undervolting values (Tip 3)
* Potential issue alert with CurrentWidget (Tip 10)
* Added JD stettings in post 2
* Added "Extreme Users" section is post 2
* Added Changelog in post 3
Nice thread.
I hope people look at this before posting "my battery life sucks.."
Do you have your statistics for the percentage gain/loss of the battery?
settings
Well you said anybody who is interested in settings on juicedefender ultimate?
Well i am on cmylxgo rom i got 37 hours on and still had 30% left with moderate usage.
But maybe your settings are better ;P
parker09 said:
Do you have your statistics for the percentage gain/loss of the battery?
Click to expand...
Click to collapse
The % I wrote are from "gut feeling"...
However, I know for sure that: before applying any tip, my battery was lasting 6 hours. Now with those tips, it lasts 18 hours!!!
You should try for yourself and report results!
beston94 said:
Well you said anybody who is interested in settings on juicedefender ultimate?
Well i am on cmylxgo rom i got 37 hours on and still had 30% left with moderate usage.
But maybe your settings are better ;P
Click to expand...
Click to collapse
Uh... So you mean that you drain your battery in 50+ hours? More than 2 full days?
Mmmmmm...
So if it's not fake, you would share with us your "tip" from another world... And also elaborate a little bit on what you mean by "moderate" usage!
We are listening to you...
Hmmm... you get over 50 hours on your battery... do you use it?
Wow i see you got a nice Tread WELL DONE!!! One more Step to perfect Phone!
And Thanks for adding my tread on your main PAGE! it's an Honor!
I am now your follower
By the way my phone cant go under 925 Voltage if i set 900 on 245MHZ it's stuck in 2 seconds!
But as you know i have configured the minimal voltage script that work for me in my tweaks. bummer that my CPU like more battery!
Good Job
Thanks for your support!
This evening, I plan to:
Update first post with new settings/information
Load my JD settings (will be in post 2)
Check it out!
Thank you. Very interesting thread!
Now i feel inspired to do something for my battery...
I have a tip for battery save.
turn off network location and GPS and auto sync and switch to 2g if you can.
then when you need one of the futures just turn it on and when finish turn off.
this can save 15% battery or more.
Sent from my HTC HD2 using XDA Premium App
Looki75 said:
Uh... So you mean that you drain your battery in 50+ hours? More than 2 full days?
Mmmmmm...
So if it's not fake, you would share with us your "tip" from another world... And also elaborate a little bit on what you mean by "moderate" usage!
We are listening to you...
Click to expand...
Click to collapse
Here are my secrets juice defender ultimate on extreme and I turn on wifi whenever I want to. I also have auto killer on strict mode don't remember the exact numbers and as for my moderate usage I took 6 1minute calls and 10message received and 3 sent and a Couple of times on xda 5 minute each. Lets not forget setcpu was on on demand not over or under clocked and my profile was screen off 245 499 and my charge was 245 1190 and when battery goes under 40 its undervolted to 245 to 780. Btw I was using cmylgxo rom the lite one since I'm on European HTC hd2.l
Press thanks if I helped anyone.
Sent from my HTC HD2 using XDA Premium App
If it is everything ok with yours builds/kernell everybody should have more than 24hours on moderate use...
I mean normal batterry consumption in stand-by should be around 3-10ma depending of reception and what is turned on...
If that is not the case than you have litlle bit more than 8 hours... i mean that sucks
I thought also it's imposible but some experimenting with different build's and kernells get me to this that i can use my device for almoust day and a half without turning wifi off.
p.s. juicedefender is enabled at balanced...
Hi everybody!
I just added a lot of things in the first 3 posts!
Check-out changelog in post 3!!!
* New SetCpu profiles
* My JD settings
* and much more... !!!
Check it out!!!
very nice tips here, but am struggling with JD atm as it says the rom i use doesnt support mobile data, does your 3g work with JD activated ? if so how do i get it working for me,
thanks, great thread btw
Found room for this useful thread in my signature
To enable JD notifications or not? Because I think notifications eat battery.
LaneyEFC said:
very nice tips here, but am struggling with JD atm as it says the rom i use doesnt support mobile data, does your 3g work with JD activated ? if so how do i get it working for me,
thanks, great thread btw
Found room for this useful thread in my signature
Click to expand...
Click to collapse
Thanks for linking to my thread in your signature
If you mean Controls Tab / 3G then JD asks you to "Proceed".
When you hit the "Proceed" button, it proposes you to install "Juice Defender AOSP Helper". You should install this app and then hit "enable" in Controls Tab / 3G.
However, some ROMs do not support this function and in this case, "Juice Defender AOSP Helper" will not install. Typhoon for example does not support this soft.
Now here is something for you: you can install a soft named "Toggle2G-update.zip" (the update through CWM if you are running Gingerbread 2.3.4).
"Toggle2G-update.zip" is in this thread, with all explanations:
http://forum.xda-developers.com/showthread.php?t=739530
You can also choose another similar app (there are a lot of them).
This will perform the same than JD / Controls Tab / 3G but with a separated software.
Cheers!
radee85 said:
To enable JD notifications or not? Because I think notifications eat battery.
Click to expand...
Click to collapse
Hello,
I enabled JD notifications.
Why? Because in a glance you can know what is JD status (I use the graphical notifications).
I never noticed any particular drain related to JD notifications, and let's say to any notifications... I also heard about that but could not reproduce the drain.
If you have any precise information about a notification-caused drain, this is an interesting information that you can share in this thread.
Thanks to report your observations!
Cheers!
Reorganized overflowing Posts to fit into 5 Posts. [Feb 3]
Most of us are flash maniacs, and we do it a lot. But after a kernel flash, we wonder:
Q1. "OK i have flashed this xyz kernel. What're all these governors? How do i know which one is the best for me? How do i tweak them to bias their characters towards Battery-life/Performance/Balance between the Two".
Q2. "What's the fuzz about these modules that comes with the kernel. How do i use them. Are they any good. Is it OK to neglect them?"
Q3. "What roles does an i/o scheduler play? How to choose a reliable i/o scheduler?"
Q4. "Can i have more control on CPU? More info and tweaks on dual core CPU, bus frequency, etc?"
Q5. "Better understanding on impact of different values for basic/advanced parameters in the Kernel Config App, so that i can tweak the settings according to my taste?"
Hope this thread could give you answers for all these questions. We're covering governors, modules, i/o schedulers that comes with Siyah kernel, plus more. That should cover almost all the popular governors/modules/io schedulers! Many people seem to get lost in Kernel dev threads without getting answers about governors and such.
The info in this thread holds good for non-siyah kernel users too. You should find here, info on most of the governors/modules/io schedulers in your kernel if not all.
Thanks To
1) Gokhanmoral for his mighty sweet Siyah Kernel which inspired me to write this thread.
2) Moderators for squeezing in extra posts when i ran out of space to fit everything in only 3 reserved posts.
3) Users/Readers for your warm comments.
POST 1: KERNEL GOVERNORS
POST 2: GOVERNOR TWEAKS
POST 3: LOADABLE KERNEL MODULES
POST 4: I/O SCHEDULERS
POST 5: DUAL CORE CPU Q&A AND TWEAKS
POST 6: CONFIGURE KERNEL AIO APP - GINGERBREAD
POST 7: CONFIGURE KERNEL AIO APP - ICS
1. GOVERNORS
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
NOTE: Info on Samsung's own multi-core aware governor - Pegasusq is here
1) Ondemand:
Default governor in almost all stock kernels. 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. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) 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.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) 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.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
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.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Luzactiveq, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
________________________________________________________________________________________________________________
II) QUESTION TIME:
Q. "Ok. Enough of explanations. Tell me which governor is for performance and which one is for battery life."
A. Tough question! lulzactive and smartassV2 for a balance between performance and battery. For light weight tasks, lulzactive should be better for battery. And for heavy weight tasks, lulzactive should be better for performance also. To get maximum performance, use a tweaked ondemand or conservative, but never complain about battery. NOTE: It's not so easy to tame luzactive. If you don't know how exactly to do it, stay away from it or you will end up complaining about battery drain!
Q. "Hey, almost forgot. How do i change governors?"
A. Best way is to use an init.d script if your kernel supports it. (echo "governor-name" > /sys/devices/system/cpu/cpu0/cpufreq /scaling_governor) Else use Voltage Control/SetCpu/No Frills/Antuntu CPU Master, etc. Voltage Control has the interfaces for gpu oc/uc/uv and charge-current change if your kernel supports them. Like we guessed, these apps will tell us the active governor too.
Q. "How do i know which governor is best for me?"
A. It depends on what you need and your daily usage pattern. Performance or battery. Better choose a governor that's balanced for battery/performance. Or tweak a governor to give performance an upper-hand as compared to battery. We can always re-charge the phone: In car when off to work, or overnight. But we can not recharge performance! After all, we bought GS2 to enjoy it's sheer power.
Q. "Well i have set my favorite governor as screen-on governor and another one as screen-off governor. Why the hell is the phone not waking up after deep sleep. I need to force-restart the phone by pressing power button for about 10 secs. Is it a sleep-of-death?"
A. Yes it is. Do not use two governors as screen-on & screen-off govs, if they both have an upper frequency limit for screen-off state.
Didn't get it? Examples for Wrong combinations: (screen-on:screen-off):-
ondemandX:smartassV2
Examples for right combinations:-
ondemand:smartassV2, lulzactive:smartassV2
Q. "I can feel slight lags here and there with a governor. For ex: while scrolling through app drawer/vertically scrolling browser, etc. I really love this governor and don't tell me to use another governor. Can i diminish this lag?"
A. Hmm well, you can. Basically what we have to do is make the governor "poll" less often to scale-down cpu. Increase down-sampling-time of your governor (whichever parameter that corresponds to), so that the cpu will stay longer on a frequency before scaling down. This should eliminate the lag.
Q. "Even though i don't have too much uv/oc, once in a while; may be once in two weeks, i experience a freeze/lock/reboot. I'm using governor X. How do i solve this?"
A. Well, a random reboot/freeze once in a while signifies that we're android/galaxy SII enthusiast. If everything go smooth as silk, what's the fun? We could use stock rom/kernel/governor and be happy. A rare reboot or freeze is nothing to worry about. Just restart the phone.
Q. "OK. I want to tweak these governors according to my usage pattern, because i'm not happy with the default behavior of these governors".
A. You can tweak the governors using an init.d script to echo suitable values into:
/sys/devices/system/cpu/cpufreq/name-of-active-governor/name-of-the-paramater-to-tweak
Example:
echo "20000" /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
Q. "I'm going to set scaling min freq as 100 mhz because my kernel supports it. Hope there's nothing wrong in doing that."
A. Wait! You may want to stay away from using 100mhz during screen-off or screen-on states for three reasons 1) It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online. 2) 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon. 3) 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Ex: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
Q. "I want to know is there's anything more i can do to improve battery life. I have already tweaked my governor settings but..."
A. Take my word. Best way is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock 1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the difference.
Q. "How to make my device more snappier. I don't care much about batt....err...I do care about battery life, but only in terms of avoiding unwanted power consumption. Device should instantly dance to my tunes."
A. Scale 500 to 1200 during screen-on and 200-500 during screen-off. Use performance tweaked conservative/ondemand(x). No excess power consumption because 1400 and 1600 is out the league. Response will be sweet. And don't worry, minimum of 500 during screen-on will not drain too much battery like you think!
Governor tweaks in Post 2.
Governor Tweaks
(First post extended here. )
2. SAMPLE GOVERNOR TWEAKS
III) PARAMETERS & TWEAKS:
[Only Ondemand, Conservative, SmartassV2, Lulzactive and Interactive; being the most preferred governors.]
Different governors has different parameters. But it's easy to understand a governor. Ideally, a governor will have:-
1) Sampling Interval/Rate measured in uS by which the polling function determines how often to poll and decide if frequency should be scaled-down or scaled-up. [Some governors will have different sampling time for scaling-up and scaling-down]
2) Thresholds measured in percentage. When CPU load reaches this point, governor scales up or scales down the CPU. [Most of the governors will have down-threshold and up-threshold, for which CPU is scaled down or up respectively.
There are various other parameters/factors too, but all are in someway related to these two parameters.
1.ONDEMAND
[ PARAMETERS ]
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
v) down_differential - This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.
[ SAMPLE TWEAKS ]
i) For battery:-
To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.
Code:
echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "10" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step
ii) For performance:-
To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.
Code:
echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "50" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step
2.LULZACTIVE
1. Initial Version:-
[ PARAMETERS ]
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
[ SAMPLE TWEAKS ]
Unfortunately, the initial version of lulzactive doesn't give user much control on it's behavior. We can only control how often cpu should scale up and scale down. Use higher down_sampling_time if you experience lag while scrolling through browser, app drawer, etc. Better keep the default up_sampling time (24000) unchanged. And make down_sampling proportional to up_sampling. Like 2x24000=48,000 or 3x24000=72000.
2. Second Version:-
[ PARAMETERS ]
i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up
ii) pump_up_step - No of scale up steps when load >= inc_cpu_load
iii) pump_down_step - No of scale down steps when load < inc_cpu_load
iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.
v) up_sample_time - same as initial version. (Allowed values 10,000 to 50,000)
vi) down_sample_time - same as older version. (Allowed values 10,000 to 100,000)
[ SAMPLE TWEAKS ]
i) For battery:-
Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive gradually scale up CPU and rapidly scale down on low load.
ii) For performance:-
Code:
echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive scale up CPU rapidly, polling often and scale down gradually.
iii) For balanced-performance:-
Code:
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
This tweak cause lulzactive to poll more often and scale up 4 steps above current frequency, but only at 90% load. CPU is scaled down normally.
note: If you're lazy to use a script, use lulzactive app from market to tweak the governor. https://market.android.com/details?id=com.tegrak.lulzactive
3.SMARTASSV2
[ PARAMETERS ]
i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
v) max_cpu_load - Same as up_threshold in other governors.
vi) min_cpu_load - Same as down_threshold in other governors.
vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
[ SAMPLE TWEAKS ]
i) For battery:-
Code:
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
ii) For performance:-
Code:
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
4.CONSERVATIVE
[ PARAMETERS ]
i) down_threshold, ii) up_threshold, iii) sampling_down_factor, iv) sampling_rate - Refer above governors.
v) freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
[ SAMPLE TWEAKS ]
i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
ii) For performance:- [Isn't it ironical that we are tuning Conservative to achieve blazing performance!]
Code:
echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
5.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:- [Interactive and battery?!! I'm capping the highspeed_freq in the hope of saving battery]
Code:
echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
ii) For performance:- [Assuming your scaling_max_freq is equal to or above 1400 mhz)
Code:
echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
IV) GUIDE TO INIT.D SCRIPTS
When I'm writing tweaks all over the thread, it's unfair if i don't cover a small guide to scripts since there are people who does not have any experience or knowledge on init.d scripts. So here are the "WHATs" and "HOWs".
If you're already familiar with init.d scripts, please skip this part.
Android boot-up process can be divided into three parts on a high-level.
1) First stage bootloader runs.
2) Kernel boots and it loads various drivers, prepares hardware and so on.
3) User space programs are invoked. It is in this stage where init.d scripts are executed. (Also various apps and daemons are started to prepare the rom)
Most of the custom kernels supports init.d scripts. Some developers choose to run init.d scripts whose names starts with an "S". Others choose to execute all the scripts inside init.d directory.
Init.d script are to be placed inside /system/etc/init.d directory (or /etc/init.d which is a symbolic link to /system/etc/init.d)
Order of executing init.d scripts are in the increasing order of ASCII values that corresponds to their names. For ex: among two scripts named, "Ascript1" and "Bscript2", "Ascript1" will be executed first. If there is a particular reason that we need one script to be executed before another, make sure you name it properly.
GUIDE:
First line of any script should invoke a compatible shell/interpreter which is responsible for executing the rest of the script. The compatible shell may be the default shell "sh" or "busybox".
So first line of any script should look like this:
#!/sbin/busybox sh or #!/system/xbin/busybox sh [The location of busybox may vary with roms/devices. So please check with root explorer, busybox location and change the path accordingly]
OR
#!/system/bin/sh
From next line, the actual script starts.
ex: echo "200000" > /sys/devices/system/cpu/spu0cpufreq/scaling_max_freq
Make sure there are no syntax errors first, (also check for logical errors)
Most common error is to use a windows-based editor which leaves an extra space at the end of each line or leaves an invisible invalid character when you press carriage return (ENTER key).
So do not use editors such as notepad or wordpad to create scripts. Use Notepad++, a free GNU editor.
After finishing the script, check for extra spaces at the beginning and end of each line in the script. If found, remove them.
Save the script without any extensions (Yes, not even .sh extension).
Use adb or rootexplorer to push the script into /etc/init.d and set permissions.
Read this beautiful guide on how to install SDK and setup ADB without any hassle on your PC.
Using root explorer, copy the script to /etc/init.d and set permissions:
owner : rwx
group : r_x
others : r_x
Download script manager from market, use it to run the script as root by checking the skull symbol. This is only to check the script for any errors. If exit code= 0, script executed successfully. From now on, your script will be automatically executed on every reboot. But if script manager shows errors, again edit the script (using notepad++ in your PC or using script manager editor itself from your phone), fix the errors and execute again. Repeat this until script is error-free. Remember once again: "A single extra space at the end of a line is a syntax error and script will fail to execute the rest of the lines."
To add comments you can use "#"
Sample Script:
Code:
#!/sbin/busybox sh
#No of values echoed to freq table and uvmv table should match the no of steps in your kernel
echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/freq_table
echo "1425 1325 1275 1175 1075 975 950 950"> /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
echo "200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "ondemandx" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
To Do:
1) Sample SmartassV2 gov tweaks - DONE
2) Sample Interactive gov tweaks - DONE
3) Technical explanation on working of popular governors by the aid of parameters. - Half done, scattered along Posts
4) More questions in Question Time section - IN PROGRESS
ICS Kernel AIO Configuration Apps: How To Mess With Them
7. CONFIGURE KERNEL AIO APP - ICS
We heard a lot of "ICS is more mutlithreaded and multi core aware". Can a 3.0 kernel make the best out of dual core Arm Cortex A9? Let's tweak and see.
SIYAH KERNEL
Thread | App - ExTweaks
TAB 1 - CPU: Hotplugging, Smooth Scaling, Idle States
1) Hotplug Mode: Best practice is to use hotplugging instead of single/dual core modes and setup settings in such a way that until about 800 mhz, only first core is active. This is energy efficient because above 800mhz, the voltage increase is steep. So static power consumption increases steeply and it's better to have two cores handling tasks from here on. Having only one core online roughly saves about 55% power compared to two cores online. But it's not worth using single core for all frequencies since the device is capable of more.
Sample Values:CPU Hotplug
2) loadh0, loadl1: Values are so self explanatory. Load-High-0 and Load-Low-1. Thresholds to turn ON and turn OFF second core. When load on first core is greater than or equal to loadh0, second core comes online. When average load on both cores is less than loadl1, second core goes offline. It's better not to overload first core before turning second core on.
Sample Values: loadl 20, loadh 50 for less aggressiveness or 20 30 for more aggressiveness. ICS hotplugging logic has some difference from GB hotplugging. To get the same responsiveness as in gingerbread, i had to use more aggressive(reduced) thresholds.
3) min_rq, load_rq: As of now, what these params does is unknown. I think it's something to do with CPU run queue and enhance load balancing on cores. I'm not sure.
4) rate: Rate is the sampling interval for hutplugging for screen-ON state. Every rate jiffies, load is sampled and if found to be more than loadh0, second core is turned ON. One jiffy is the time taken to complete one tick of the system timer. Frequency of sgs2 timer is 200hz. So the value divided by 200 gives the equivalent seconds or in other words, one jiffy = 5 milliseconds in GS2 terms.
Sample Values: rate 100.
5) freq_min: 'Threshold' frequency for second core to turn on during hotplugging. If current frequency <= freq_min, second core will not turn on even if the load has crossed loadh0. CPU runs efficiently if only single core is used until about 800 mhz and both the cores are used only for the higher frequencies. Because voltage increase is intense past 800 mhz.
Sample Value: 800000 (so that second core kicks-in only from frequency>800 mhz).
6) CPU Idle States: Unlike 8 idle states supported by OMAP4 of Nexus, GS2 Exynos supports only 3 idle state: IDLE, AFTR, LPA.
IDLE - Clock is gated but power on CPU core remains (static power consumption still active)
AFTR - Clock is gated, power on CPU core is removed and L2 cache power remains. Static power consumption mostly eliminated.
LPA - Cache power removed.
AFTR or LPA cannot be entered if second core is active.
Sample Values: Idle Mode 3 (AFTR+LPA), to save battery.
7) Sched_mc: Disable sched_mc. There could be only one situation where load balancing or weird-overloading of first core can be useful - when we use dual core mode. Sched_mc is valid only when both cores are online. Since it doesn't go well with hotplugging logic, if someone uses dual-core mode sched_mc is worth a try to handle task loads on cores.
Sample Values: sched_mc 0
8) smooth_target, smooth_offset, smooth_step: These params helps in 1) Throttling CPU at higher temperatures 2) Control Ondemand based governors' urge to jump to maximum frequency too often by jumping the CPU to an intermediate frequency first. If we're not interested in either of them, leave it as 0 0 0. NOTE: Smooth scaling is enabled only for Ondemand and Conservative governors.
Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2
TAB 2 - GPU: GPU behavior. This matters more than CPU UV w.r.t Screen-On power savings!
1) GPU Frequency Steps: There are plenty of frequencies supported by the MALI400. Valid frequencies are 400/(x*0.5) where 2 <= x <= 20. 400 267 200 160 133 114 100 89 80 73 67 62 57 53 50 47 44 42 40 are valid frequencies. I would recommend using energetically efficient GPU freqs.
Sample Values: 160 200 267. If you want more frames, use 200 267 400.
2) GPU Voltages: GPU Undervolting (if not taken care of) has some worse side effects compared to CPU UV. Your game will crash, your navigation app will crash. I'd recommend to use stock voltages. Or just a -50mV UV for each step.
3) GPU UP and DOWN Thresholds: The four thresholds are threshold to switch to second step, switch back to first step, switch to third step, switch back to second step. We do not want GPU to immediately scale up after scaling down to a frequency. This implies the thresholds are overlapping load-evaluations. Use up-thresholds of the range 80-90. To calculate down-thresholds in such a way that overlapping is prevented, for a set of two freqs, find out what percentage of higher frequency is lower frequency, and reduce 5-10 % from the resultant value.
(If you like the 'good old' two frequency step, set Threshold-2-UP to 100 so that only First two steps are used and third step will never be active)
Sample Values: 85 70 85 65 (Assuming GPU freqs are 160 200 267). OR 85 65 85 55 (If GPU freqs are 200 267 400).
4) GPU Stay Counts: No of cycles to stay at each GPU step. It is recommended to leave it as default 1 1 1.
Sample Values: 1 1 1
TAB 3 - SCREEN: Touch sensitivity, Brightness curve
1) Touch Move Sensitivity: Supported values are between 0 and 20. Lower value is more responsive. But setting it too low will cause swipes to be registered as clicks.
Sample Value: 7 pixel
2) min_bl,min_gamma, max_gamma: If you don't want lowest brightness to be very low, use 30 1 24.
Sample Values: 30 1 20 (for stock experience)
OR 50 0 20 (for low lowest brightness level and low highest brightness levels)
TAB 4 - MISC: Governor, Scheduler, Miscellaneous tweaks
1) Backup EFS: Backup your precious EFS partition to use in the future to recover a lost IMEI.
2) Android Logger: Enable/Disable Logging. Leave it enabled.
3) Default Ondemand Suspend Freq: Max frequency that will be used during screen-off state if Ondemand is the active governor. 500000 (500 mhz) is the most sensible value.
4) Default CPU Governor: Use whichever you like. Ondemand is good enough.
5) Default I/O Scheduler: Use whichever you like. I use sio/bfq.
6) Charge Current: Since it was proved that i9100 Li-ion battery charge current can only be either of 450mA and 650mA, leave it at AC:650, MISC:450,USB:450 OR AC:650 MISC:650 USB:450
7) Reset Fuel Gauge Chip: After a low-battery reboot if the battery shows very low and incorrect percentages since true battery capacity failed to accurately synchronize with the fuel gauge, press the button and wait for sometime. An alternative is to charge full->discharge full->charge full.
8) Remove Root: Some apps detects root and refuse to work if found. In such cases, or if some apps are freezing in a while, remove root and re-install root. Pressing the button will remove Superuser.apk and SU binary.
9) Install Root: Tries to install root after a removal. Copies Superuser.apk and SU binary. If this fails, check 'Auto-Install Root' and reboot.
This post will be updated with more releases of the kernel.
Modules
3. MODULES
A loadable kernel module is an object that contains some code to extend your kernel. Modules serves various type of purposes like support for new hardwares, filesystems, and system calls. It is probable that once a new module is inserted, it might cause minor fragmentation in kernel resulting in a minor performance penalty. Mostly, not noticeable.
We might ask "ok, if kernel modules are so amazing, why not add them all into the kernel code instead of asking us to load them". Well, the advantage to LKMs is that you can minimize the memory footprint for a kernel, loading only those elements that are needed.
You can find all the modules in /lib/modules. (With extension .ko = Kernel Object).
To avail a module, you need to install/insert it by:
Code:
insmod /lib/modules/module-name.ko
Put the line in an init.d script to load the module(s) on every boot.
To view the list of modules that are loaded by default, use:
Code:
lsmod
To unload/remove a module (that has been loaded):
Code:
rmmod "modulename"
1) bthid.ko* - BlueTooth Human Interface Device
Signifies: Bluetooth
Bthid is one of the bluetooth profiles. The module provides support for devices such as bluetooth mice, joysticks,keyboards,etc. It uses a low latency link with low power requirement to achieve the above mentioned.
2) cifs.ko - Common Internet File System
Signifies: Network Share
Successor to the SMB (Server Message Block) protocol, this protocol is supported by windows servers, samba, etc. The module is responsible for managing your network shares. It is used to mount/unmount network file resources on to your device. If special characters are not properly read/displayed, download and use nls_utf8.ko module for UTF-8 character support.
3) fuse.ko* - File System in Userspace
Signifies: File System
The module let the users create own filesystems without editing kernel code. Fuse module act as a bridge between filesystem code running in the userspace and kernel interface. The module is often used in our devices to support ntfs/ntfs-3g filesystem for mounting ntfs formatted hard drives and pen drives.
4) cuse.ko - Character Devices in User Space
Signifies: Audio Proxying
CUSE is an extension of FUSE allowing character devices to be implemented in userspace. One of the prime motivation for developing cuse is to provide a better support for Open Sound System or OSS. Except for initialization sequence and creation of character device instead of a mount, CUSE isn't very different from FUSE. CUSE is used for tasks like proxying OSS audio from OSS apps to an audio system.
5) dhd.ko - Dongle Host Driver
Signifies: Wifi
This module (from broadcom) is the wifi kernel module/wireless driver, and is responsible for wifi tethering, and such.
6) ftdi_sio.ko - Future Technology Devices International - Serial I/O
Signifies: USB Serial Devices
The module is required to connect an embedded device to our device using FTDI USB-serial converter. The embedded device will be an ftdi chipset based device. Devices like an USB-RFID reader could be connected.
7) usbserial.ko - USB Serial
Signifies: USB Serial Modems
This module is often used along with ftdi_sio module. It is the usbserial-generic interface for linux platform. The module is used to detect and use devices such as usb serial modems.
8) gspca_main.ko - GSPCA Main Driver
Signifies: Webcams
This module is used to install gspca based web camera in our device. The module is the driver that's responsible for detecting and functioning of gspca based webcams.
9) hfs.ko - Hierarchical File System
Signifies: Mac Filesystem
This module is the driver to support HFS aka Mac OS Standard file system. Try mount -t hfs "/source" "/destination" to mount. Also give USB Mass Storage Watcher App from market a try, to skip commands and mount via GUI.
10) hfsplus.ko - Hierarchical File System Plus
Signifies: Mac Filesystem
This module acts as the driver for HFS+ aka Mac OS Extended file system. HFS+ is one of the formats found in iPods. Use mount -t hfsplus "/source" "/destination" for mounting drives.
11) j4fs.ko* - Jong Jang Jintae Jongmin File System
Signifies: File System
J4fs is a filesystem based on LFS (Linear File Store). The bootlogo and some misc files in our device, mounted in /mnt/.lfs is formatted as j4fs filesystem by default.
Please do not mess with .lfs folder!
12) ld9040_voodoo.ko* - LD9040 AMOLED Driver
Signifies: Voodoo Color
Module/driver for voodoo color/screen tuning support for our device. Let's wait patiently until supercurio comes out with a legendary app to have full control on our amoled display.
13) scsi_wait_scan.ko - Small Computer System Interface Wait Scan
Signifies: Waiting During Booting
scsi_scan_wait is responsible to wait until all the asynchronous scans are complete. It will wait after all root SCSI drivers have finished scanning their busses. Note that use of this module can increase your bootup time.
14) Si4709_driver.ko* - Si4709 FM Radio Driver
Signifies: FM Radio
Si4709 is the fm radio receiver driver. Module is loaded by default by Siyah. If there are issues with fm radio in aosp roms, try inserting this module.
15) vibrator.ko* - Vibrate Sensation on Touchsense
Signifies: Haptic feedback
This module from immersion corporation is responsible for haptic feedback. It senses touch as a request and sends back vibration as response. Try inserting this module if haptic feedback not working on aosp roms.
16) logger.ko - Logger for Android
Signifies: Logging/Debugging
Loggers are used to log records to a variety of destinations such as log files or the console. Install this module to enable logging, if logging is disabled in your kernel by default. Logging is used to generate logcats (for debugging purpose), dmesgs (message buffer of the kernel), for proper functioning of app protectors, etc.
17) mc1n2_voodoo.ko - mc1n2 Voodoo Sound Driver
Signifies: Voodoo Sound
Module/driver for Exynos Yamaha audio hardware tweaks. Provides sysfs interface for HP gain and Aout. This driver provides support for supercurio's Voodoo Louder app.
18-25) cpufreq_ brazilianwax.ko, cpufreq_ interactive.ko, cpufreq_ interactivex.ko, cpufreq_ lazy.ko, ondemandX.ko, cpufreq_ powersave.ko, cpufreq_ savagedzen.ko, cpufreq_ userspace.ko
Insert these module(s) to avail your favorite governor which are not loaded by default.
*Modules preloaded in Siyah by default.
Q&A
Q. "I can not find a module that i need to use with the current release of my kernel. Can i use the module downloaded from internet?"
A. Module should be binary compatible with the kernel version. So even if the module was one that came with an older version of the kernel, it's probable that the compatibility is lost.
Q. "I feel there could be some advantage if i remove modules which is no use for me, but they're loaded by kernel during boot-up. What can i do?"
A. Put "rmmod name-of-module" in one of your init.d script, so that it's uninstalled on every boot-up. After booting if you need to use the module, you can insmod it. Ex: rmmod Si4709_driver.ko. (If you don't use FM radio)
Gingerbread Kernel AIO Configuration Apps: How To Mess With Them
6. CONFIGURE KERNEL AIO APP - GINGERBREAD
See the previous post for detailed description of each tunable. This post is to give an idea on impact of value x or value y for a tunable.
PREFACE:
ARM processor in Exynos chip consists of four major power domains: CPU cores (and L2 cache), GPU, memory interface, and audio/video IP blocks. The tunables discussed below will directly or indirectly affect power consumptions of these domains. Please note: 1) Having an upper hand on Screen-ON power consumption is difficult. Reducing brightness, control GPU behavior and bus frequencies are almost the only ways. 2) Beyond a point we can not achieve better performance or better power saving and it's useless to tweak settings thereafter.
SIYAH KERNEL
Thread | App - ExTweaks
TAB 1 - CPU: Take control on CPU hotplugging, throttling, power saving states, etc
1) Hot-Plug Mode: You have a dual-core device. Forcing single core mode is foolishness. You have room for performance. Forcing dual core mode is also foolishness. Unwanted excess power consumption even when CPU is 'idling' is the 'minor-reason' and blocking deep idle states is the 'major-reason'. (Only first core can hit deep idle states in Exynos 4210. Never forget this!) It takes only a few micro seconds to activate/deactivate a core. So use Hotplugging.
2) loadl, loadh: Do not wait for core 1 to be over-loaded to activate second core.
Sample Values: loadl 25, loadh 75 for less aggressiveness or 25 50 for more aggressiveness.
3) loadl_scroff, loadh_scroff: Bluetooth transfers, wifi/3g downloads, music play. Tasks that can be run during screen-off state are very few. It is recommended to set threshold to 100% so that second core doesn't kick-in during screen-off state. This will help first core to hit deep idle state soon after tasks are finished.
Sample Values: loadl_scroff 50, loadh_scroff 100. Value of loadl_scroff is insignificant since Core 2 will not turn on.
4) rate, rate_cpuon, rate_scroff: Compared to governor sampling interval (in the range of micro seconds), these are normally very high values (terms of seconds or hundreds of milli seconds). Unit is jiffy. One jiffy is the time taken by one tick of the system timer. Frequency of sgs2 timer is 200hz. So the value divided by 200 gives the equivalent seconds. In a research it was found that having two cores online consumes almost same power as having a single core online.
Sample Values: rate 100 rate_cpuon 400 rate_scroff 1000. If you want to delay enabling second core, use 200 400 1000.
Why such a high value for rate_scroff? Because loadh_scroff was set to 100%, core 2 won't kick-in when screen is off. So the value of rate_scroff doesn't matter. We're simply delaying the next sampling.
5) freq_cpu1on: CPU runs efficiently if only first core is used until about 800 mhz and both the cores are used for the higher frequencies (if the load demands).
Sample Value: 800000 (so that second core kicks-in only from frequency>=800 mhz). Or 300000 (so that core2 could be online from 500mhz onwards)
6) Idle Mode, Sched_mc: Unlike 8 idle states supported by OMAP4 of Nexus, GS2 Exynos supports only 3 idle state: IDLE, AFTR, LPA. Also, load balancing using sched_mc makes no sense on an already hotplug-enabled device.
Sample Values: Idle Mode 3 (AFTR+LPA), sched_mc 0
7) smooth_target, smooth_offset, smooth_step: If you feel there's a need for 1) throttling CPU 2) Control governor's urge to jump to maximum frequency too often, then use sensible valid non-zero values. Otherwise, leave it all zero. NOTE: Smooth scaling is enabled only for ondemand and conservative governors.
Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2 for the sake of power saving and precaution. If you prefer not to interfere with governor's decision use 0 0 0.
TAB 2 - GPU: Take control on GPU domain. You decide how many FPS you want!
1) GPU Frequency Steps: There are plenty of frequencies supported by the MALI400. Valid frequencies are 400/(x*0.5) where 2 <= x <= 20. 400 267 200 160 133 114 100 89 80 73 67 62 57 53 50 47 44 42 40 are valid frequencies. I would recommend using energetically efficient GPU freqs.
Sample Values: 160 200 267. If you want more frames, use 200 267 400.
2) GPU Voltages: GPU Undervolting (if not taken care of) has some worse side effects compared to CPU UV. Your game will crash, your navigation app will crash. I'd recommend to use stock voltages. Or just a -50mV UV for each step.
3) GPU UP and DOWN Thresholds: We do not want GPU to immediately scale up after scaling down to a frequency. This implies the thresholds causes overlapping of load-evaluations. Use up-thresholds of the range 80-90. To calculate down-thresholds in such a way that overlapping is prevented, for a set of two freqs, find out what percentage of higher frequency is lower frequency, and reduce 5-10 % from the resultant value.
(If you like the 'good old' two frequency step, set Threshold-2-UP to 100 so that only First two Steps are used and third step will never be active)
Sample Values: 85 70 85 65 (Assuming GPU freqs are 160 200 267). OR 85 65 85 55 (If GPU freqs are 200 267 400).
4) GPU Stay Counts: No of cycles to stay at each GPU step. It is recommended to leave it as default 1 1 1.
Sample Values: 1 1 1
TAB 3 - SCREEN: Take control on touch response and brightness levels.
1) Touch Move Sensitivity: Supported values are between 0 and 20. Lower value: more responsive. Set it too low, swipes will be registered as clicks. Set it too high...yeah do not set it high.
Sample Value: 7
2) min_bl,min_gamma, max_gamma: If you don't want lowest brightness to be very low, use 30 1 24.
Sample Values: 30 1 24 (for stock experience) OR 50 0 20 (for low lowest brightness level and low highest brightness levels)
TAB 4 - MISC: Governor, Scheduler, etc
1) Backup EFS: Backup your precious EFS partition to use in the future to recover a lost IMEI.
2) Android Logger: Enable/Disable Logging. Leave it enabled.
3) Default Ondemand Suspend Frequency: Max frequency to be used by ondemand governor during suspend state (screen-off). Leave it as 500000.
4) Default CPU Governor: Use whichever you like. New ondemand is good enough.
5) Default I/O Scheduler: Use whichever you like. I use sio/bfq.
6) Charge Current: Since it was proved that i9100 Li-ion battery charge current can only be either of 450mA and 650mA, leave it at AC: 650, MISC: 450, USB:450 or AC:650 MISC: 650 USB:450
7) Reset Fuel Gauge Chip: After a low-battery reboot if the battery shows very low and incorrect percentages since true battery capacity failed to accurately synchronize with the fuel gauge, press the button and wait for sometime. An alternative is to charge full->discharge full->charge full.
Last Words: If you use scripts to set bus frequencies, i recommend leaving static bus frequency disabled. Tasks which involves a lot of GPU rendering really does a lot of Write and Read To and From memory. Let the system decide what bus frequency should be used.
FECALITY KERNEL
Thread | App - ExTweaks
TAB 1 - CPU: See above for config hints/sample values for each parameters under this tab.
1) loadh, loadl:
2) loadl_scroff, loadh_scroff:
3) rate, rate_cpuon, rate_scroff:
4) freq_cpu1on:
5) CPU Idle Mode:
TAB 2 - GPU: See above for config hints/sample values for each parameters under this tab.
1) GPU Frequency Steps:
2) GPU Voltages:
3) GPU UP and DOWN Thresholds:
TAB 3 - MISC: See above for config hints/sample values for each parameters under this tab.
1) Backup EFS:
2) Default CPU Governor:
3) Default I/O Scheduler:
4) File Fsync Disable: If FSYNC is used, and a file is open for writing, all cached data will be written to disk. This feature helps to minimize data loss under rough conditions, where power failures can occur. Only advantage to disable per file fsync is increased performance in DB writes, etc. This can also be achieved using a different i/o scheduler. Disabling Pfsync is dangerous as it can lead to data corruption. Do not disable Pfsync.
5) Reset Fuel Gauge Chip:
N.E.A.K KERNEL
Thread | App - N.E.A.K Configurator
TAB 1 - NEAK Options:
1) Governors: By default, NEAK comes with Ondemand, Lulzactive and Performance only. To have more governors available, enable from the list and reboot. Conservative governor can also have lionheart tweaks enabled. (Lionheart = aggressive conservative). Selected governors will be loaded on reboots, as module(s).
2) SCHED_MC: Yes you have read multiple times that enabling load-balancing via Linaro's Shedule Multi-Core is redundant and is of no particular use in an hotplug enabled device. Leave it unchecked.
3) AFTR Idle Mode: Enable AFTR+LPA. Use this to have better battery life. The battery life is 'bettered' by hitting deep idle states before the actual deep sleep. If and only if there are issues, leave it unchecked. Possible issues are stuttering videos/lagging gui, etc. This kinda issues arises when AFTR is hit too soon.
4) Ext4 Boost Optimizations: Enable to have remount scripts run during every boot-up. May increase disk performance.
TAB2 - OTA Downloader
Download OTA APP: Click to download Kernel OTA app. OTA app can be used to check and download new releases without visiting xda.
Q. "Even though i could understand everything you stated here about, what exactly does those sample values/recommended settings do? Will i get 8 hours screen-on and 8000 Antuntu?"
A. We have a Galaxy S2, not Nokia 1100. We should utilize and enjoy the performance of the phone. The values recommended were intended to give snappiness without compromising too-much battery life. Our definitions of 'too-much' may be different. But i assure you the difference isn't too much!
I/o schedulers
4. I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) 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.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) 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.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Q. "How do i change I/O schedulers?"
Voltage Control or No Frills from market.
Or init.d script:
echo "scheduler-name" > /sys/block/mmcblk0/queue/scheduler
Q&A and Tweaks
5. DUAL CORE CPU Q&A and TWEAKS
Q&A on parameters and factors that control the performance, throughput and battery-life delivered by GS2's dual-core CPU, and some CPU tweaks
Q. "What is the basic hardware of GS2 that make all of us enjoy this phone so much and boast about benchmark scores to office-mates and friends?"
A.
Processor: ARM Cortex-A9 MPCore processor on Exynos 4210 SoC (System on a Chip - ICs where all components are integrated into a single chip) and 45nm semi-conductor technology. Exynos 4210 is supposed to give 6.4GB/s memory bandwidth for heavy-weight ops such as full hd video encoding.
GPU: ARM Mali-400
Memory: LPDDR2 (may be DDR3)
Q. "What is the significance of bus frequency?"
A. Bus speed at its simplest form determines how fast the data should travel to and from memory. Memory throughput is directly proportional to bus frequency. In tasks that includes small amount of work on every element in a data sets, lower bus speed means longer the CPU has to wait for data to arrive from memory. Because, CPU spends only little time on each of these elements, and a slow bus cannot catch-up.
Advanced Micro-controller Bus Architecture (AMBA) is used as the on-chip bus in system-on-a-chip designs, like our device.
Q. "What is modifying bus frequency? How do I do it? Advantages?"
A. Stock behavior is dynamic bus frequency scaling, where in operating bus speed is dynamically calculated for each CPU frequency depending on the application/process’s requirement. We can modify this behavior by setting static bus frequency scaling, specifying at what bus speed should each CPU frequency operate. Three values/levels are possible.
0 – 400 mhz
1 – 266 mhz
2 – 133 mhz
Sample bus frequency modification:
echo "0 0 0 1 1 1 2 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo "enabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
This means for first three higher CPU frequency steps, 400 mhz bus will be used.
Next three, 266 mhz
And last two, 133 mhz
Advantages of bus frequency modification: i) Saves battery by using low bus speeds on low frequencies and ii) Prevent overheating.
Q. "I experience some lags sometimes while playing HD videos or playing heavy 3d games using static bus frequencies. Why?"
A. HD videos and some games require a minimum of 400/266 mhz bus irrespective of the CPU frequencies being used during the run. To resolve, set higer bus for 500 mhz and higher frequencies or simply disable static bus frequency scaling to switch to default.
echo "disabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
Q. "Our phone CPU has two cores. How are they utilized? Are the two cores ON all the time?"
A. The stock behavior is Dynamic Hot Plug Mode where depending on the load, the second core is turned on. If the load can be handled by a single core, the second core is turned off dynamically. This behavior can be controlled by using Tegrak Second Core app from market if your kernel supports it. (Siyah, Lulz,etc supports this). Using this app you can set three modes :-
Dynamic Hot Plug Mode: Default mode. Second core is kicked in depending on the load, and kicked out when first core can handle the load alone.
Single Core Mode: Irrespective of the load, only first core is used always. This can lead to increased battery, but reduced performance.
Dual Core Mode: Irrespective of low loads, both the cores are always active. Increased performance, but reduced battery.
Recommendation: Use the stock hotplug mode during normal use. Switch to dual core mode only for benchmarking or playing some heavy 3d games.
Q. "OK, I'm using hot plug mode, still i want to control how often the second core kicks in. To make it more aggressive/more mild depending on my usage."
A. You can set UP & LOW thresholds for second core in Screen-On and Screen-Off states.
Examples:
echo "70" > /sys/module/pm_hotplug/parameters/loadh
echo "25" > /sys/module/pm_hotplug/parameters/loadl
echo "90" > /sys/module/pm_hotplug/parameters/loadh_scroff
echo "35" > /sys/module/pm_hotplug/parameters/loadl_scroff
As you can see, when load > 70% second core becomes active and when load drops below 25%, second core is turned off.
During screen off, these values are 90 & 35 respectively. This helps in reducing unwanted kick-ins of second during screen-off state when music is playing, downloading, etc.
Q. "Like governors, is there a sampling rate/interval also at which the load on CPU is checked for crossing thresholds to turn second core ON?"
A. Yes there is. But it is set at kernel level in most kernels and can not be controlled at user level. Like you guessed, higher sampling rate could cause core 2 to kick in less often and thus save a little battery. In Siyah kernel though, these thresholds are configurable.
Q. "Advantages/Disadvantages of switching to Single Core/Dual Core modes?
A. Using only single core can save some battery, but can have some adverse effects too if there are some heavy tasks that require both cores too often: 3d games, full hd videos, etc. So use it wisely.
Using dual core mode can reduce latency by a tiny bit on high loads, as compared to hot plugging. But hot plugging is intelligent enough to turn second core ON really fast when load demands it. Only first core (cpu0) can enter deep-idle (LPA), so using dual core mode in an idle system cause unwanted excess-power consumption.
Recommendation: Use Hot Plugging and tune thresholds (like mentioned above) for a better experience.
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.
Q. "What is MALI aggressive policy on GPU?"
A. Mali aggressive scaling policy is simply lowering the up-threshold of GPU so that GPU doesn't jump to second frequency step too often. This makes more sense if lower step is under-clocked. In one release of Siyah, the threshold was changed to 55 from default 65.
Q. "What is tree rcu, fast nohz, jrcu?"
A. Read-Copy Update (RCU) is a synchronization mechanism added to Linux kernel. RCU improves scalability by allowing readers to execute concurrently with writers.
Tree RCU is a new implementation of original classic RCU to achieve more scalability as the number of CPUs increase. Tree RCU fixes a performance bug in classic RCU that results in massive lock contention on the internal RCU lock on systems with large number of CPUs.
Fast NoHz is an optimized version of the traditional Tree RCU. Many new kernels are using the Tickless NoHz design. This RCU is tailored and designed to work with the new NoHz kernel system.
JRCU mechanism in its simplest form, runs batch operations from a single CPU relieving other CPUs from this periodic responsibility. This is important for those real-time applications requiring full use of dedicated CPUs. For our dual core single CPU, JRCU can conflict with hot-plugging, hence we will have tree rcu (with or without CONFIG_RCU_FAST_NO_HZ) in our kernels.
Q. "What are SLAB, SLUB, SLQB?"
A. They're three memory allocation mechanisms.
Slab allocation is a memory management mechanism intended for the efficient memory allocation of kernel objects which displays the desirable property of eliminating fragmentation caused by allocations and de-allocations. SLAB is used to retain allocated memory that contains a data object of a certain type for reuse upon subsequent allocations of objects of the same type.
SLUB allocator promises better performance and scalability by dropping most of the queues and related overhead and simplifying the slab structure in general, while retaining the current slab allocator interface. SLUB offers to make alignment of objects and cleaning up of caches easier, as compared to SLAB.
SLQB - SLAB allocator with Queue. This is a slab allocator that focuses on per-CPU scaling. This memory allocator is designed for small number of CPUs system. This allocator is designed to be simple.
Note that SLUB is significant on a system with large number of CPUs. SLAB has the advantage of being simple.
Q. "Can i change the RCU synchronization mechanism & memory allocators?"
A. NO. They are set at compile time at kernel level, and are not configurable from user space.
MISC Q&A
Q. "What is top-off current?"
A. Charge cycle for the device's battery actually consist of two stage.
First stage consist of supplying a constant current until battery reaches it's constant/peak voltage, something between 4.1 and 4.2 v.
Upon reaching this peak voltage, a constant voltage is applied until the charge current goes below top-off current. This is the second stage. Stock top-off current is 200ma. From Siyah 2.6.9, it is set to 100ma just so that a little more juice goes into battery since a lower top-off current means longer the constant voltage is applied in the second phase of charging.
If you love your battery, do not charge to 'real' 100% too often. Perform the 'trickle' charge only once every 20 days or so.
Q. "My battery drains fast sometimes immediately after a kernel flash. It's like this: i reboot the device with 40 percent battery left and when it returns, i have only 20 percent left. Anything i can do?"
A. Your battery is not actually draining fast. But the fuel gauge is showing funny values which is not the real percentage left. On high-loads, like immediately after you reboot cause the fuel gauge to report low percentages. What you can do is to reset the fuel gauge.
[Courtesy Entropy512. The code is for i9100. Location of reset-file may be different in other variants of GS2]
Give it a few hours after you reset the gauge. It may still show you funny values for those period, then the battery percentage should be fine.
Code:
echo "1" > /sys/devices/platform/i2c-gpio.9/i2c-9/9-0036/power_supply/fuelgauge/fg_reset_soc
Q. "So CPU/GPU or GPS chip, which is the biggest power drainer in GS2?"
A. It is the bright amoled display! Display uses roughly 370mW average and 960mW with 100% brightness full white screen. Avoid bright wallpapers, reduce brightness.
Q. "What're the approximate power consumptions by the device peripherals & activities?"
A.
AMOLED Display: Average - 370mW. Full white background, 1% brightness - 450mW. Full white background, 100% brightness - 960mW. So roughly every percentage of brightness increased accounts to additional 5.2mW. (Now we know why using dark wallpapers and reducing brightness is so important than undervolting).
Illuminated button - 40mW
Led lamp next to camera - 1.3W
Camera - 700mW
Bluetooth and GPS - 110 to 180mW (Really?!)
2G to 3G switching - 800mW for 8 seconds. (This is no h/w component, but we should know)
CPU 1.4 Ghz full load, 100% brightness - 4W+
CPU 1.4 Ghz average - 3.2W
CPU 1.6 Ghz full load - 5.9W (Forget Ocing to 1600mhz)
BLN - 200mW during suspend state opposed to deep sleep 8mW without BLN.
Wifi download - 1.51W
2G download - 1.598W
2G upload - 853mW
3G download - 1.603W
3G upload - 2.136W (Stay away from uploading your videos to youtube via 3G)
Q. "Sometimes the device says 'low battery' and switches itself off. But when i turn it on, there's 30% left. Why?"
A. Some heavy load conditions such as quickly reaching 1600mhz on full load, etc will cause the battery voltage to time below 3.3V and this is wrongly interpreted by the battery as empty.
Q. "What is 500 mhz core voltage bug?"
A. It's not a bug. It's a safety feature. What is it: When frequency is raised to 500 from a frequency below it, core voltage used for 500mhz is the core voltage of 800mhz. When frequency is dropped to 500 from a frequency above it, core voltage used is it's own voltage. So climb to 500 uses 800's volt and fall to 500 uses it's own volt. If you're UVing do it properly for 500 and 800. Now you know why.
SIYAH SPECIFIC TWEAKS (2.6 gingerbread versions)
Summary of all user configurable parameters in Siyah kernel. Some which were already listed in above posts, and some which i may have missed out. Let's have everything in one place, with examples.
1) CPU Frequency & Voltages
#Set frequency steps according to the number of steps in your kernel.
echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/freq_table
#Set voltages for frequency steps. Changes possible at +/-25mV steps
echo "1425 1325 1275 1175 1075 975 950 950" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
#Sets global scaling min&max frequencies
echo "200000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1400000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2) Scaling Governor & Smooth Scaling Parameters
#Set scaling governor, according to available governors in your kernel
echo ondemandx > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#Smooth scaling parameters to control any governor jumping to higher frequency directly (other governor specific tweaks in first post).
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step
note: Smooth scaling is disabled for interactive based governors: Interactive, Interactivex and Lulzactive in Siyah. Idle loop based governors shouldn't like throttling.
When CPU is on a certain frequency (let's call this current_freq) and governor decides to jump CPU up to a higher frequency (let's call this target_level), Then
If target_level less than smooth_target, CPU jumps either to smooth_target+smooth_offset or current_freq-smooth_step, whichever is smaller.
Note that L0=1600 mhz, L1=1400 mhz, L2=1200 mhz, L3=1000 mhz, ..., L7=100 mhz
Example:
CPU current_freq is 500 (L5) and Ondemand governor decides to jump to 1400 (L1).
We have smooth_target = 2 = L2, smooth_offset = 2 and smooth_step = 2
smooth_target + smooth_offset = L2+2 = L4 = 800 mhz
current_freq - smooth_step = L5-2 = L3 = 1000 mhz
Since 800 mhz is smaller CPU jumps to 800 mhz first and then 1400 mhz.
3) GPU Clock, Voltages, Thresholds & Staycounts
#Set GPU clocks ( valid values are 400/(x*0.5) where x is an integer >= 2. So valid values will be 400/1,400/1.5,etc. Examples: 40 80 89 100 114 133 160 200 267 400 )
echo "160 200 267" > /sys/class/misc/gpu_clock_control/gpu_control#Set GPU voltages (changes possible at +/-50mV ie at 50000 steps)
echo "900000 950000 1000000" > /sys/class/misc/gpu_voltage_control/gpu_control
#Set GPU Up and Down thresholds
echo "85% 55% 85% 50%" > /sys/class/misc/gpu_clock_control/gpu_controlWorking of Thresholds:
Up threshold for Step 1 (160 mhz) = 85% [GPU scales up to 200 from 160 when load >= 85%]
Down Threshold for Step 2 (200 mhz) = 55% [GPU scales down to 160 from 200 when load < 55%]
Up Threshold for Step 2 (200 mhz) = 85% [GPU scales up to 267 from 200 when load >= 85%]
Down Threshold for Step 3 (267 mhz) = 50% [GPU scales down to 200 from 267 when load < 50%]
Step 1 will not have a Down Threshold & Step 3 will not have an Up Threshold since they don't have a step to scale-down to or scale-up to.
#Set GPU Staycounts. Staycount act as rate multiplier for GPU sampling intervals. Now you have complete control over GPU!
echo "1 1 1" > /sys/class/misc/gpu_control/gpu_staycount
4) Hot Plug Thresholds, Sampling Interval & Frequency
#Set second core kick-in threshold for screen-on state
echo "25" > /sys/module/pm_hotplug/parameters/loadl
echo "70" > /sys/module/pm_hotplug/parameters/loadh#Set second core kick-in threshold for screen-off state [Forcing second core NOT to turn on during screen-off make it easier for first core to hit deep idle, hence power savings]
echo "35" > /sys/module/pm_hotplug/parameters/loadl_scroff
echo "100" > /sys/module/pm_hotplug/parameters/loadh_scroff
#Set hot plug sampling intervals for screen-on state
echo "200" > /sys/module/pm_hotplug/parameters/rate
echo "400" > /sys/module/pm_hotplug/parameters/rate_cpuon
rate is the sampling interval to check if second core should be kicked-in, if present load >= loadh.
rate_cpuon is the sampling ineterval to check if second core should be turned off (if already online), if present load < loadl
#Set hot plug sampling intervals for screen-off state
echo "800" > /sys/module/pm_hotplug/parameters/rate_scroff
rate_scroff is the sampling interval used in screen-off state to check if second core should be turned on, if current load >= loadh_scroff
If second core is already online, rate_cpuon is used as the sampling to check if second core should be turned off
For more info on Hotplug sampling and behavior, please see this post. Unit for these sampling intervals are jiffies. Since frequency of GS2 system timer = 200hz, divide jiffy value by 200 to convert into seconds.
#Set frequency below which second core will not be turned on, regardless of thresholds.
echo "500000" > /sys/module/pm_hotplug/parameters/freq_cpu1on
If CPU frequency <= 500 mhz, then second will not be turned on.
5) Deepsleep Levels
#Set deep sleep frequency & bus speed (L4=800 mhz and 0=400mhz bus speed)
echo "4" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel
6) I/O Schedulers
#Set i/o scheduler
echo "sio" > /sys/block/mmcblk0/queue/scheduler
7) Bus Frequencies
#Set bus frequencies for highest-to-lowest CPU frequencies and enable static bus frequency scaling
echo "0 0 0 1 1 2 2 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo "enabled" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
Bus speeds: 0: 400 mhz | 1: 266 mhz | 2: 133 mhz
8) Schedule Multi Core & Idle Modes
#enable sched_mc
echo "1" > /sys/devices/system/cpu/sched_mc_power_savings#enable AFTR
echo "3" > /sys/module/cpuidle/parameters/enable_mask
9) Touch Sensitivity Parameters
#touch sensitivity
echo "50" > /sys/devices/virtual/sec/sec_touchscreen/tsp_threshold
Possible values are between 40 to 80. Lower value = higher sensitivity.
Also use Tegrak's Touch Move app from market to further control touch sensitivity
10) Charge Current
#set AC, Misc & USB charge current
echo "750 650 450" > /sys/devices/virtual/misc/charge_current/charge_current
AC refers to wall charger current, MISC refers to car charger current , USB refers to usb charge current from pc. Do not set Ac & Misc more than 1000mA or Usb more than 450.
11) Brightness Curve Settings
#brightness settings
echo "30" > /sys/class/misc/brightness_curve/min_bl
echo "1" > /sys/class/misc/brightness_curve/min_gamma
echo "24" > /sys/class/misc/brightness_curve/max_gamma
We will have lowest brightness or zero gamma for brightness level read from sensor < 30. Above that, it is linearly mapped to [min_gamma:max_gamma] which is [1:24] here.
To increase the minimum brightness, decrease the min_bl.
Possible values for min_bl = 0 to 255 | min_gamma = 0 to 24 | max_gamma = 0 to 24
12) Switch Hotplug/DualCore/SingleCore
#Dynamic hotplug mode
echo "on" > /sys/devices/virtual/misc/second_core/hotplug_on
#Single core mode
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "off" > /sys/devices/virtual/misc/second_core/second_core_on
#Dual core mode
echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on
echo "on" > /sys/devices/virtual/misc/second_core/second_core_on
The above script is a replacement for Tegrak's 2nd Core app, for those who don't like apps to set something on boot.
Nice work droidphile, this will help many people around here.
One more thing, can you add the details about bus frequency selection? It will be helpful for starters
Sent from my GT-I9100 using xda premium
bala_gamer said:
Nice work droidphile, this will help many people around here.
One more thing, can you add the details about bus frequency selection? It will be helpful for starters
Click to expand...
Click to collapse
I will add bus frequencies and other parameters soon.
respect!!!!
Nice work droidphile
Wow, this is a real good work droidphile. I think this thread should be locked and sticky or at least only sticky.It's not only useful for siyah kernel. It could be used as an example for everyone. Thanks for the time you took to help nood
Excellent thread. Stuck
nice work dude
Really happy to see someone took this task on their shoulders.Well done droidphile,our fellow flashmaniac.
Hope you are ready to accept all these noobs in your thread,eh?
tolis626 said:
Really happy to see someone took this task on their shoulders.Well done droidphile,our fellow flashmaniac.
Hope you are ready to accept all these noobs in your thread,eh?
Click to expand...
Click to collapse
Well, trying to add more noob questions and more info in first post so that i don't have to deal with too many questions
how this kernel compatible with δ-HyperDroid-Androidmeda-v3.0 ?
THX
This is not Siyah Q&A thread. This is.
I guess it is compatible with hyperdroid. Siyah is an unified kernel for stock/stock based and aosp roms.
If you're not sure, take a nandroid backup first. Then flash Siyah.
Thanks
Thanks for making such a useful thread!
droidphile said:
This is not Siyah Q&A thread. This is.
I guess it is compatible with hyperdroid. Siyah is an unified kernel for stock/stock based and aosp roms.
If you're not sure, take a nandroid backup first. Then flash Siyah.
Click to expand...
Click to collapse
Excellent thread, thank you very much!
Just couple more noob questions you can add to your Question Time:
1. How to edit/change init.d script to change governor? Any examples, please?
2. How to check which governor is on by default? (in Siyah it is mentioned that default one is ondemand)
1. To change governor, Ex:
echo "smartassV2" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
2. To check active governor, just use Voltage Control/SetCpu. Or by script:
echo $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)
More info on init.d scripts: http://forum.xda-developers.com/showpost.php?p=19519757&postcount=10699
Many battery-life-tips mentioned here DON'T need any modifications to your Z.
Please don't post discouraging things like...
-"Why all the fuzz? Buy a external battery"
-"Why BLunlock/undervolting/-clocking/rooting and voiding warranty?"
...we all know that.
There are many factors influencing screen-on-time. Please read the must-read-section before you judge my thread.
THIS THREAD IS ABOUT OPTIMIZING BATTERY LIFE OF THE SONY XPERIA Z WITHOUT SACRIFICING TOO MANY FEATURES OR MUCH OF USER EXPERIENCE/PERFORMANCE. THIS IS A UNFINISHED ONGOING PROCESS.
Don't forget: If you like what you read, please press the thanks-button.
TABLE OF CONTENTS
I. INTRODUCTION
I.1 Prologue / Must read
I.2 My average usage pattern
I.3 Change-Log
I.4 To-do
II. BATTERY SAVING TIPS
II.1 General-section (tips everyone can apply)
II.1.1 Tips I use
II.1.2 Tips I don't use (but you can)
II.2 Root-section (additional: tips for rooted devices)
II.2.1 Tips I use
II.2.2 Tips I don't use (but you can)
II.3 Bootloader-section (add.: tips for bootloader-unlocked devices)
II.3.1 Tips I use
II.3.2 Tips I don't use (but you can)
III. MISC
III.1 Thanks to
III.2 Translations
III.3 Results
I. INTRODUCTION
I.1 Prologue / Must read !
Hi everyone,
First I should introduce myself a little: I'm from germany, 24 years old and currently studying technology of information systems. Since xda helped me alot, I also want to share with you all I know about optimizing battery life.
A XZ with all-standard-settings (without my tips) currently only gets approx. 4,5-5 h with my average usage pattern. And max. 3,5 hours with heavier usage (while travelling e.g.). With heavy games even less.
After implementing my tips I often get 7h+ of REAL USAGE battery life (=screen-on-time = SOT =s-o-t) with my Xperia Z. Sometimes I even get more SOT: see e.g. my screenshots of 7:09 h SOT with remaining 6% and 20 hours since last charging. But I also sometimes only get 5 hours (with heavier usage, while travelling e.g.).
I'm not bragging, please do not misunderstand me. If we crippled all smartphone-features, turned everything off and only read books with the XZ, we could even get 9-10 hours SOT...but thats not what I want to achieve!
There are many factors influencing screen-on-time: Your individual usage, your individual apps, your apps' (obligatory) wakelocks, your cell/data/wifi receiption during the day, provider-support of fastdormancy, your XZ's undervolt capability, ...
Also everyone has his own taste:
Some like 1.5 GHz+4cores+100% brightness all day+5 homescreens+... And some don't.
I only write down ALL tips I know/find. I do not use every single one of them, because some would lower my comfort. But I write them down for you, because I respect everyones individual usage. So please don't blame me for everything or talk bad about my thread in other threads.
You can decide which tips you like to use, which you don't.
Greetings
Seb
I.2 My average usage pattern
- browsing a lot with dolphin browser (sonar etc. disabled with elixir; 'Google Chrome' consumes too much battery, causes many wakelocks and has no flash-support)
- reading hundrets of tech-news with gReader (almost all news include pictures and some videos; hardware acceleration on)
- listening to music with walkman (20 min/day)
- watching some youtube (at least 3-4 videos; each 2 to 15 min long)
- reading for about half an hour (with kindle app or adobe reader)
- usung tapatalk for xda a lot
- whatsapp a lot
- reading many mails with KAITEN MAIL (many include pdf) and let synchronize 2 of 4 email accounts every 3 h and the remaining 2 every 6 h
- sms: 1/day
- calls: 20min/day
- photos: 2/day
- using wunderlist
- checking ebay: 1x/day
- VNC to enter business-pc remotly 2x/day (5-10 min)
- a lot 9gag
- Widgets on 2 homescreens:
4x Kaiten Mail-Widgets (counters for unread emails)
1x Walkman-Widg.
I.3 Changes to this post
31.12.13
- corrected formatting
27.12.13
- Updated and added many new tips to bootloader section (e.g gpu-undervolting!)
- Updated and added many tips to root section
- Updated general section slightly
- Updated prologue slightly
- Updated usage pattern slightly
- NEWS1: Switched to XzKernel by alnikki25k because it currently offers more features, runs smoother and gets updated more frequently
- NEWS2: Lifted my max. cpu-freq from 1.24 to 1.35ghz, which won't effect battery life too much anylonger ( -15 min SOT)
Earlier changes: deleted because of limited space
I.4 To-do
- add measurement-section
- give some milliampere-values
- Shorten all sections/texts/tips
- Find the holy grail of battery life saving
II. BATTERY SAVING TIPS
II.1 General-section
II.1.1 TIPS I USE:
- Update to Android 4.2.2 (currently use stock-sony-firmware .67), but will switch to 4.3 as soon as we get a working custom kernel for it
- if contract has no LTE/4G, so set the network mode to wcdma/gsm (the LTE/4G-chip sucks a lot of battery (better disable it, if you don't need more than the 21 Mbit/s 3G/hsdpa+ provides)
- If you can choose: use Wifi over 3G over LTE (in general). But if 3G connection is fast and wifi very slow, use 3G! Avoid LTE/4G if you do not need more than 21 Mbit/s.
Use "ONLY 2G" only if 3G receiption is extremly poor and as slow as 2G, but 2G receiption is great.
- stamina on (only whatsapp whitelisted). Reset stamina mode if it doesn't work properly (clear cache). Stamina is (mostly) better than turning phone off several times per day, because boot consumes too much battery (especially if many apps load at boot).
- battery settings > battery save mode: on (from 100%; excluding wifi+auto sync)
- wifi set to not search for networks/no notification,
- wifi set to stay always on (turning off during standby will help battery, but every custom kernel has an issue with the wifi drivers, so set wifi to "always on" which circumvents this issue),
- Brightness set automatically to 25% during the day and 0% in the evening with my TASKER-profile (below). more info in root-section.
- NFC off (only on when needed)
- Bluetooth off (only on when needed)
- GPS off (only on when needed)
- charging at 6-10% remaining battery (below could harm your battery and decrease battery life over time...but this is a highly controvertial topic, so I charge at 10% to be on the safe(r) side)
- Reduce wakelocks:
- Install 'Wakelock Detector' to find partial wakelocks and alarms which wake the XZ during standby. Many unnecessary wakelocks can easily be reduced (like fastdormancy). But some may need root access. Here is a very helpful link for wakelocks: http://forum.xda-developers.com/showthread.php?p=38629490#post38629490
- In settings > apps > all apps > select an app: Deactivate the notifications of all apps you don't want to be notified by. Can reduce wakelocks!
- Turn OFF 'developer settings' when not using it (stops their services, wakelocks)
This section will grow in time!
- Google Now off: long-press on home-button > google search > settings > turn google now off
- Let your Wifi-Router always work with 100% signal-power, wifi g+n. This way you will get better wifi-receiption with your Z (might squeeze some minutes/your phone won't connect to data unnecessarily)
- Don't overprotect your phone with metal cases over metal cases Receiption of Cell, 2G/3G/LTE, Wifi, Bluetooth etc. will decrease and your battery life too (a lot)
- Turn Restore & Backup off: settings > restore & backup
- Google Settings App > Location > Turn OFF: Location history + location protocol /summary(? don't know the english name of that button)
- Google Settings App > Search > Turn OFF: Webprotocol + search-results shall not include apps/... (deactivate anything you don't need)
- Deinstall or deactivate FACEBOOK, if you don't use it. If you really need it, change the notification settings + update settings + push-settings according to your REAL needs. This app is a hugh battery consumer and it causes far too many wakelocks which will prevent the phone from entering sleep modes (even when the phone is not being used).
- Settings > Sound(?) > Turn OFF: vibration when touching screen + sound for every screen press + sound for unlocking + xloud + sound for call-buttons
- Settings > Accounts > Google > Turn OFF: google-personalized-advertising + every synchronization you don't need (I don't sync apps and google books because I use Titanium Backup)
- Often forgotten but basic tip: Search for unnecessary settings or battery saving features in the settings of your favourite apps. E.g. many apps allow to deactivate unnecessary settings or ugly special effects/animations which drain battery. OR many apps let you deactivate (maybe in your case: ) unnecessary push notifications...
- Settings > Display > Sleep > After 1 Minute (mostly sufficient)
- Update your apps regularly, because new versions often improve performance, battery drain, wakelock-issues etc. Still: make backups!
[/HIDE]
II.1.2 TIPS I DON'T USE (but you can):
- Display brightness always at 0%
- Wifi set to "save battery when connected" (may cause problems with some custom kernels, so I currently don't use it!)
- Data/cell/wifi/bluetooth always off (e.g. if you only play games/read books)
- Calibrate your battery (this can bring back 5-10% of your battery life, depending on its condition). This tip was discussed a lot. I didn't calibrate my Zs battery yet. Everyone says something different and the manufacturers like sony give instructions for (first) battery cycles... So I leave it up to you to decide if its a myth or not
- Set all animations in dev-settings to 0 x (settings > about phone > press 10 times on the built-number > go back and now you got the dev-settings below)
- Sleep screen after 15 sec
- Turn background sync and auto-sync and google account sync OFF
-Reduce every wakelock possible by spending hours for finding their causes, deinstalling/deactivating all thats necessary to reduce it...etc...
II.2 Root-section
II.2.1 TIPS I USE
- Installed TITANIUM BACKUP PRO and deleted all bloatware/google apps/..
All I didn't need or like or which drained too much battery.
Here is a list of all deleted apps:
com.android.providers.partnerbookmarks.res.overlay
com.sonyericsson.android.socialphonebook.res.overlay
com.sonyericsson.trackid.res.overlay
com.sonymobile.connectivitycenter
Sapphire 10.0.A.0.16 (com.sonyericsson.bluetheme)
Silk 10.0.A.0.16 (com.sonyericsson.blacktheme)
VerifyCertificatesDummyApp
Xperia Twitter Setup
com.sonymobile.datadisclaimer
Anonymous Usage Stats
com.sonymobile.cameraautoupload
Backup-Restore
com.sonyericsson.lockscreen.uxpnxt
Black Hole
Bubbles 1.0
com.android.backupconfirm
com.android.providers.partnerbookmarks
com.android.sharedstoragebackup
com.google.android.voicesearch
com.sonyericsson.unplugchargerreminder
Converter 6.1.1 (com.sonyericsson.androidapp.converter)
Device Usage 1.0.A.0.11 (com.sonymobile.phoneusage)
E-Mail 4.0.1 (com.android.email)
com.sonyericsson.retaildemo
Emerald
com.sonyericsson.music.wikipediaplugin
com.sonyericsson.music.youtubeplugin
com.sonyericsson.music.youtubekaraokeplugin
com.sonyericsson.music.googlelyricsplugin
Exchange Services
Face Unlock 4.1.2-509230 (com.android.facelock)
foursquare 2012.03.09 (com.joelapenna.foursquared)
Infinite view 10.1.A.0.0 (com.sonyericsson.infiniteview)
com.sonyericsson.androidapp.memorycardinstaller
Market Feedback Agent
Mono 6.1.A.0.1 (com.sonyericsson.android.pobox.skn.mono)
com.sonyericsson.metadatacleanup
OMA Client Provisioning
Oma Download Client
OmaV1AgentDownloadServices
Picasa Uploader
Pico TTS
POBox Touch
Quartz
Remote Control Service
com.sonyericsson.vendor.backuprestore
SkinSelector
Smart Connect
com.android.voicedialer
Tags
TalkBack
TrackID
Update Center
com.sonyericsson.verifycertificatesdummyapp.application
com.sonyericsson.verifycertificatesdummyapp.platform
com.sonyericsson.verifycertificatesdummyapp.shared
com.sonyericsson.advancedwidget.weather
Wfd Service
Woody
Xperia AppShare
Xperia Calendar Sync
Xperia FB Setup
Xperia Friends’ Music
Xperia Link
Xperia Music Likes
com.sonyericsson.facebook.proxylogin
com.sonymobile.twitter.account
Xperia Share
Xperia Social Engine
com.sonyericsson.socialengine.plugins.facebook
com.sonyericsson.socialengine.plugins.picasa
com.sonymobile.socialengine.plugins.playmemories
com.sonymobile.socialengine.plugins.facebook_sharefrwk
com.sonymobile.socialengine.plugins.twitter_sharefrwk
com.sonyericsson.androidapp.everchwallpaper
Google Chrome
+ all branding-/carrier-specific apps
- Installed ELIXIR2 and deactivated all kinds of entries I don't need. Examples of activities/receivers/services you can disable:
BE CAREFUL:
If you deactivate vital activities/services/receivers of an app the apps won't work properly anylonger or the app will crash. But thats no problem! Just check the apps and and activate activities/services/receivers e.g. one-by-one to find the cause of the crash and leave it activated.
Deactivate e.g. every ACTIVITY that says (differs from app to app):
-facebook.login
-.analytics.
-.tracking.
- google.ads.AdActivity
- .googleplus.
- .gtalk.
-.ads.
-.voicesearch.
And all kinds of RECEIVERS that will boot apps at boot (if not necessary):
-.onboothandler.
-.bootreceiver.
-.devicestartup.
And SERVICES:
-again: .analytics.
-.gtalk.
-googleplus.
- Install GREENIFY+donation-version (needs Xposed Framework!). Then activate all experimental options like boost mode, gcm push, greenify system apps...
and after that greenify some system apps like google maps etc. (according to your needs)
- Installed Xposed Framework and following modules:
1. "Greenify" (donation-version necessary) and activate all options
2. "BootManager". Deactivate all apps you don't want to load when starting up
3. "ReceiverStop" (if you didn't like Elixir2): Deactivate all unnecessary receivers
4. "App Settings": reduce permissions if necessary
5. "Per App Hacking": prevent services and wakelocks, but becareful...
It can cause apps to not work anymore!
6. "YouTube AdAway": especially helpful fot those watching alot. Why drain battery for ads?!
- Installed TASKER and SECURE SETTINGS (and its helper; see settings).
I currently automated following things (you can also download my tasker-backup below):
Tasker is consuming little power in the background, but is a powerfull tool.
My Tasker-Profile isn't very sophisticated. Working on it, but don't want to use other peoples profiles. You can deactivate/change any feature easily in tasker, if you don't want to use it:
- 18:00 until 08:00 o'clock (6PM till 8AM): Brightness set to 1% (in the evenings 1% is enough mostly and reduces consumption by a high margin) + Turn Rotation off
- Rotation only ON with certain apps and automatically turn off
- Hibernate with Greenify every 3 hours (sometimes the built in autohibernation of greenify won't work, so tasker triggers
- GPS ON when GOOGLE MAPS, NAVIGATION start and turn OFF automatically when closed
- Turn OFF Data when connected to Wifi since 5 Minutes
- Install BuiltProp Editor and add these lines to the end of the built.prop:
(Thanks to …… for this tip):
#signal tweak
ro.ril.enable.3g.prefix=0
ro.ril.enable.dtm=0
ro.ril.hep=0
ro.ril.hsxpa=5
ro.ril.enable.a53=1
ro.ril.gprsclass=12
ro.ril.hsupa.category=9
ro.ril.hsdpa.category=36
____
This will increase receiption by lifting 2G/3G-settings. It increases battery consumption, but over the day the better receiption makes up for that (at least for me).
II.2.2 TIPS I DON'T USE
- ELIXIR2 is hardcore...you could even deactivate EVERY button/activity/service (those which you asume you won't ever need) of all your apps...could save some processing time and therefore battery life
-Installing ES EXPLORER and deleting in the apps-folder:
fast dormancy.apk and .odex ( both ONLY if your provider doesn't support fastdormancy)
-Reducing Wifi-consumption by editing the ini-files in etc/firmware/wlan/prima/
-Reducing 2G/3G/LTE-consumption by editing their ini-files
-With Overlays (App) we can make buttons/switches hovering over apps. In some cases it could save battery (especially in combination with tasker and zoom).
-I tested wether the LTE-Switch for the upper menu will switch back the network mode to "GSM" (=2G) if I activate and then deactivate LTE... Worked! The LTE-switch turns on 2G+3G+LTE but my contract doesnt have LTE so maybe the LTE-chip won't consume anything after a first connection attempt... Then the LTE-switch would effectivly be a 2G/3G-switch for me Update: Switching back and forth is uncomfortable and automation isn't possible without deep rom-modifications... a dead end currently
II.3 Bootloader-section
II.3.1 TIPS I USE:
- Flash @alnikki25k 's custom stock kernel XzKernel
- In TRICKSTER MOD + FAUXCLOCK (!!) do following:
0. Set CPUs to 384 mhz - 1,35 ghz
1. Governor to intellidemand (settings: see below)
2. Set scheduler to 'sio'
3. Underclock the GPU to 325mhz and set gpu-scheduler to "ondemand"
4. Multicore power saving = 0
5. Dynamic FSYNC = on
6. Ecomode = on
7. Mp-decision = off
8. Intelli-plug = on
9. ZRam = off
9.1 Delete VFS cache after boot: on
9.2 Auto FS Writeback: on
9.3 swappiness: 0%
9.4 vfs cachepressure: 150%
9.5 dirty ratio: 20%
9.6 dirty background ratio: 5%
9.7 TCP congestion control: westwood
10. Read_ahead (emmc + sdcard): 2048 mb
10.1 Entropy (emmc + sdcard): off
11. Frequency Lock = on
12. In faux clock: activate c0, c1, c2 and c3 states
13. IMPORTANT TIP FOR SMOOTHNESS: Deactivate gpu's vsync (activate it if you are a egoshooter-gamer)
14. In faux clock: Set a profile for every app which does (or does not) need much performance. Here is an examples:
'Whatsapp' doesn't need high cpu-freq and 400 mhz gpu-freq to run smoothly. We can set a profile for it with these settings:
Min freq: 384 mhz
Max freq: 1188 mhz
gpu freq: 200 mhz
ecomode: on
FOR GAMES you could e.g. slightly overclock frequencies, turn ecomode off and use 450 mhz gpu-freq
14. CPU: Undervolt to these VOLTAGES (ONLY IF YOU KNOW WHAT YOU ARE DOING !!) :
Please ONLY undervolt when you already know all about it...and undervolt slowly (in -25 or -50 mV steps e.g.)
until you reach a stable new voltage for each frequency. Always test several times with benchmarks and all your apps and for 1h at least
MY (VERY LOW) VOLTAGES MIGHT NOT WORK FOR YOUR XZ !
MAKE BACKUPS BEFORE YOU TRY ! IF YOU DON'T HAVE ACCESS TO A PC: KEEP A ROM AND A KERNEL ON YOUR SD-CARD. ALSO MAKE BACKUPS WITH CWM
I assume everyone trying this will know about
the dangers of playing with voltages.
*
[Mhz : sony's standard mV : mV working properly for my Z ]
192 : ---- : 712
384 : 850 : 712
432 : 875 : 712
486 : 875 : 725
540 : 900 : 725
594 : 900 : 725
648 : 925 : 750
702 : 925 : 750
756 : 975 : 750
810 : 975 : 800
864 : 1000 : 800
918 : 1000 : 825
972 : 1025 : 850
1026 : 1025 : 875
1080 : 1075 : 900
1134 : 1075 : 912,5
1188 : 1100 : 912,5
1242 : 1100 : 935
1296 : 1125 : 962,5
1350 : 1125 : 975
1404 : 1137 : 977,5
1458 : 1137 : 987,5
1512 : 1150 : 1025
-Governor-Settings (BE CAREFUL):
As the intellidemand governor got a big update (but almost no descriptions for the new features/settings), here you get my latest settings:
Governor = intellidemand
____
freq_step = 15
enable_boost_cpu = 1
input_event_min_freq = 384000,384000,384000,384000 // #
down_differential = 8 // #
ignore_nice_load = 0
io_is_busy = 1
optimal_freq= 1350000 // #
powersave_bias = 0
sampling_down_factor = 9 // #
sampling_early_factor = 9 // #
sampling_interim_factor = 9 // #
sampling_rate = 50000 // #
smart_each_off = 0
smart_high_slow_up_dur = 5
smart_high_slow_up_freq = 1350000
smart_slow_up_dur = 5
smart_slow_up_freq = 1350000
smart_slow_up_load = 90 // *
smart_up = 0
step_up_early_hispeed = 1242000 // #
step_up_interim_hispeed = 1242000 // #
sync_freq = 810000 // #
two_phase_freq= 384000,0,0,0
ui_sampling_rate = 50000
ui_timeout = 100
up_threshold = 86 // *
up_threshold_any_cpu_load = 90 // *
up_threshold_multi_core = 93 // *
_____
If its laggy for your taste:
1. make sure its no thermal issue or related to the rom itself;
2. Turn these ( // *) down. And these ( // # ) up. But search for their meanings first!
-GPU: undervolting (ONLY IF YOU KNOW WHAT YOU'RE DOING!):
Easiest way I know (until fauxclock/trickster support this feature):
Install "universal init.d", choose any available init.d-script (custom kernels often flash some along the way), add following in it and save:
echo "930000 1000000 1100000" > /sys/devices/system/cpu/cpu0/cpufreq/gpu_mv_table
The numbers (e.g. 930000) are in uVolt for See alnikki25k 's XzKernel-Thread for more info! I highly recommend reading that first!
Becareful: after flashing a new kernel(-version) this added code will likely vanish.
If you know how: just make your own init.d-script, wait for fauxclock/trickster
or just readd it manually again
II.3.2 TIPS I DON'T USE (but you can):
- Thanks @Destroyedbeauty: Instead of using apps like fauxclock/trickster mod you could also just write your own init.d-scripts which would cost nothing and lead to slightly less battery drain (+5 min). I don't use this tip YET, because these apps really don't consume that much. Still a very clever tip!
III. MISC
III.1 Thanks to
People I need to thank for various reasons (in no special order):
@DooMLoRD
@alnikki25k
@gm007
@[NUT]
@Dsteppa
III.2 Translations
I'm very thankful for everyone helping me translate this thread!
(Don't forget: translations can't be always up to date and won't be monitored by me)
-French-Forum (thanks to @monsieur_debile):
http://forum.frandroid.com/topic/16...-plus-de-7-heures-dautonomie-en-écran-allumé/
III.3 Results
-Antutu Benchmark 4: Instead of approximativly 20500 points (standard Z) I currently get approx. 15000. I currently give a damn about benchmarks Will try to improve in the future as promissed
RESULTS WITH REAL USAGE (For those who think I only leave the screen on):
- with my average usage pattern (see beginning of post) in "one sit" I got 7h S-O-T with 10% left battery charge and 9 hours since last charge: See screenshots.
- With my average usage pattern (see beginning of post) on a NORMAL day going to office etc. I got 7:09 h screen-on-time with 6% charge left and 20h since last charge: see screenshots.
- (almost) ONLY reading books, xda, news with gReader, surfing and with a bad phone receiption all day(!) I got 8h screen-on-time with 3% charge left and 12,5 h since last charge.
- Playing Deadtrigger for 0,5h I lost 14% battery life (graphics set to high), so with a full charge I approximativly could get 3,5 h (consider: Deadtrigger isn't optimized very well for non-nvidia-tegra3-hardware so it uses the Z inefficiently and I played with 'high' graphic settings)
If you like what you read: press the thanks-button and rate my thread with 5 stars
One question: Was this done indoors. Like in your room or office, just sitting playing with the device?
And that was a short "stint", I mean 7 hours of screen and 8 hours since the last charge. If you counted idle times, in like a 15 hour stint, screen time would be greatly reduced, plus, if you commute the phone is constantly looking for antennas, thus reducing screen time further.
7 hours is great. But this seems to be on "ideal conditions".
As for my methods of saving battery? 2G all the time. Undervolt. No Underclock. Greenify. Stamina Whatsapp only.
The important question is, what have you been doing ? Did you play games? YouTube? Or did you just let the screen active?
Gesendet von meinem C6603 mit Tapatalk 4 Beta
sea2605 said:
Since xda and its forum helped me alot in many ways, I also want to share something with you, that might solve many users biggest complaint: battery life.
I optimized my battery life so I regularly get 7 hours of battery life (sometimes even more, see screenshot with 10% remaining battery at 7:00h screen on time)... and all that with very normal usage (but no games) and without any sacrifices for me.
Tried many (...!!) methods to optimize but sticked only with those truly making a difference after testing.
________________________________
!!
I'm going to update this thread regularly until I wrote down all details and until I stop optimizing battery life
Lets work together: Tell me your battery life tricks!
Maybe in some weeks/months we can get to 8-9 h of battery life without too large sacrifices
!!
________________________________
HOW I did it (roughly summed up for the moment):
0. Updated to 4.2.2 (no 4.1.2 didn't give me more battery life).
1. Bootloader unlocked (essential, but will void warranty).
2. Rooted
3. Flashed doomkernel v9 via fastboot
4. Installed kernel tuner and underclocked the cpus to 1,24 ghz, changed governor to ondemand,
Undervolted like this (phone is still veeeery fast! No perfomance issues!):
Coming soon
5. Installed titanium backup pro and deleted all sony bloatware/google apps/other apps... All I didn't need or like or which drained too much battery. Here is a list of all deleted apps etc.:
Coming soon
6. Installed elixir2 and deactivated google-ad- and/or google-analytics-entries in all of my apps. Also all features I didn't need in my apps (e.g. I dont want to share everything in.every app with facebook so I deactivated those entries).
I deactivated all voicesearch-entries as I don't like it yet...(Even apples siri isn't great yet in my opinion...maybe in 2-3 years . I also deactivated google now-entries (not google-search!) since it drains a lot and I don't need it.
7.
X. Rather standard things:
- My contract has no LTE so I set the network mode to wcdma/gsm,
-stamina mode on (only whatsapp whitelisted),
- battery save mode on (from 100%; excluding wifi and auto sync),
- wifi-location-based on,
- wifi set to not search for networks,
- wifi set to stay on during standby only when connected (turning off during standby might help some of you, at least those who don't look at/need their phone and need it to be instantly connected),
- Wifi set to save battery
- To be continued
________________________________
I see more potential (but some with sacrifices):
1. With Tasker (thats an app) you could get a little (or quite much) extra battery life (depending on what you are willing to sacrifice...)
2. Future doomkernels could allow for more finetuning of the cpu and gpu (e.g. gpu-underclocking hat sticks; maybe we have some luck and we could undervolt the gpu )
3. elixir2 is hardcore...you could even deactivate EVERY button/activity/service (those which you asume you won't ever need) of all your apps...could save some processing time and therefore battery life
4. Governor wheatley and optimizing it's governor settings would give more juice but it slows all too much down in my opinion...but can lead to +0,5 h!
5. Even further killing some wakelocks with betterbattery
6. Reducing tx of the Wifi-antenna (but reducing tx only helps while downloading, I guess...)
or other antennas...
7. Installing es explorer and deleting fast dormancy app and odex ( both only if your provider doesn't support fast dormancy) in the apps-folder
8. Underclocking min. Frequency to 192 mhz (might help +5-10 minutes but slows phone down a little)
9. Maybe a little further undervolting (+5-10 min, but stability might be a problem...)
10. To be continued
THIS IS NOT READY YET...please wait patiently for more details etc!
Lets work together: Tell me your battery life tricks!
Click to expand...
Click to collapse
I easily get 8+ hours of screen-on time....my tricks for that are as follows,,
1)Root(obvious )
2) download greenify (a must-have by oasis feng)and greenify almost all apps(including games) expect some messaging apps(apps shown with gcm logo in greenify) ,,,and if you want to get that lil extra minutes then go for the donation version of greenify, it lets you greenify some system apps to....also don't kill apps with appkillers(real battery hog)
3) Switching Stamina mode On(especially after the 4.2.2 update)...and carefully selecting only "most needed" apps to be excluded (if you don't want to break notifications)
4)download startup manager..and disable all unwanted apps at startup
5)remove all unwanted bloatware and battery saving apps(they usually do nothing to save your battery,instead they run in background and eatup your battery)
6) no under-clocking, no over-clocking
7) maintain a healthy battery charge history ( don't charge unless battery is less then 20%.,,then charge without interrupting to 100%(don't keep it charging for to long if it reaches 100%,,this will over-charge the battery)
8 ) If you're on 4.2.2 ,,surely you're facing the battery bug,which is really dangerous for the battery (because it bring the battery % down to zero ,without giving you a chance to reach your charger)....So to fix this you'll need to recalibrate your battery by downloading easy battery calibration from playstore (I've calibrated my battery and fixed the bug )...the app will guide you how to calibrate the battery(easy)
9 ) Don't use the "trickle charging" method recommended by some battery saver apps...I've used that method and it shows no improvement in battery life instead it'll drain the battery in a very strange manner ("modern"Li-on batteries should not be trickle charged Google it if you need more info on this subject)
Use this tricks and you'll definitely notice improved juice
More tweaks and tricks for a better battery going to be updated soon(as soon as I'll test and confirm them)...
If you feel that I've helped you in any way,,please hit the thanks button
Sent from my Xperia ZL (C6502) using Tapatalk 4 Beta
Point nr 6 is not true. Best for batery is when working between 50-85%. Battery will not overcharge because phone turn off charging, when battery reaches 100%. You can charge phone even when reaches 90% or 60%. Dont have to wait till 20% (sooner pluged - better for battery).
Sorry for bad english. Regards...
Media Server
Place a ".nomedia" file in directories of your sdcard(s) you don't want scanned so media server doesn't suck all the battery!
Grenify works but not sure about the effectiveness of startup manager. Apps disabled seem to load at startup regardless.
adielee said:
Place a ".nomedia" file in directories of your sdcard(s) you don't want scanned so media server doesn't suck all the battery!
Grenify works but not sure about the effectiveness of startup manager. Apps disabled seem to load at startup regardless.
Click to expand...
Click to collapse
Once you grant root access to startup manager it disables all the apps you've selected not to start at the startup...try it for yourself
If you feel that I've helped you in any way,,please hit the thanks button
Sent from my Xperia ZL (C6502) using Tapatalk 4 Beta
Rumman Shaikh said:
I easily get 8+ hours of screen-on time....my tricks for that are as follows,,
1)Root(obvious )
2) download greenify (a must-have by oasis feng)and greenify almost all apps(including games) expect some messaging apps(apps shown with gcm logo in greenify) also don't kill apps with appkillers..
3)download startup manager..and disable all unwanted apps at startup
4)remove all unwanted bloatware and battery saving apps(they usually do nothing to save your battery,instead they run in background and eatup your battery)
5) no under-clocking, no over-clocking
6) maintain a healthy battery charge history ( don't charge unless battery is less then 20%.,,then charge without interrupting to 100%(don't keep it charging for to long if it reaches 100%,,this will over-charge the battery)
Use this tricks and you'll definitely notice improved juice
Click to expand...
Click to collapse
Sure you get 8 hours screen on time with only that and a normal usage (see my average usage)? If yes: I'm an idiot... why did I even bother with all the other crap
adielee said:
Place a ".nomedia" file in directories of your sdcard(s) you don't want scanned so media server doesn't suck all the battery!
Grenify works but not sure about the effectiveness of startup manager. Apps disabled seem to load at startup regardless.
Click to expand...
Click to collapse
nomedia is a great idea ! Will try it ! :good:
ckyy said:
The important question is, what have you been doing ? Did you play games? YouTube? Or did you just let the screen active?
Gesendet von meinem C6603 mit Tapatalk 4 Beta
Click to expand...
Click to collapse
Updated my first post! See "average usage pattern" on that single day.
DrKrFfXx said:
One question: Was this done indoors. Like in your room or office, just sitting playing with the device?
And that was a short "stint", I mean 7 hours of screen and 8 hours since the last charge. If you counted idle times, in like a 15 hour stint, screen time would be greatly reduced, plus, if you commute the phone is constantly looking for antennas, thus reducing screen time further.
7 hours is great. But this seems to be on "ideal conditions".
As for my methods of saving battery? 2G all the time. Undervolt. No Underclock. Greenify. Stamina Whatsapp only.
Click to expand...
Click to collapse
In some way you could say I tested in ideal conditions as I tested only in "one sit", right (weekend, got bored; but see my
usage pattern...great battery life considering that). But nevertheless:
Roughly we can say, all these methods aggregated will give everyone at least 40-60% more battery life (in relation to their
previous battery life). Thats no exaggeration...UnderVOLTing alone will lead to approx. 15-25% more battery life
...thank @DooMLoRD and his kernel for that!
So someone who only got 4h with his very own usage pattern will now get 6h.
Someone who only played games will get 3 h instead of 2 h...
Someone with a similar usage pattern to mine will get 7 h instead of 4,5 h (my starting point when I bought it)
etc. pp.
EDIT:
even on a normal workday (not "one sit") I get 7+h screen on time and 20 hours since last charge and 6% remaining battery. See my post of 2. August !
I didn't find an option to stop searching for Wifi networks, but I installed an app from google play to automatically turn off wifi when not connected, disbled NFC because I never used it, installed Juice Defender to disable 3G when I don't need it, used greenify on most of my apps, lowered brightness a bit and underclocked and I see some substantial improvement right away.
thanks for sharing your undervolt settings, might try later.
sea2605 said:
Sure you get 8 hours screen on time with only that and a normal usage (see my average usage)? If yes: I'm an idiot... why did I even bother with all the other crap
nomedia is a great idea ! Will try it ! :good:
Updated my first post! See "average usage pattern" on that single day.
In some way you could say I tested in ideal conditions as I tested only in "one sit", right (weekend, got bored; but see my
usage pattern...great battery life considering that). But nevertheless:
Roughly we can say, all these methods aggregated will give everyone at least 40-60% more battery life (in relation to their
previous battery life). Thats no exaggeration...UnderVOLTing alone will lead to approx. 15-25% more battery life
...thank @DooMLoRD and his kernel for that!
So someone who only got 4h with his very own usage pattern will now get 6h.
Someone who only played games will get 3 h instead of 2 h...
Someone with a similar usage pattern to mine will get 7 h instead of 4,5 h (my starting point when I bought it)
etc. pp.
Click to expand...
Click to collapse
Yes,,I'm really getting great screen times(one thing in my favour is that we don't have LTE here in India,& I use a 2g network(since I've a great lan ) so I've disabled wcdma network type & selected only gsm) I even play some graphic intensive games for "sometime" in my normal usage ...see the attached screenshot for details of my usage... Also I would like to add that the switching on the stamina mode is a must(mainly after the 4.2 update) But I'm still trying to squeeze even some extra juice...will update with some more extra tweaks,, after I try them out
If you feel that I've helped you in any way,,please hit the thanks button
Sent from my Xperia ZL (C6502) using Tapatalk 4 Beta
Ill rather use the charger then unlock the bootloader and spend numerous more hours just to get a couple of extra hours screen time as if its a competition lol.
Seriously I can get 6 hours+ screentime with stock 4.22 rom, no root, no bootloader unlocking.
Wifi on, auto sync on, brightness at lowest, stamina on. All I do is read a book from amazon kindle app, lol.
Well, of course no one has to chase maximum battery life... I'm chasing for it out of curiousity... Its only a challenge
But along the way I learn something new about android, smartphone-architecture, linux, ... Might someday be useful (I'm about to study technology of information systems)
Thats all forums/xda/communities exist for: Learning something new and sharing your knowledge
My undervolt goes from
192mhz @ 662mV to 1512mhz @ 975mV on Doom's Kernel.
On FXP Kernel I could go lower. 650mV to 950mV. Although even at those voltages, battery life on CM or AOSP is like 30% lower.
rotkiv3451 said:
I didn't find an option to stop searching for Wifi networks
Click to expand...
Click to collapse
Bump for op. How did you do that?
Turning of that it stops searching for wifi networks.
Now that I arrived home I can write my whole voltage list:
192 mhz @ 662 mV
384 mhz @ 675 mV
432 mhz @ 700 mV
486 mhz @ 700 mV
540 mhz @ 712 mV
594 mhz @ 712 mV
648 mhz @ 737 mV
702 mhz @ 737 mV
756 mhz @ 737 mV
810 mhz @ 787 mV
864 mhz @ 787 mV
918 mhz @ 837 mV
972 mhz @ 837 mV
1026 mhz @ 887 mV
1080 mhz @ 887 mV
1134 mhz @ 912 mV
1188 mhz @ 912 mV
1242 mhz @ 937 mV
1296 mhz @ 937 mV
1350 mhz @ 962 mV
1404 mhz @ 962 mV
1458 mhz @ 975 mV
1512 mhz @ 975 mV
Tested throughout 3-4 weeks. Rock solid stability.
There is a way to know beforehand if your chip can go as low voltages as this:
http://forum.xda-developers.com/showpost.php?p=39373866&postcount=124
First entry is deactivating the intervall-searching for wifis, as far as I can tell
sea2605 said:
First entry is deactivating the intervall-searching for wifis, as far as I can tell
Click to expand...
Click to collapse
I don't think so. As far as I can understand, that option just activates or deactivates the notification for open wifi networks, not the wifi scanning.
Sent from my C6602 using xda app-developers app
mikii100297 said:
Sent from my C6602 using xda app-developers app
Click to expand...
Click to collapse
I'm not a big fan of not charging the phone every day. If I leave home with less than 100% chances are I don't feel confortable.