In my previous thread, I made mistakes in my findings.
http://forum.xda-developers.com/showthread.php?t=1750444
Thank you for your inputs and feedbacks which made me to investigate further.
I used OS Monitor app, to change the governor, and it seem the app changed the cpu governor of 1 core (cpu0) only, where, we need to change both cores (cpu0, cpu1) cpu governor's setting.
Here are my revised procedures.
Code:
$ adb shell 'ls /sys/devices/system/cpu/cpufreq/'
interactive # CPU governor mode
$ adb shell 'cat /sys/devices/system/cpu/online'
0-1 # This means, both cores are currently running.
Now leave the RAZR for 5 minutes... and run these commands
Code:
$ adb shell 'cat /sys/devices/system/cpu/online'
0-1 # This means, both cores are currently running.
$ adb shell 'su -c "cat /sys/devices/system/cpu/cpu[01]/cpufreq/cpuinfo_cur_freq"'
1200000 # current CPU core 0 speed. 1.2GHz
1200000 # current CPU core 1 speed. 1.2GHz
Now we combine both and make a simple monitoring.
Code:
$ adb shell 'su -c "while ((1)); do cat /sys/devices/system/cpu/cpu[01]/cpufreq/cpuinfo_cur_freq /sys/devices/system/cpu/online; sleep 1; done"'
1200000
1200000
0-1
300000
300000
0-1
300000
300000
0-1
300000
300000
0-1
Imagine this, even during idling, BOTH cores are running, and it shoots to 1.2GHz immideately from 300Mhz, IMHO, this is might be onf the causes of the lower battery life.
Now, this command will change the CPU governor to hotplug
Code:
adb shell 'su -c "echo hotplug > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor; echo hotplug > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor"'
Yes, you need to set BOTH cores CPU governor to hotplug.
Now start monitoring, while
Code:
$ adb shell 'su -c "while ((1)); do cat /sys/devices/system/cpu/cpu[01]/cpufreq/cpuinfo_cur_freq /sys/devices/system/cpu/online; sleep 1; done"'
600000
600000
0-1
300000
300000
0-1
600000
0
300000
0
300000
0
300000
0
Conclusions:
Now we can see, the hotplug CPU governor dynamicly enable and disable the second core, and may improves the battery's life. The interactive CPU governer seem to be nice to make thing runs very smooth, but, the downside is, it uses more power.
Thank you and very sorry for the mistakes which may lead to the misinfonrmations in my previous thread.
i always thought adding more cores will improves battery life..
Let's see... NVIDIA's Tegra 3 cpu has 4+1 cores, which the the 5th core is a 500MHz low power core, which is run during standby. In logic, reducing cores, also mean less or no electrical current is going to the disabled cores, and improves the battery life.
The previous Andorid version, which is the GB 2.3.6, Motorola set the CPU governor to mot_hotplug which IMHO, gave a reasonably good battery life.
Now, how about we do some testings, by comparing the average battery life, when using interactive or hotplug CPU governor.
Thank you.
bahathir said:
Now, how about we do some testings, by comparing the average battery life, when using interactive or hotplug CPU governor.
Click to expand...
Click to collapse
I've back-ported some cpu-freq governor modules to Motorola kernel 3.0.8.
I would love to see how this module competes with stock version
List of cpu-freq governor
interactiveX V2 by imoseyon (Lean Kernel for Galaxy Nexus)
hotplugX by imoseyon (Lean Kernel for Galaxy Nexus)
SmartassV2 by Erasmux
Personally, I like the interactiveX. Having best of the both world.
interactive profile + hotplug ability (screen off -> core 1 off)
Thread link [GSM/CDMA][ICS][KERNEL] extra kernel modules
Tq. I'll try it later.
Sent from my XT910 using xda app-developers app
Here are some information after about a day with hotplug CPU governor.
Code:
[email protected]:~$ adb shell 'su -c "cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state"'
300000 1986985
600000 196658
800000 51932
1000000 40389
1200000 348778
[email protected]:~$ adb shell 'su -c "cat /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table"'
From : To
: 300000 600000 800000 1000000 1200000
300000: 0 0 0 0 8768
600000: 3378 0 0 23 1605
800000: 731 1279 0 20 546
1000000: 624 412 732 0 586
1200000: 4035 3315 1844 2310 0
and here is the battery usage information...I deleted /data/system/batterystats.bin first and full charged the battery.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I was using my phone to read/update this forum using XDA app and reading news using Pulse apps during about 1.5 hours commuting. I also listening to podcasts or lectures for about 3-4 hours, which I downloaded using Wifi. Several chattings using gtalk, and several phone calls, on 3G/HSDPA network.
I still have 10%, and seem to be able to get 20 hours of battery life. It was like the GB 2.3.6 with default 'mot_hotplug' CPU governor. Battery life would be much better if I use 2G/GSM network only all the time
Not bad, I may use this setup for a while... before trying other CPU governors.
Note: I like minimalist settings. No live wallpaper, very few widgets. Brightness is at 'Auto'.
Thank you
I noticed that while monitoring the CPU and running Antutu, that the cpufreq hardly ever stayed at 1.2ghz. it dropped to 300M or 600M for most of the test.
I did get a score increase of 703 going from 5606 before switching to hotplug, to 6309 after.
Updates: 2012-07-12
Another day with hotplug CPU governor. This time, I changed the governor's sampling_rate
Code:
$ adb shell 'su -c "cat /sys/devices/system/cpu/cpufreq/hotplug/sampling_rate"'
100000
100000 is a default sampling rate, ie, how quick 'sensitive' the kernel to react and change the CPU frequency.
On my laptop, which runs on conservative CPU governor, the sampling rate is 25000.
I changed the sampling rate to 25000 to my RAZR, and,...I felt a bit jerky, if I scroll the screen SLOWLY, comparted to the original 100000. Next, I tried 50000, and it reduced the jerkiness, at the same time, keep the CPU frequency at the lowest for most for the time. I also changed down_threshold value, to mimic the conservative CPU governor from 35 (default) to 20. Not as smooth as the defualt 100000 sampling rate, but, still usable. Yeah, it is a small sacrifice if you want to conserve energy.
Now, here are all commands that I am using right now.
Code:
adb shell 'su -c "
echo hotplug > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
echo hotplug > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor;
echo 20 > /sys/devices/system/cpu/cpufreq/hotplug/down_threshold;
echo 50000 > /sys/devices/system/cpu/cpufreq/hotplug/sampling_rate
"'
I hope these screenshots can speak itself
My activities whit the RAZR were...
1) Listening to 2 podcasts ...total about 2 hours (Google Listen)
2) Listening 1 lecture . 1.5 hours (Google Play Music)
3) Browse/read news from 8 sites in Pulse :
4) Sevaral gtalks
5) Several short phone calls.
6) Reading this forum using XDA App
Quite good battery life fo a low usage.
Thank you.
Reference:
http://www.kernel.org/doc/Documentation/cpu-freq/user-guide.txt
http://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
Sorry, but why did you lower the down_threshold? This means your CPU stays longer in higher frequencies because the utilization has to drop under 20% to scale down.
dafi87 said:
Sorry, but why did you lower the down_threshold? This means your CPU stays longer in higher frequencies because the utilization has to drop under 20% to scale down.
Click to expand...
Click to collapse
Thank you for your feedback.
You are right. I just copied the value (20) from my laptop which is running on conservative CPU governor.You can always try with other value, while monitoring the cores' frequency. I did few experiments with value of 50. and do some 'real world' usage, such as... playing Angry Birds SPACE.
Based on my observation, not much differences between value of 20 and 50. but, it seem that value 20 able to keep lower speed more gracefully. Most probably this related to the sampling_rate. The cpu frequency changes are done in microseconds..
Need some more tests for this matter.
Thank you.
So this means that hotplug is as efficient as interactive plus saves battery?
Based on ny daily usage, hotplug gives me a small improvement in performances and battery life. YMMV.
Sent from my XT910 using xda app-developers app
for me,
hotplugx >> hotplug > interactive.
R3dbeaver said:
for me,
hotplugx >> hotplug > interactive.
Click to expand...
Click to collapse
hotplugx stutters here and there after a while... way better pegasus or even hotplug
edit
Related
EASY ENGLISH: Differences between this module and the others:
- allows to set max CPU freq when screen is off (to save battery),
- allows to set starting CPU freq when phone awakes (to speed up awake process),
- allows set/change almost all aspects of governor (to suite needs),
- should be a bit more responsive when parameters are well chosen.
Note: Don't use DSP Manager when this governor is enabled (it consumes more CPU then player itself). When screen goes off - sound will be distorted. Use player with equalizer build-in instead.
Governor have some predefinied values - more info in "Available settings".
Start:
The goal was bring 'smartass' governor to work with X8 and also make some improvements.
What Is A CPUFreq Governor?
==============================
Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.
How to decide what frequency within the CPUfreq policy should be used?
That's done using "cpufreq governors". Two are already in this patch
-- they're the already existing "powersave" and "performance" which
set the frequency statically to the lowest or highest frequency,
respectively. At least two more such governors will be ready for
addition in the near future, but likely many more as there are various
different theories and models about dynamic frequency scaling
around. Using such a generic interface as cpufreq offers to scaling
governors, these can be tested extensively, and the best one can be
selected for each specific use.
Click to expand...
Click to collapse
SMARTASS GOVERNOR - is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works - by taking over the idle loop - is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the "old" minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 245Mhz (or if your min frequency is higher than 245 - why?! - it will cap it to your min frequency). Lets take for example the 600/245 kernel, it will sleep at 245. No need for sleep profiles any more!
Click to expand...
Click to collapse
Info:
- information about governors is here,
- more information about 'smartass' governor is here,
- how different governors work is explained here: [Q] SetCPU governors (explained).
Prerequisites:
- X8,
- Baseband x15
- desire to replace SetCPU - when used only for 'ScreenOff' profile.
Manual installation:
- push ax8_smartass.ko to /system/lib/modules
- run the following command
Code:
insmod /system/lib/modules/ax8_smartass.ko
echo "smartass" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Available settings:
Note: there is no need to add following commands without changed value. The values are already implemented in module.
- up_rate_us:
The minimum amount of time to spend at a frequency before we can ramp up.
Default value:
Code:
echo "24000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_rate_us
- down_rate_us:
The minimum amount of time to spend at a frequency before we can ramp down. Default value:
Code:
echo "49000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/down_rate_us
- up_min_freq:
When ramping up frequency with no idle cycles jump to at least this frequency.
Zero disables. Set a very high value to jump to policy max freqeuncy.
Code:
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
- sleep_max_freq:
When sleep_max_freq>0 the frequency when suspended will be capped by this frequency. Also will wake up at max frequency of policy to minimize wakeup issues.
Set sleep_max_freq=0 to disable this behavior.
Default value:
Code:
echo "122880" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_max_freq
- sleep_wakeup_freq:
The frequency to set when waking up from sleep.
When sleep_max_freq=0 this will have no effect.
Default value:
Code:
echo "600000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq
- awake_min_freq: When awake_min_freq>0 the frequency when not suspended will not go below this frequency.
Set awake_min_freq=0 to disable this behavior.
Default value:
Code:
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_min_freq
- sample_rate_jiffies:
Sampling rate, I highly recommend to leave it at 2.
- ramp_up_step:
Freqeuncy delta when ramping up.
zero disables and causes to always jump straight to max frequency.
Default value:
Code:
echo "220000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
- ramp_down_step:
Freqeuncy delta when ramping down.
zero disables and will calculate ramp down according to load heuristic.
Default value:
Code:
echo "160000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
- max_cpu_load:
CPU freq will be increased if measured load > max_cpu_load.
Default value:
Code:
echo "75" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
- min_cpu_load: CPU freq will be decreased if measured load < min_cpu_load.
Default value:
Code:
echo "25" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
- sleep_rate_us: Sleep rate when screen is off
Code:
echo "500000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_rate_us
Release history:
v002:
- sleep_max_freq set to 122880 - more battery saving,
- sleep_wakeup_freq set to 600000 - faster wake up,
- ramp_down_step set to 160000 - to slow down decreasing CPU freq,
- when screen is off - governor acts like its 'conservative' version, just checks CPU loads using 500ms rate,
- added sleep_rate_us parameter - sleep rate when screen is off can be changed using this parameter.
v001:
- just initial version fixed to work with X8.
Sources at: GitHub
Very nice Andy! Apparently we found ourselves a new Module Man
i don't really know what this is all about, its some kind of an AI for cpu governor?
i like the kuyadroid setting(its use native cm setting not setcpu), so its gonna be an setup on cm setting?
Downloading to make some tests
As I can see it is a custom CPU governors, like one "Do it yourself"
Maybe now some people stop complaining about battery life in every ROM. Thx AnDyX
biscoitu said:
Downloading to make some tests
As I can see it is a custom CPU governors, like one "Do it yourself"
Click to expand...
Click to collapse
It is rather - get abandoned project ('erasmux') and refresh it . I tried to resolve one of annoying issue:
12. Using smartass the CPU frequency does go above 352Mhz (with screen off)
Intentional to keep standby battery life under control.
13. Using smartass the CPU frequency is always at its max (or always at 352Mhz when screen is off)
See "Monitoring the CPU frequency" in the "Advanced subjects".
Click to expand...
Click to collapse
I will test it now and I let know how it compares to 'ondemand' tomorrow.
so in plain english(sorry im a noob) this changes the CPU freq scaling behavior? does it improve preformance?
Aashrey99 said:
so in plain english(sorry im a noob) this changes the CPU freq scaling behavior? does it improve preformance?
Click to expand...
Click to collapse
I will add better explanation soon.
Nice module AnDyX I'm gonna check it. Did you have to hijack many calls?
doixanh said:
Nice module AnDyX I'm gonna check it. Did you have to hijack many calls?
Click to expand...
Click to collapse
Only two
But your:
Code:
kallsyms_lookup_name_ax = (void*) OFS_KALLSYMS_LOOKUP_NAME;
is irreplaceable
AndyX...Is this an AI SetCPU??....when we push it to out phone..it will auto config or we config ourself?
lukewong01 said:
AndyX...Is this an AI SetCPU??....when we push it to out phone..it will auto config or we config ourself?
Click to expand...
Click to collapse
Module has predefinied value - I changed info and explained this in main post.
Well this is an instant success!!!!! My stock SE 2.1 is much more responsive now. Menus are smoother and apps start up faster and dont lag much.
I haven't tested it on any custom ROM yet, but i'll do that today. Will report back soon.
Thanks for the awesome module!
AnDyX said:
Module has predefinied value - I changed info and explained this in main post.
Click to expand...
Click to collapse
hmm...i just have 1 question on my mind...i just wanna know we need to customize the value ourself or just push it to our phone and insmod and thats it?
lukewong01 said:
hmm...i just have 1 question on my mind...i just wanna know we need to customize the value ourself or just push it to our phone and insmod and thats it?
Click to expand...
Click to collapse
Just push - module has predefined values as standing in 1st post, after that you can tweak it if you want and share opinion.
khartaras said:
Very nice Andy! Apparently we found ourselves a new Module Man
Click to expand...
Click to collapse
yeah, that's the first thing that came to my mind when i noticed this thread. when doixanh focused on improving his rom, there is a new module-star rising up
thanks, andyx! i haven't tried it yet, but i'll sure test it in a few days. actually, i came up with a simmiliar idea, but i have no programming/scripting/whatever skills (ability to write a "hello world" prog in pascal doesn't count, does it? LOL)
Does this module has conflict with the other modules if i push it or it will work with itself? I mean if this is safe in all ROM without conflicts from racht or dx modules?
i have one question: if i reboot my x8, will i have to insmod it again ??? or can i add these 2 lines in hwconfig ??? thanks for reply
deedii said:
Does this module has conflict with the other modules if i push it or it will work with itself? I mean if this is safe in all ROM without conflicts from racht or dx modules?
Click to expand...
Click to collapse
This module adds completely new functionality, so should work in all ROM-s.
Oh thanks much andyx.x0x0
this thing works well! applications start quickly and everything runs smoothly. Thank you very much for all your modules AnDyX. You're doing really useful and necessary moduls and I'm use all your modules.
Good job!
Im looking for an init.d script to set the cpu gov to performance...i know this can be done using setcpu just wondering how to make a script. I had one on my X2 that would set Gov to performance, looking for one for razr.
This is ont one from the X2, will this work? also will it work for both cores?
Code:
#!/system/bin/sh
echo 1 > /sys/devices/system/cpu/cpu1/online
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 312000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 312000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
It will, but it would suck your battery really, really fast.
And you should set 1200000 as max_freq if you want to use the real CPU's max freq.
kholk said:
It will, but it would suck your battery really, really fast.
And you should set 1200000 as max_freq if you want to use the real CPU's max freq.
Click to expand...
Click to collapse
Ya i wouldn't use those freq values that was just the code copied from X2
mattfox27 said:
Ya i wouldn't use those freq values that was just the code copied from X2
Click to expand...
Click to collapse
download Linpack... run a multi-threaded benchmark in mot_hotplug governor, then switch to performance and run a multi-threaded benchmark. Why do you want to run in performance mode? I think we'll discover that the least amount of cycles on these batteries as possible, will be desired.
tekahuna said:
download Linpack... run a multi-threaded benchmark in mot_hotplug governor, then switch to performance and run a multi-threaded benchmark. Why do you want to run in performance mode? I think we'll discover that the least amount of cycles on these batteries as possible, will be desired.
Click to expand...
Click to collapse
I don't know, im just messing around with phone...
Here are the init.d scripts that I have been using for Siyah. Please note that 95% of the scripts were done by Pikachu's thunderbolt scripts and I have modified then to my liking. Thanks to Pikachu for the hard work he has put in for the developement of our devices. For those that will use these scripts please use them with caution! I am not responsible for any damage done to your phone! You are free to use these as you wish, adjust them to your liking. The s70darkyzipalign, s98cfs, s98systemtweak should be universal for all setups and you do not need to adjust these init.d scripts. The one you need to be aware of is the s98bolt1 and screenstate_scaling script. The s98bolt1 script has cpu freq. steps set at max 1504 min 100. Scaling @ max 1304 min 200. The voltages for these steps are pretty aggressive and may not work for your device so please PLEASE adjust them accordingly. This script will also set ondemand/sio as default. You can replace those as you wish. GPU is set for 40, 133, 267mhz. (Andreilux's settings, Thanks Andrei) Sched_mc and AFTR have been enabled for some extra power saving.
Screenstate_scaling have been modified to set as Ondemand as wake governer and Powersave as sleep governer. You can adjust these as well. The scripts are pretty self explantory and you can adjust these values using root explorer and using the menu in root explorer to "open in text editor". Or you can you wordpad or notepad++ on your pc and adjust them. Save the scripts to your phone. Using root explorer copy the init.d scripts to /etc/init.d. Paste in this directory and set permissions as rwx,rwx,rwx and reboot.
I am sure I missed some things as I'm kind of in a hurry. Please pm me if you have any questions or need help. I have used this setup for quite some time now without any problems. Battery life has been amazing without sacrificing performance. Oh please do not use VC to save boot settings as these will clash. Everything in the init.d scripts will do the same as VC as long as you adjust them accordingly. Good luck and happy flashing/modding!
P.S. After downloading the file remove the .txt extension in the files before using. Thanks!
Here is the link to the Originator and Creator of these awesome scripts. Thanks Pikachu!
http://forum.xda-developers.com/showthread.php?p=18285859
PHP:
I just want to make sure before I utilize these. I need to use a file manager to place these in /etc/unit.d folder without the .txt correct?
Should I remove the existing scripts as well?
Edit: do these scripts completely take the place of voltage control and setcpu? I wanted to get all of my questions out of the way
These seem awesome. Can't wait to try them out
moustro said:
I just want to make sure before I utilize these. I need to use a file manager to place these in /etc/unit.d folder without the .txt correct?
Should I remove the existing scripts as well?
Edit: do these scripts completely take the place of voltage control and setcpu? I wanted to get all of my questions out of the way
Click to expand...
Click to collapse
Everything you posted is correct. Please keep in mind the voltage settings are a little extreme. If you think or know your phone can handle the UV then just drop them in without modifying. But if you're not sure add +25 mv to each step.
I almost gaurantee your phone will sleep like a baby. And fly like the wind when in use.
Thanks for the scripts!
I've also found an interesting script at 9100 Siyah Kernel topic ( http://forum.xda-developers.com/showthread.php?t=1263838&page=1813 )
I got sleep of death by using below script so you may want to check voltages setting before using it.
Code:
#!/system/bin/sh
# ******************
# 1°) I/O Schedulers
# ******************
# Set i/o scheduler (Valid values are: noop, deadline, cfq, bfq, sio, vr, anticipatory)
echo bfq > /sys/block/mmcblk0/queue/scheduler;
# ************************************************
# 2°) Scaling Governor & Smooth Scaling Parameters
# ************************************************
# Set scaling governor, according to available governors in your kernel
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
# Smooth scaling parameters to control any governor jumping to higher frequency directly.
echo 2 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target;
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset;
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step;
# ****************************************************************
# 3°) Deepsleep Levels
# cpulevel = 4 (100Mhz - 800Mhz, default), 5 (100Mhz - 500Mhz)
# buslevel = 0 (400MHz, default), 1 (266MHz), 2 (133MHz)
# ****************************************************************
# Set deep sleep frequency & bus speed:
echo 5 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel;
echo 2 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel;
# ****************************
# 4°) 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 "1350 1275 1150 1050 950 900 850 800" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table;
# Sets global scaling min&max frequencies as 100 and 1000 mhz
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
# ************************************
# 5°) GPU Clock, Voltages & Thresholds
# ************************************
# Set GPU clocks (Valid values are: 100 114 133 160 200 267 300 400 )
echo "40 133 267" > /sys/class/misc/gpu_clock_control/gpu_control;
# Set GPU Up and Down thresholds
echo "90% 25% 90% 45%" > /sys/class/misc/gpu_clock_control/gpu_control;
# Set GPU voltages (Changes possible at +/-50mV ie at 50000 steps)
echo "850000 900000 950000" > /sys/class/misc/gpu_voltage_control/gpu_control;
# ======================================================
# 6°) Hot Plug Thresholds, Sampling Interval & Frequency
# ======================================================
# Set second core kick-in threshold for screen-on state
echo 35 > /sys/module/pm_hotplug/parameters/loadl;
echo 80 > /sys/module/pm_hotplug/parameters/loadh;
# Set second core kick-in threshold for screen-off state
echo 90 > /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 400 > /sys/module/pm_hotplug/parameters/rate;
echo 400 > /sys/module/pm_hotplug/parameters/rate_cpuon;
# Set hot plug sampling intervals for screen-off state
echo 1000 > /sys/module/pm_hotplug/parameters/rate_scroff;
# Set frequency below which second core will not be turned on, regardless of thresholds.
echo 524288 > /sys/module/pm_hotplug/parameters/freq_cpu1on;
# ===================
# 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;
# ====================================
# 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°) Brightness Curve Settings
# =============================
# Brightness settings (Possible values for min_bl = 0 to 255 | min_gamma = 0 to 24 | max_gamma = 0 to 24)
echo 20 > /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;
# =================================
# 10°) Touch Sensitivity Parameters
# =================================
# Set touch sensitivity (Possible values are between 40 to 80. Lower value = higher sensitivity)
echo 40 > /sys/devices/virtual/sec/sec_touchscreen/tsp_threshold;
# ===================
# 11°) Charge Current
# ===================
# Set AC, Misc & USB charge current (Do not set Ac & Misc more than 1000mA or Usb more than 450)
echo "950 950 450" > /sys/devices/virtual/misc/charge_current/charge_current;
# =======================================
# 12°) Switch Hotplug/DualCore/SingleCore
# =======================================
# Set Dynamic hotplug mode
echo on > /sys/devices/virtual/misc/second_core/hotplug_on;
echo on > /sys/devices/virtual/misc/second_core/second_core_on;
# ===================
# 13°) Disable logger
# ===================
if [ ! -d /data/.siyah ];
then
mkdir /data/.siyah;
chmod 777 /data/.siyah;
fi;
touch /data/.siyah/disable-logger;
# ====================
# 14°) Graphic tunings
# ====================
setprop debug.sf.hw 1; # HARDWARE RENDERING (GPU)
setprop video.accelerate.hw 1;
setprop debug.performance.tuning 1;
# Set deep sleep frequency & bus speed:
echo 5 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel;
echo 2 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel;
See the echo 5, change that to 4. And your SOD's will be gone!!
Steve you are the man! Thank you for bundling these scripts all in one place. Everything is smooth and my phone is sleeping like a baby so far.
moustro said:
Steve you are the man! Thank you for bundling these scripts all in one place. Everything is smooth and my phone is sleeping like a baby so far.
Click to expand...
Click to collapse
What ROM are you using?
Can these scripts be used on Unnamed?
Unit.d generator in the i9100 forum works great for this.
Must script manager be used to give these scripts root access to work?
Sent from my i777.
desiromeo719 said:
What ROM are you using?
Can these scripts be used on Unnamed?
Click to expand...
Click to collapse
Miui 2.1.13
I believe these scripts are universal and can run on siyah or entropy dd. Can someone else confirm this?
Sorry guys for the late reply. Busy at work. Yes these scripts are universal for any ROM. Just make sure your kernel supports init.d. Siyah and Entropy both support them.
moustro said:
Miui 2.1.13
I believe these scripts are universal and can run on siyah or entropy dd. Can someone else confirm this?
Click to expand...
Click to collapse
No, some of them depend on tunables in Siyah I haven't ported over yet.
Personally, I would not recommend putting voltage settings in a script that you distribute to the public, as voltages are device-unique.
I'm also a firm believer in a number of small separate scripts with descriptive names, instead of a "megascript" that does it all - harder to analyze and harder to pick and choose.
I'll take a look at the specific script contents when I have some time.
thx for clarifying entropy. i did state specifically about the voltages and they have been modified to my likings. so for now use for siyah kernel. and once again pls adjust the voltages to values that your phone can handle. some phones can only take a -25 mv from stock voltages. s98bolt1 and screenstate should be used as a base only. adjust them to your liking. the other scripts are system tweaks and are universal for most roms.
Sent from my SGH-I777 using xda premium
Thanks for this post Steve. Im sure once I get a handle on these tweaks and applying them I will greatly benefit from them!
No problem. Trying to help out anyway I can. I know all these scripts can be confusing and a headache. I noticed a lot of people asking how to make scripts and OC and UV settings so why not make them avail for the general public. It's just a good base to start off with for siyah users. If anyone has or needs any help in reading the scripts and how to adjust them let me know.
I could ask ya a million questions..but I wont lol. Just trying to do lots of reading here..and on Google to learn about scripts..init.d..OC and UV. Sometimes I think I got it...but then i get all confused. The only script I have now is the V6. That one just seemed like I could handle since it basically walks ya through the entire process. And to be honest..not even sure i notice a difference.
jasvncnt1 said:
I could ask ya a million questions..but I wont lol. Just trying to do lots of reading here..and on Google to learn about scripts..init.d..OC and UV. Sometimes I think I got it...but then i get all confused. The only script I have now is the V6. That one just seemed like I could handle since it basically walks ya through the entire process. And to be honest..not even sure i notice a difference.
Click to expand...
Click to collapse
Trust me, it made a difference. It's nothing flashy, and nothing some people would notice, but it did.
Nice post stevehkim, I may give these are try.
Sent from my SGH-I777 using xda premium
If I may..s70darkyzipalign, s98cfs, s98systemtweak...Are theses kinda like OC and UV or just minor system tweaks? I tried opening them and taking a look...but have no idea what im looking at. I admit, I am not the smartest person thats for sure
They, from their titles, are system tweaks. I haven't looked through them, so I can't tell for sure.
Edit: Steve, you might want to post a brief description of what each script does, which can be run independently, which need to be run together, and most importantly how to implement them.
Just a suggestion to cut back on confusion and potential fights
Sent from my SGH-I777 using xda premium
Ktoonsez presents:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Fluxi XX ICS kernel features
•Must-have for CyanogenMod and AOKP ICS
•Linux kernel 3.0.38
•Samsung open source update 4
•Own toolchain XX. 03, Linaro GCC 4.7.1 with NEON-FPU optimizations for ARM Cortex A9
•Optimized kernel configuration
•Compilertweaks
•ClockworkMod recovery xxTouch 5.5.0.4 complete customized & rebuilt
•xxTweaker app with huge range of functions
•Kernel backlight notification BLN, breathing, LED Fadeout / ** BLN & LED in xxTweaker ** /
•Backlight notification BLN / ** 100% compatible with BLN control ** /
•CPU OC/UV 100 1600MHz / ** per xxTweaker, voltage control, SetCPU or init.d script ** /
•District Governor, and Governor settings / **. CPU/governor in xxTweaker ** /
•OnDemand Governor significantly optimized with screen-off profile and boost at low frequencies.
•CPU hotplugging settings / b. CPU/hotplug in xxTweaker ** /
•Power management utilities / b. General, in xxTweaker ** /
•I/o Scheduler / ** General, in xxTweaker ** /
•Load current settings for AC, Misc and USB / ** General, in xxTweaker ** /
•GPU OC/UV 3step 67 400 MHz, 700 1200mV and threshold values / ** per xxTweaker, voltage control or init.d script ** /
•LCD density settings / b. General, in xxTweaker ** /
•ROM Manager / ** per xxTweaker ** /
•Automated Flash of multiple ZIP files in one pass / ** per xxTweaker ** /
•Screen cursor movement hysteresis / ** by xxTweaker or Tegrak touch move ** /
•Screen touch sensitivity (e.g. with display cover) / ** per xxTweaker ** /
•Volume of quiet to LOUDERER adjustable / ** sound settings in xxTweaker ** /
•Super Amoled + mDNIe, hot, wonderful colors without yellow stitch / ** configurable with xxTweaker ** /
•Screen brightness configurable / ** gamma level in xxTweaker ** /
•Screen color temperature configurable / ** shade in xxTweaker ** /
•.. .and much more
•Sources publicly under (I9100 version) https://github.com/myfluxi/xxICSKernel
•Sources publicly under (My I777 version) https://github.com/ktoonsez/xxICSKernel
Click to expand...
Click to collapse
Download CWM flashable zip kernel
****** IMPORTANT - I removed the xxTweaker from auto installing, use link below to get the newest one.
DO NOT USE THE OTA OPTION IT IS FOR I9100, IT FLASHES THE WHOLE KERNEL NOT JUST THE xxTweaker!!
ICS 7/29/2012
http://www.mediafire.com/?jx7b1b12wz849f0
JELLYBEAN 8/26/2012
WARNING: This kernel has updated WIFI and Bluetooth drivers. If you are going back to stock, you need to get those drivers back or those 2 devices will not work. Simply flashing a kernel will not do it unless it also flashs back those drivers (they are in "/system/lib/modules" folder).
http://www.mediafire.com/download.php?7x9mt83na522m6o
Download xxTweaker APK 0.3.9_rc2
http://www.mediafire.com/?rnhnt8lpfhgl83t
Click to expand...
Click to collapse
Link to original thread:
http://www.android-hilfe.de/kernel-...ernel-ics-xxtweaker-app-xxtouch-recovery.html
Special thanks go to myFluxi for the kernel of course and to bajee11 for the English version of xxTweaker and xator91 for the I9100 thread
Click to expand...
Click to collapse
xxTweaker
Troubles with getting xxTweaker working or showing up as installed
1. Clear data for xxTweaker
2. Uninstall xxtweaker
3. Open Superuser and press menu button, click preferences and update Su binary. EVEN IF IT SAYS YOU ARE UP TO DATE!!!!!!!!!!!!!
4. Go flash the newest kernel again
5. Done
If you are still having issues, do Step #3 again, make sure you don't have a file called "/data/.notweaker" and reboot and that should do it.
Click to expand...
Click to collapse
Some great information is post #2 about governors, schedulers and all that good stuff
Click to expand...
Click to collapse
FAQ's and general Help down in Post #2
Changelog in #3
Help with kernel to isolate issues with WIFI battery drain
http://forum.xda-developers.com/showpost.php?p=25876666&postcount=3
Some helpful information on what all these cool settings are in the xxTweaker:
Especially 6th and 7th posts (first page) are very helpful to understand most of the options. (Thanks to Droidphile for the information and to Bethrezen1453 for finding the link)
http://forum.xda-developers.com/show...php?p=23616564
A bit more info regarding what are the kernel options. (Many thanks to Droidphile for all the information)
Q. "What are these modes: IDLE, LPA and AFTR?"
A. Between screen off and deep sleep states, there are some idle modes supported by cpuidle driver. They are IDLE aka Normal Idle, LPA aka Deep Idle and AFTR aka ARM Off Top Running. Race to idle by CPU is implemented for power management.
In IDLE state, CPU is not clocked anymore, but no hardware is powered down.
In deep idle (LPA),a state after IDLE, again, the cpu is not clocked anymore like we guessed but some parts of hardware are powered down. Deep idle brings in real power savings and there is no need of putting a hard limit to frequency during screen-off; using a screen-off profile. (Good practice is to use a governor with built in screen off profile, than using an user-configured screen-off profile by putting a hard limit on frequency). Deep idle is not used when device is entering deep sleep and also when device is woken from suspend/deep sleep. While entering/exiting DEEP IDLE, CPU is set statically to SLEEP_FREQ and is not clocked below or above until it exits this state.
AFTR is a patch to support Top=Off mode for deep idle. Level 2 cache keeps it data during this mode.
We can have IDLE or AFTR modes with LPA enabled or disabled. (Obviously it is not possible to have IDLE and AFTR together)
Values:
0: IDLE
1: AFTR
2: IDLE+LPA
3: AFTR+LPA
Q. "What idle modes are recommended for power saving? How do i change it"?
A. Recommended for power saving is to enable AFTR and LPA, ie value 3
Example:
echo "3" > /sys/module/cpuidle/parameters/enable_mask
Q. "What is sched_mc?"
A. Linaro team invented sched_mc or Schedule Multi Core to make process scheduling multi-core aware. ie, utilize both cores wisely to save power and balance performance. Even though sched_mc is sort of an alternative to cpu hot plugging, we can use sched_mc with the default hot plug mode.
Possible Values:
0 : No power saving load balance, default in our exynos4210 Soc.
1 : Fill one thread/core/package first for long running threads. In our single-CPU dual-core device, multithreading does not come into picture, so load balancing is almost redundant to hotplugging.
2 : Also bias task wake-ups to semi-idle CPU package for power savings. (Bias new tasks to cpu1 if cpu0 is mostly filled with running tasks). This is 'overloading' CPU0 first.
Q. "What value is recommended for sched_mc?"
A. 1) If you find advantages to sched_mc, use sched_mc=1 for a possible battery saving. Anyhow since load-balancing is reduntant on hotplugging, it may not have any advantage on exynos chip.
2) For performance use 2. But do remember that loading CPU0 and leaving CPU1 can not do justice to hitting deep idle states sooner since second core can not enter deep idle. So extra performance or no performance, value 2 will drain some more battery, in the context of delayed didle.
3) To do justice to hotplugging, use value 0.
Example:
echo "0" /sys/devices/system/cpu/sched_mc_power_savings.
Schedulers that i recommend to use. Again massive thanks to Droidphile for the information.
Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
Governors that i recommend to use. Information again by Droidphile.
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
Do not forget to enable the Lionheart tweaks you must have Conservative governor enabled through the configurator application and then select Lionheart tweaks
Links
*Droidphile thread regarding more info about governors and schedulers and more tweaks
http://forum.xda-developers.com/showthread.php?t=1369817
*Ext4 Optimization information
http://kernelnewbies.org/Ext4
*If you want to try alternative settings from mine and try settings near stock default go to the following thread by Geko95gek and check his great thread out.
http://forum.xda-developers.com/showthread.php?t=1466017"
7/29/2012 Changelog:
•Updated BFQ
•Updated Pegasusq
•Change packet filter settings to block multicast
•Etc.......
7/17/2012 Changelog:
•Linux 3.0.37
•Just some many to list so here is the short of it
•USB
•vhost
•mm
•raid
•PCI: EHCI
•eCryptfs
•ACPI
•etc................
Previous Changelog:
•USB driver from N7000
•Increased pipeline for USB
•Fix file permissions and cleanup of mali
•Increased USB Buffer count
•Correct intermediate freq step and conditional for cpufreq
Previous Changelog:
•Another few tweeks to logging
•Several Recovery updates
•File permissions for vibrator pwm value in Initramfs
Great auto brighness settings (custom backlight settings) from codeworx:
***** Make sure your Exynos Sensor is set to "Open Source" in xxTweaker General section *****
*****WARNING: If you apply the setting before adding ALL the values, you'll have to do a full wipe. *****
CWM Flashable (This sets all the custom backlight values from below in one zip. You will have to flash this everytime you do a Wipe Data/Factory Reset)
REMEMBER THAT THIS WILL NOT WORK IF YOU HAVE JUST WIPED ALL DATA AND THEN TRY TO FLASH THIS IN THE SAME RECOVERY SESSION, YOU NEED 1 REBOOT TO MAKE THIS WORK.
http://www.mediafire.com/?3dwevbpdh0p9j6z
Code:
0 12
6 18
9 26
14 30
20 34
30 39
46 45
68 51
103 59
154 67
231 77
346 88
519 101
778 116
1168 133
1752 152
2627 174
3941 199
5912 228
8867 250
nice!!!! you might need a little work on your dates, but i still except you bro.
task650 said:
nice!!!! you might need a little work on your dates, but i still except you bro.
Click to expand...
Click to collapse
LOL, copy pasted from original, fixing right now
Flashing now
This looks interesting. Might have to give it a try
Sent from my SGH-I777 using Tapatalk 2
task650 said:
nice!!!! you might need a little work on your dates, but i still except you bro.
Click to expand...
Click to collapse
Might need a little work on your grammar
Jp u know i love u
Red5 <3
Dang Ktoons!!!! At this rate we'll never get these kernals set in after a few battery cycles to see which is best!
Great job getting these kernals to us... you and task make this phone awesome!
Sent from my SGH-I777 using xda premium
Why u not has download link?!!
Red5 <3
dirtbikerr450 said:
Flashing now
Click to expand...
Click to collapse
Not sure what you are flashing man, I havent put up the link yet.
Colonel is at it again!
Sent from the Nodes of Ranvier
To keep guys entertained look at how this retard parked at my work today
Red5 <3
OP Updated:
Download CWM flashable zip
http://www.mediafire.com/?7888m7e9e7ysm86
Click to expand...
Click to collapse
ktoonsez said:
Not sure what you are flashing man, I havent put up the link yet.
Click to expand...
Click to collapse
I was just gonna say that! Thought there was something I wasn't seeing lol
Sent from the Nodes of Ranvier
U forgot xxtweaker lol
Red5 <3
Found it
http://forum.xda-developers.com/attachment.php?attachmentid=1060018&d=1336987618
Red5 <3
JordanElliott said:
Found it
http://forum.xda-developers.com/attachment.php?attachmentid=1060018&d=1336987618
Red5 <3
Click to expand...
Click to collapse
Just saw that, it didnt take my link but OP is fixed and here it is again:
http://forum.xda-developers.com/attachment.php?attachmentid=1060018&d=1336987618
Sweet something new to try out.
transmitted from the Dark Obelisk
Now your just showing off.
There are so many questions asked over and over again about how to configure the kernel for a desired outcome..... max performance, best battery holdup, fix freezing etc.
I will post this for those who did not attend school just for the bus ride or playtime. All dumb questions ignored so if I don't respond, you asked a dumb question or made a dumb comment.
We have a choice of 1 custom kernel (Eureka) that can be comprehensively tweaked thanks to many of the settings being moved into the DTB partition. Currently, there are 20 versions of the DTB image that can be selected on kernel installation - 10 enforcing and 10 permissive with 10 different mixes of cpu and gpu frequencies to suit most needs. The default sets everything to maximum and is the cause of the majority of freezing / crashing on an A205 phone that has a lower quality SoC than the other A series compatible phones. Most will end up using DTB2 to fix instability but even this might not be enough. You then have to consider a lower frequency DTB which lessens the attractiveness of using this custom kernel. Why not make your own flavor of DTB that can more accurately reflect what you can run on your specific SoC? Here's how:
Open up the Eureka Kenel zip file in whatever zip extractor you use.
Extract DTB2.img from the zip file (either permissive or enforcing version depending on what your chosen ROM needs)
Now open DTB2.img using a hex editor
Now look at the following which is a list of addresses (in hex), what the value at this address is defining and a list of possible settings. Frequencies are in MHz and the hex code to set it is the frequency in kHz example: 343MHz is 343000kHz, 053BD8 is hex for 343000.
GPU:
5CA5 GPU max freq
5CB5 GPU boost freq
5CC7 GPU boost %load
Possible freqs (MHz):
343 053BD8
450 06DDD0
545 0850E8
676 0A50A0
845 0CE4C8
1001 0F4628
1100 10C8E0
1200 124F80
1300 13D620
CPU smalls:
71B1 CPU min freq
71C1 CPU min freq
71D1 CPU max freq
71E1 CPU max freq
71F1 CPU boost freq
Possible freqs (MHz):
208 032C80
343 053BD8
449 06D9E8
546 0854D0
676 0A50A0
757 0B8D08
839 0CCD58
902 0DC370
1014 0F78F0
1144 1174C0
1248 130B00
1352 14A140
1482 169D10
1586 183350
1690 19C990
1794 1B5030
CPU bigs:
73B9 CPU min freq
73C9 CPU min freq
73D9 CPU max freq
73E9 CPU max freq
73F9 CPU boost freq
Possible freqs (MHz):
208 032C80
312 04C2C0
520 07EF40
728 0B1BC0
936 0E4840
1144 1174C0
1352 14A140
1560 17CDC0
1664 196400
1768 1AFA40
1872 1C9080
1976 1E26C0
2080 1FBD00
2184 215340
2288 22E980
First thing: The default min freq of 208MHz does not save any more battery than setting this to 343MHz (for small cpus) and 312MHz for bigs.
Next thing: The A205 more than likely will become unstable at anything above 2080MHz for the big cpus but can probably cope with 1794MHz on the small cpus. Each SoC is slightly different so you must test what your phone can handle, not what someone else's phone can do!
Next: It is highly unlikely that your A205 will be stable with the GPU maxxing out at 1300MHz. You will not be aware of this until the gpu governor actually cranks the gpu up to that frequency i.e. you can remain oblivious to it for some time and incorrectly assume something else is causing freezes / crashes / glitching.
Next: There are many more settings in the DTB relating to boost frequencies on various input conditions i.e. screen touches, keyboard clicks, mouse clicks etc. Most of these are set to peak at 1144MHz which seems quite reasonable so I have not sought to specifically identify and edit these.
Edit: So here are the input boost frequencies: (address, name, function, freqs)
I assume the first addresses in each block are for BIGS and the 2nd lot are for SMALLS. It seems to work well to set all the BIG freqs to 936 and all the SMALLS to 839 since there is an abundance of upward boosting from other sources such as the Governor and Exynos specific drivers.
50B1 key1 IKEY 1144
5181 key2 ITOUCHKEY 1144
5255 5259 525D 5285 5289 528D key3 ITOUCH 1144 1144 936 839 839 839
5369 536D 5391 5395key4 IMULTITOUCH 1144 936 839 839
545D 5461 5485 5489 key5 IKEYBOARD 1144 936 839 839
554D 5551 5575 5579 key6 IMOUSE 1144 936 839 839
5641 5669 key7 IMOUSE WHEEL 1144 839
5735 5739 575D 5761 key8 IPEN HOVER 1144 936 839 839
5821 5825 5849 584D key9 IPEN 1560 936 839 839
58E5 key10 IKEY_TWO 1872
Recommendations:
Min Freqs:
Set GPU to 343MHz, small CPUs to 343MHz and big CPUs to 312MHz. This is the maximum power saving you will get and offer minimal lag as the frequencies scale up to meet demand.
Set the GPU max freq to 845MHz while you are establishing what is stable for the CPUs.
Set GPU boost to 545 or 676MHz (depending on your compromise between battery and performance)
Set GPU boost load trigger level from the stock 75% down to 50~60%. Again depending on your compromise between battery and performance. Lowering this setting has a significant impact on reducing perceived lag so the stock setting was probably far to high.
Set big CPU max freq down to 2080MHz. This solves most crashing that is due to the cpu being overclocked too far.
Set small CPU max freq to 1794MHz unless your SoC proves to be unstable at this.
Set the CPU boost freqs to something quite low (around 700~900MHz). There are other boosts that override this basic CPU boost freq so you will almost never see it.
Note: If you want maximum battery savings, setting the max freqs lower seems like a logical thing to do but it is not! If you halve the cpu freqs, you double the amount of time they must remain on but you do not halve the power consumption so you end up consuming more power....
Make the changes and save the DTB.img file and flash it in recovery to DTB partition and reboot.
Install hKtweaks_v2.2.2 or your favorite kernel tweaker that can deal with Exynos SoCs (not many can)
Take a look at the cpu and gpu settings to confirm that your edited DTB file is producing the expected results i.e. min and max freqs agree with what you set.
You are done!
Err..... only kidding there is more to do.
Now back to the issue of the GPU max freq. In hKtweaks you can override the settings inherited from the DTB (within the limits set by the DTB). The max GPU freq is also associated with a core voltage. Lowering the voltages will make the GPU run cooler (use less power) but also it will not overclock as far as if the voltage is higher. Here is the dangerous bit - you can increase the voltage to make it overclock higher but cause it to overheat quicker which will make it throttle back to a lower freq. There is also an error in the DTB: Look at the settings for throttling the frequency back at certain temps. Set GPU LEVEL 3 Throttling Freq to 343MHz to fix the error.
Have a play with the GPU settings in hKtweaks without setting Apply on boot so if you set something that crashes the phone, it will revert to normal on a reboot. When you are positive you have the best GPU settings. then set Apply on boot.
Now you are done!
Err..... not quite, there is more.
O.K, assuming you have your custom DTB set up exactly how you want it, it is time to look at some important settings available through hKTweaks.
Firstly we will look at the CPU Governor selection. Interactive is the stock setting and if you watch what the CPU cores are doing with no background activities (kill all unnecessary apps), you will see the frequencies will be dancing around without settling down to the minimum freqs. This is partly due to a dodgy implementation of this governor by Samsung and also the excessive amount of invisible running services that allow Samsung and Google to plunder your personal data in realtime.
Touch the screen, scoll the screen etc. and you will see the various CPU boost features adding to the overall freqs.
The Eureka kernel has extra CPU Governors added - not all function correctly... be warned. Some Governors apply to all CPUs (big and small) and can't be configured separately. Some Governors can have separate configurations for big and smalls.
The way this works is whatever is set for cpu0 is applied to all smalls (cpu0~5) and whatever is set for cpu6 is set for all bigs (cpu6~7).
In a root filemanager, take a look at /sys/devices/system/cpu/cpufreq If you see a folder with the Governor's name, the Governor is applied to all cpus big and small with the same settings. If the Governor does not have a folder here, look in policy0 and policy6 folders. If the Governor has folders in there, the Governor can have separate settings for big and smalls. This is determined by however the Governor was set up at the kernel level.
I can't tell you what Governor is best for your usage patterns - I have already warned you that some are borked so all you can do is try them all while watching their behavior. until you find one that works for you.
Let's use Smartmax as an example. It is not aware of bigs and smalls so any settings are applied to all cpus. If you set this Governor for both big and small cpus, changing the settings in big will change the settings in small as well. The default settings will automatically pick up on the settings you made in your DTB. The remaining settings are not bad as they are but can be improved on.
Try it out, set Smatmax as the governor both both big and small and observe the cpu freqs on idle and when touching / wiggling the screen. You should see it scale up rapidly and scale down to min freqs much better than Interactive was doing. Have a play with other settings if you want - I tend to speed up the ramp down rate and increase the ramp down step to make the cpus return to min freq quicker (for battery saving). Once you have experimented with Smartmax, have a play with the remaining Governors to see if there is anything you like. Something I learnt from a previous phone with a MTK octa core SoC is that there is no power penalty for readily scaling the cpus up to a (sensible) maximum freq. This gives the phone a fast, lag free feel that everyone wants and the cpu will complete its tasks faster so it can return to idle faster. A foolish overclock freq will burn more power - usually when the core voltage is cranked up stupidly high to get the overclock - bad for phone, bad for battery! A bad Governor setup will chew battery if it doesn't pull the frequencies back to idle at low loads but view this in light of the amount of background services you are running. MyAndroidTools is an excellent app to view and take control of pesky services.
The GPU also has a choice of Governors but I recommend sticking with the default Interactive. You get to choose the GPU Highspeed freq and load and both of these settings can be embedded in your DTB. Play with the freq / voltage tables at your own risk!
More to come....
Latest additions:
HMP Settings:
689C 0000020C up threshold
68AC 000000D6 down threshold
68BC 000000FE semiboost_up_threshold
68CC 000000A3 semiboost_down_threshold
68DC 02625A00 bootboost-duration us
68EC 0000001E down_compensation_timeout mS
68FC 0016E360 down_compensation_high_freq uS
690C 000F4240 down_compensation_mid_freq uS
691C 000C3500 down_compensation_low_freq uS
A final note:
If you want to know which CPU, GPU governors are best and what the difference is between them, there is loads of information already gathered on this topic. Most of it is quite dated but still relevant. Here is a good starting point:
[REF][GUIDE]Saber's guide on CPU governors, I/O schedulers and more!
Collective guide of CPU governors, I/O schedulers and other kernel variables I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel...
forum.xda-developers.com
There is a lot of misunderstanding on Eureka Kernel and ROM forums around the issue of memory management - LMK, Virtual Memory etc. Many users want something for nothing like running every known Samsung, Google and Social Media app in the background on a A12.1 or 13 ROM on a phone with 3GB RAM.
The basics of virtual memory have not changed - set ZRAM to no more than 50% of the available memory and set ZSWAP Memory pool to no more than 30%. Swappiness is best at 100% and vfs_cache_pressure set to 50. These settings are the favorite targets for abuse in tweaks offered by people of little knowledge.
Once you have your virtual memory sorted and have made smart decisions on what services/apps you are going to allow to self start on boot and hide in the background, it is a simple case of looking at the free memory to figure out how many more apps can run before killing occurs. It should surprise no-one when it occurs..... blame yourself, not the kernel, not the ROM, but your decisions on what you run and how you configure the phone.......