Related
So many people on these forums ask about the best CPU tuner profiles to set on their Desire Z that I thought i'll make a thread here to refer to.
Note: I've been using and experimenting with CPU tuner for 5 months now, and i faced all the known issues before i came to these settings. Also, I have been listening to everyone's remarks. So i think it works the best. Now don't blame me if your phone turns into a fireball after you applied these settings (well, it's rare though...).
If you don't have it, you can download "cpu tuner" from the market. I'm using the 2.1.2 version.
Tips first:
You need a ROOTED phone to operate CPU tuner properly.
You'd better get a good kernel which allows a wide frequency range and the basic governors.
Read the help that's included with the program (Menu -> Help).
Unless you really need it, do not run the Check System Capabilities.
Not all phones can handle high CPU speed, just experiment. It's mostly a matter of luck.
The purpose of CPU tuner is to allow you to save battery life while getting the best of your phone when you need it. It allows you to change two important things in your phone, defined in "profiles":
Governor: the "brain" that decides when to lower or raise frequency, depending on what you do
Frequencies: the min/max frequencies the governor can choose between.
These profiles are applied depending on your battery status. Battery remaining life is the variable for "triggers", which fire the profile changes.
Usually, you want your phone to give you the best of its power, as long as possible, so i defined only two triggers: one for "Battery is fine, thanks" and one for "Battery is at agony, stop it now!" (below 20%).
Here we go:
Before you start, go to settings, and turn profiles off.
Virtual governors
In the virtual governors tab, we define the 3 ones we need:
VG: Screen Off: "interactive" governor
VG: Normal: "ondemand" governor, with threshold up at 95
VG: Powersave: "conservative" governor with thresholds up at 97 and down at 90
Profiles
Now, let's set 3 profiles for the different cases:
Screen off: Governor "VG: Screen Off", frequencies 691-806Mhz
Normal: Governor "VG: Normal", frequencies 806-1210Mhz
Powersave: Governor "VG: Powersave", frequencies 599-806Mhz
In all cases, let all services on "unchanged" unless you want some specific behavior.
Triggers
Ok, now that we have everything we need, let's say what to trigger, and when:
Let 2 triggers:
1.Battery Good
Level: 100
On Battery: Normal
Screen Locked: Screen off
On Power: Normal
(optional but advised) Call in progress: Normal
(optional) Battery hot: Powersave
2.Battery Low
Level: 20
On Battery: Powersave
Screen Locked: Screen off
On Power: Normal
(optional but advised) Call in progress: Normal (this is important for call stability)
(optional) Battery hot: Powersave
You're ready to go now! But we can check some options if you'd like to:
User interface:
Be sure not to enable the Calculate power usage.
Also, here you can remove the (annoying) notifications, just let the status bar icon.
Profiles and triggers
Remember this optional "Call in progress" option? Here you cna enable it.
Service Switches
It's a good idea to check the "Manual service change" box, not to be bothered when you manually turn some connection on and it goes because you run low on battery.
Buy me a beer
Honestly, you can buy him two ones...
And to thank me, just click on the "Thank" button on this forum
When you're done, turn profiles on again.
Tell me how you do with these settings!
hi. i have a desire z running virtuous 1.0.2 with advanced kernel 2.2.0.
i follow you settings and after 2 days of use i've got the screen wake up issue on incoming call.
there's something i missed?
Are you using the Call in progress settingon every trigger ?
yes, i've set both to the normal profile as in your guide.
now i've disabled the option in settings and hope that works...
Yeah, try without this setting.
If you keep having the issue, try to raise the min frequency of screenoff.
ok! now i've found a good config!
i've increased screen off min freq to 691 and enabled again the call in progress option.
if the call in progress option is disable, the phone locks during a call and the proximity sensor won't work anymore (for example if you wish to end a call).
i hope this will help some other users!
thank you for help and guide!
Please give again a feedback in some days, and then i'll add your findings in the 1st post.
Thanks
after 3 days of usage i can say that this is the right config.
no more wake up / in call locking / end call wake issues!
Alright and you're using interactive for screenoff, right? I'll edit my first post
You guys minimum frequencies look a bit too high, I have mine set to 245 minimum and it gets me much better battery life. I would also suggest using SetCpu (it's free for registered xda members). Just a thought though.
Edit: CPUTuner can also cause issues with any rom that isn't CM7; and also on CM7 under the right circumstances.
Sent from my HTC Vision using XDA App
@Ninj: yes, that's right!
@PaganAng3l: any suggestion is welcome! why don't you post an example of your settings?
Great little write up. I look forward to setting it up after work!
My profiles in SetCPU are pretty basic, but I get great preformance and around 30 hours of battery with moderate/heavy usage. Here are my profiles:
Temp > 42.0 C = 806 max / 245 min
Governor = Conservative Priority = 95
Charging = 1209 max / 245 min
Governor = On Demand Priority = 90
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
Battery < 50% = 1017 max / 245 min
Governor = On Demand Priority = 80
Battery < 101% = 1209 max / 245 min
Governor = On Demand Priority = 75
That's it! I don't personally experience "wake lag" or a blank screen with incoming calls with these settings, but if you do simply bump up your minimum frequencies to above 300 mhz.
Sent from my HTC Vision using XDA App
PaganAng3l said:
[...]
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
[...]
Click to expand...
Click to collapse
powersave? i can't find that governor...
i've set it on conservative.
i'm trying your settings but i still have the wake up issue.
now i'm going create a screen off profile.
if even this won't help, i'll try to increase the minimum freq to 300mhz.
however i have to say that this setup really help to increase battery life.
after 2 day of moderate usage i'm still at 66%!!
eFFeRaTuM said:
powersave? i can't find that governor...
i've set it on conservative.
i'm trying your settings but i still have the wake up issue.
now i'm going create a screen off profile.
if even this won't help, i'll try to increase the minimum freq to 300mhz.
however i have to say that this setup really help to increase battery life.
after 2 day of moderate usage i'm still at 66%!!
Click to expand...
Click to collapse
Your kernel may not support a "powersave" governor. I just flashed pershoot's kernel and I no longer have it. Try bringing all of your max frequencies to 1171mhz or lower. This helps solve the waking issue too.
Edit: having a screen off profile caused me no end of trouble. It may not be an issue for you but I thought I would share.
Sent from my shiny metal G2 w/ meXdroid V2
PaganAng3l said:
My profiles in SetCPU are pretty basic, but I get great preformance and around 30 hours of battery with moderate/heavy usage. Here are my profiles:
Temp > 42.0 C = 806 max / 245 min
Governor = Conservative Priority = 95
Charging = 1209 max / 245 min
Governor = On Demand Priority = 90
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
Battery < 50% = 1017 max / 245 min
Governor = On Demand Priority = 80
Battery < 101% = 1209 max / 245 min
Governor = On Demand Priority = 75
That's it! I don't personally experience "wake lag" or a blank screen with incoming calls with these settings, but if you do simply bump up your minimum frequencies to above 300 mhz.
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Going to give this a try. Hope I see an increase in battery life.
Why not just get the pyromod kernal and watch it do its magic?? but cool find
Sent from my HTC G2 PyroMod 2.0
Is it normal for CPU Tuner to give a "has been granted Superuser permission" message everytime the phone comes back from standby?
Sent from my T-Mobile G2 using XDA App
jankypr said:
Is it normal for CPU Tuner to give a "has been granted Superuser permission" message everytime the phone comes back from standby?
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
Yes that is normal. However since you're an xda member you can get the app SetCPU for free and I believe it's superior to cpu tuner. Just search the forum for "setcpu download" and it should turn up.
Sent from my shiny G2 w/ meXdroid V3
[EDIT: Feel free to jump to comment #9]
[EDIT2: last version of the patch to apply to the kernel is in comment #25, applying the patch to the kernel source is all you need to test]
[EDIT3: changed name to deep cpuidle, I figured "deep sleep" is usually meant as "suspend-to-ram" and this has nothing to do with suspend, suspend is entered at fixed SLEEP_FREQ and the cpu frequency is irrelevant during suspend because CPU power is cut-off]
On my galaxy S I've been monitoring my cpufreq stats and the stats/total_trans keeps increasing every second or so with default cpufreq values and ondemand governor, when the screen is off and the cellphone is idle. This means the cpu spends some time spent at the high frequency even if the cellphone is idle and screen off.
I noticed if I increase the ondemand/sampling_rate from the default 40000 (on i9000) to 80000 the total_trans go down to one every 10 or 20 sec. But I want to decrease the sampling_rate to 20000 so it takes only 20msec to jump to 1ghz. 40msec (the default) is too much. 40msec means 25hz but the first image frame would get lost because it'd be rendered at 100mhz instead of 1ghz. at 20msec of sampling_rate the frequency is 50hz so if the first frame is lost we're still down to 25hz which is less noticeable to the eye. I think 20000 is the max that sampling_rate should be set for decent responsiveness.
However if I drop the sampling_rate to 20000 as I prefer, when the screen is off the stats/total_trans increases even faster at a couple per second, than with the default of 40000, so sampling_rate 20000 is ideal for responsiveness but it will waste power when the screen is off.
So my solution is to force the max frequency allowed by the cpu policy to the min frequency when the screen is off. After that I can easily set sampling_rate to 20000 and io_is_busy to 1, by adding this the init.rc of the initramfs. I prefer io_is_busy to be 1, because 100mhz is really slow and the I/O will take some significant percentage of CPU too if set at 100mhz, and especially because after the I/O is complete I'll avoid losing one frame.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate 20000
I'm also testing with up_threshold 80 but I'm not sure if it is better or worse... need to do more tests on the below one, could be a bad idea.
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
This way I can tune the ondemand as aggressive as I need without sacrificing the powersaving when the screen is off. In fact it should use less power now when the screen is off than before.
The patch is for the ginger update2 kernel, running 2.3.4 XXJVR using the kernel modules of XXJVS (I rolled back the userland and initramfs to JVR because JVS disconnects wifi for me).
I've noticed there's a smartass2 governor which I didn't try, it may work better than this, but I tend to trust the ondemand governor to be the best for responsiveness, and my approach is much simpler than the smartass2 governor, I'm not in a mood of doing beta testing or risking instability for a feature that can be achieved so simply. If ondemand isn't aggressive enough I prefer ondemand to be improved to be more aggressive. Ondemand is what runs on most laptops/workstations so we can't afford it not to be as fast as it can.... The problem is not specific to cellphones. And when screen is off there is not point to ever increase the frequency over 100mhz on i9000 (and unfortunately it happens and it's not fair to pretend some background service to call usleep(1) just to avoid the frequency jump).
Note, you may want to remove the two printk from the patch, they shouldn't flood but they're only for debug...
I think you need to put a [MOD] in your title.
First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?
Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk
cnn888 said:
Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
Well I'm running the JVS kernel on top of JVR userland+initramfs. It'll run perfectly on JVS but I only posted the source and it'll work for both
I'm also a bit annoyed often I see mods and tweaks and I try to search the source and it's not so easy to find it. I'd recommend people to post more source and less binaries.
You just need to ask one kernel builder that ships with the ondemand governor to apply my patch, add those 3 lines to the initramfs/init.rc file and rebuild and it'll work for JVS too. Theoretically it will drain less when the screen is off and it'll be a bit more responsive when screen is on.
---------- Post added at 07:42 PM ---------- Previous post was at 07:36 PM ----------
Rootax said:
First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?
Click to expand...
Click to collapse
The whole point of this approach is not having to change governor and to share the ondemand governor which must provide max performance and max responsiveness on laptop and desktops so I don't see the point of creating a new governor when the screen is on, considering the requirements are the same.
I thought lowering voltage was considered risky, I don't want to change voltage but if you want to change the voltage I think the best place to do it is still my two handlers I added in the patch, no new governor required, I doubt you want to change voltage when the screen is on, and when the screen is off I guess you want always the lowest voltage and lowest freq like me.
A new governor is not needed in short, just a few liner patch to set the max freq at the lowest when screen is off is my preference, especially because it's so much simpler
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values
zacharias.maladroit said:
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values
Click to expand...
Click to collapse
Thanks.
I figured with csipsimple with the proximity sensor, 100mhz are not enough.... so I'm now decreasing the max frequency to 800mhz when screen is off, and I'm keeping the default sampling_rate to 10000 msec (setting transition_latency to 10000, equivalent to writing 10000 into ondemand/sampling_rate).
I also changed the code a bit to call all notifiers when the max frequency changes from 1ghz to 800mhz.
Now I did quite a bit more tests and something's going wrong when screen goes off in cpufreq. The cpu is idle, but ondemand raises the frequency more than if the screen is on. That is probably why the cpu isn't very idle when the sampling_rate is reduced go give more responsiveness. If I change get_cpu_idle_time_us to return -1 unconditionally, the trans_total are greatly reduced with screen is off and the ondemand stays at the low frequency when screen is off with sampling_rate 10000 too.
I also tried to measure the cost of a frequency switch (including the overhead caused by ondemand sampling at 1khz) and it seems of the order of 38usec.
I'm wondering if there's some bug in the get_cpu_idle_time_us that is causing the jitters in the ondemand governor when screen goes off.
I found the problem with the ondemand governor while in earlysuspend suspend mode. The problem is that the cpu starts to go in deep sleep, so a sampling_rate of 10000 is applied only once in a while, the real sampling_rate becomes 1second or more.
So when that happens the CPU goes in deel sleep all the time and ondemand tends to stay stuck at the max frequency all the time, by mistake, despite the load is near 0%.
After deep sleep when a wakeup happens we return to the 10000usec sampling rate. ondemand sees activity after the deep sleep wakeup but those wakeups "loads" must be adjusted down if the previous wall_time delta was huge and the current one is tiny. We're too close to deep sleep to ramp up cpu freq.
So my solution is to tweak the ondemand to scale down the "load" according to the decrease in the wall_time delta ratio (deep_sleep_ratio variable).
When screen is on, or during a call or during playback with screen off, the deep_sleep_ratio is 1, so the ondemand behaves as aggressive as always. But the deep_sleep_ratio ramp up when the phone is idle and the idle deep sleep states starts. With this tweak I can use the ondemand governor with the default values and the sampling rate set to 10000 (for max responsiveness) and the cpu freq will stay down to 100mhz with no jitter when the screen is off and the load is near 0% (instead of staying close to 1ghz most of the time with the 10000 sampling rate setting, 40000 of the JVS tends to hide it but it still jitters a lot and it hurts interactivity to be unable to set it below 40000).
In my first post I already noticed this jittering of the ondemand governor with the screen off. And I thought to solve it by lowering the freq to min with the screen off (which screwed csipsimple). I also noticed that a sampling_rate of the order of 100000 would decrease the jittering and with 10000 the cpu freq would be set at the maximum all the time. But the real problem was the ondemand comparing apples to oranges with the deep sleep state, and this explains why the jittering wasn't as bad with the screen on, as opposed to the badness with the screen off and the CPU going in deep sleep at high freq most of the time.
So this heuristic I wrote solves the problem, and I also disabled all those dvfs magics in cpufreq that prevented to use the 100hz frequency most of the time. It works fine for me with screen on, and now with screen off (proximity sensors) voip works perfectly too (I also verified deep_sleep_ratio is 1 during calls with proximity sensor activated). Any real activity will prevent the deep sleeps so it's perfectly ok to ignore the high loads measured just after returning from the deep sleep.
Anyway feel free to experiment. I also wrote another patch to switch the governor to performance automatically when screen goes on, and return to ondemand (with deep sleep detection) when screen goes off. But I think this heuristic is better and ondemand won't be exactly as fast as "performance" but especially at 10000 sampling_rate the difference should not be noticeable. And so I prefer to save a tiny bit of power by using ondemand all the time. Plus it proofs the new logic is good if it works for both scenarios.
I still decrease the max cpu frequency when screen is off to 800mhz (not anymore to 100mhz after I found it screws the voip and playback with screen off). ondemand will immediately jump to max the moment the threshold is exceeded (default threshold is 95% of not idle time). So this helps because all csimpsimple/skype/musicplayer background non-interactive workloads that may run with the screen is off and this will avoid to ever reach 1ghz which isn't needed for any of those background apps. 1ghz returns when screen goes on again.
In addition to this patch you can also consider adding these two lines to init.rc, but they're just to tune it a bit more aggressively. In the end I couldn't measure any difference from either one (default is 0 for io_is_busy, and 95 for up_threshold) so I'm using the default values and I didn't add the below to my currently running kernel. Probably you can ignore this and only apply the patch to the kernel.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
I recall having read of some tweakded ondemand governor in some rom, but there was no link to source... again I recommend folks to post link to source whenever a new cooked rom is published.
Considering this is closer to a bugfix, if this is confirmed to work by others I can try push the deep_sleep_ratio as a core feature in the kernel, maybe under some better name, to enable in sysfs so in future releases changing init.rc would be enough. It may be useful to other than arm as this is a common problem of what happens after the cpuidle governor enter deep sleep and sleeps more than the sampling_rate.
You can use this to monitor the effect before/after.
adb shell 'cd /sys/devices/system/cpu/cpu0/cpufreq; while :; do cat stats/*; sleep 1; done'
With the patch applied (which also sets sampling_rate at 10000, your default currently is 40000) you will get this when screen is off.
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469564
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469669
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469774
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469888
3384
And this with screen on (without touching
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477547
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477652
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477758
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477864
3461
1000000 11324
800000 22619
400000 2067
200000 6297
100000 477956
3464
There is some seldom jitter still but nothing significant anymore (and with sampling_rate set to 10000, it wasn't just a jittering problem but it was at max freq all the time). Some minor jittering like above is just unavoidable if some userland run a bit longer, and at 100mhz it doesn't take much CPU load to run longer.
I also measured the raw performance by calculating PI and it's within the measurement range error if compared to performance governor. quadrant just fine too unchanged over 1600 at the 3rd run, so I'm optimistic it's not degrading perf.
cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.
Dividing the load by deep_sleep_ratio was too aggressive. I noticed some app was more laggy than with "performance" governor. The better approach to the long deep sleeps is to ignore jitters until the wall_time_delta converges. I added comments on the reason why this is better, and it seems also better to ignore time jitters in both directions (so also to ignore measurement of long wall_time when the wall_time_delta average is short, with screen on). I attached an update, it still avoids the jittering with the screen off and phone idle, and it works better with the phone on.
With this one phone sits at 100mhz with screen off (freq range with screen off 100mhz-800mhz), works fine when doing voip calls with proximity sensor as before. With screen on the freq range is now 200mhz-1ghz, considering that without the patch the phone may never reach 100mhz even with screen off, it is most certainly not going to make a difference and 100mhz is way too slow and we've to run at least 10msec at 100mhz before we can ramp up the freq. So this will double speedup those first 10msec compared to the prev version. The jittering with screen off completely goes away and the phone stays at 200mhz fixed if you disable the rotation sensors, otherwise there are 2 jitters from 200mhz to 1ghz and back per second, which is certainly fine.
I've been using for a while and I'm pretty happy and should work better than the previous version. That app were I noticed an higher lag with previous version, now seem to be as responsive as performance or at least I can't see a difference anymore.
If you test it let me know and please check when screen is off and phone not awake, if the battery is lasting longer or not. By looking the chart I attached (running the sleep2 version in this post) it seems my battery went down 2/3% in 6 hours with this. Frankly I don't remember if it was as good before... all I know for sure is that what happened before with ondemand didn't make much sense: a proper governor allowed to use a range from 100-800mhz must keep the cpu at 100mhz when screen is off and phone is idle, and with the deep sleep detection fix, ondemand finally behaves well, and it works fine with voip with screen off, it doesn't require to rump up the min freq from 100mhz to 200mhz with screen off, and it seems more responsive than before thanks to the 4 times more frequent sampling rate (and maybe also thanks to ignoring the long deep sleep cycles during interactive behavior but that I'm not entirely sure if it helped but it still looks good idea to ignore the infrequent wall_time_delta jitters). It's also likely that the cpu goes into very long deep sleep shutting down the cpu harder and maybe the freq it enters those states don't matter, but at least this should help if you play music in the background with the screen off, it manages to do that now at 100hz without skips.
It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work
pikachu01 said:
It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work
Click to expand...
Click to collapse
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.
newmail said:
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.
Click to expand...
Click to collapse
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)
zacharias.maladroit said:
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)
Click to expand...
Click to collapse
Thanks for the pointer! Appreciated . I won't have much time to look into this until the next weekend (I'll look into it ASAP , but with the last version I posted in comment #11 (ondemand-deep-sleep2.patch) things are going absolutely great. In fact it works much better with skype than the stock unpatched kernel: when I iconize skype during a call it won't degrade the audio anymore. I'm sure it degraded audio for a little if I iconized skype and started another app during a call. I guess it's the faster sampling rate, or maybe the fact I now ignore the long idle times if the average wall_time is short. Both are good.
The sampling_rate not being constant with long cpuidle times that disregard software timers, really requires this fix to the ondemand to perform great. So I'm super happy about this change so far. 100-800/200-1000mhz also works great. And this change won't have any effect on laptops/workstations where the timers should fire as expected. (I also tried 100-400/400-1000 for a while but there's no point it seems, 100-800/200-1000 is enough so I'm back to the exact values in the last patch I posted)
I doubt it's worth to stop the sampling like interactive governor does while cpu is idle, considering cpuidle will disregard the timers so there's no risk to wakeup too early because of a timer it seems.... I think this changes will improve ondemand in general and it is required fix for these phones IMHO.
The fact background apps like music player with screen off now run 95% of the time at 100mhz also looks great. I didn't have any sign of instability, and I run a lot of load on it (though only for the last few days...). I sent my patch to some samsung engineer who added the SLEEP_FREQ to the cpufreq upstream code (to enter suspend to ram at 800mhz which I didn't alter, that sure is fine change considering the cpu is cut off the power during suspend to ram, it'll speedup suspend to ram too in addition to not crashing phone as described in the patch . In my patch I only handle the frequency changes right when cpuidle runs for long and I doubt the cpu is cut off the power for only 60msec or 500msec when screen is off, that's too fast to cut the power completely I guess so I think it's worth it. And if it doesn't help to save power when idle, for it sure won't hurt either and the statistics now look sane and this change should help while using the phone too by allowing to lower the sampling_rate and avoiding interactive usage to be fooled by long cpuidle samplings started at high freq that decrease the freq just before the real loads come in and idle is exited (ignoring those long wall_times during interactive usage is also good and should save power too as the load will complete faster and cpu will be allowed to spend more time in idle at low freq then).
Deep Sleep
Hi, you said that you first came to this topic because some app was keeping your CPU from deep sleep, probably FB app. This night I also experienced that the phone did not go into deep sleep, it was awake all the time according the battery status. So is there a way to check, which app causes this behaviour?
See attachment for a screenshot.
newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?
zacharias.maladroit said:
newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?
Click to expand...
Click to collapse
Thought you were on time-out??
dachau said:
Thought you were on time-out??
Click to expand...
Click to collapse
This is his time out, wait till you see him on his kernel dedication time.
^^
Sent from my GT-I9000 using XDA Premium App
newmail said:
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.
Click to expand...
Click to collapse
Newmail, first of all your analysis + the mod for governor was awesome !
basically actually not a dev and i can't patch my kernel myself (hmm.a noob kinds when it comes to kernel stuff )
i'm wondering how would be your patch's results vs Smartassv2's coz your patch includes the stuff directly in Ondemand Governor that's a perfect approach making it more effective .
So, please could you prepare a CWM flashable if possible on behalf of those GPLv2 (idk what are those btw ) or a step by step procedure to perform the FIX .. ?
Thankyou again for your approach on CPU freq tweak !!
*I got this complete set of STweaks config from Verizon Note 2 section and it works well with GN-N7100/N7105*
Alright, below this, I will include an almost full guide to setting up STweaks (for those who do not want to use the provided profiles)
The CPU section contains the frequencies and voltages that you want to run at.
200mHz is the minimum speed, 1800mHz is the maximum speed. You can change these to affect your overall performance or battery life. Mine is currently set to 200mHz minimum, 1800mHz maximum. I have seen no hit on battery life at all (might be miniscule.)
Now for the voltages.. Each and every person will have a different set of voltages, as every CPU will be a little bit different. You can manually set your frequency to a certain level, use a CPU stress testing app (stability test) and drop the voltage by SMALL increments until you start to lose stability (system crashes, app force closes, etc.) I usually go UP one voltage step over the borderline stable voltage. I will post my voltages, but take caution, as my voltages are set pretty low compared to stock values on the kernel.
1800mHz - set to 1200000 uV or 1.2 volts.
1704mHz - set to 1175000 uV or 1.175 volts.
1600mHz - set to 1112500 uV or 1.1125 volts.
1500mHz - set to 1100000 uV or 1.1 volts.
1400mHz - set to 1062500 uV or 1.0625 volts.
1300mHz - set to 1025000 uV or 1.025 volts.
1200mHz - set to 1000000 uV or 1 volt.
1100mHz - set to 975000 uV or 0.975 volts.
1000mHz - set to 962500 uV or 0.9625 volts.
900mHz - set to 937500 uV or 0.9375 volts.
800mHz - set to 912500 uV or 0.9125 volts.
700mHz - set to 887500 uV or 0.8875 volts.
600mHz - set to 862500 uV or 0.8625 volts.
500mHz - set to 837500 uV or 0.8375 volts.
400mHz - set to 812500 uV or 0.8125 volts.
300mHz - set to 800000 uV or 0.8 volts.
200mHz - set to 787500 uV or 0.7875 volts. * BE CAREFUL WITH THIS ONE, it can cause your device to lock up when the screen is off, and need a battery pull if the voltage is too low.
CPU Scaling Section - this controls how your device will turn up the speed when it needs to.
Governor - This contols how the device will respond overall (power management, sleep, etc.) I will keep mine set to the Pegasusq governor unless I am running a benchmark, in that case, use perfomance (which locks the device to full speed and all 4 cores online)
Sampling Rate - how often the device will 'think' about changing the CPU speed. I have mine set to 15000 uS (15 milliseconds) so it is more responsive.
Sampling Down Factor - This enables you to create 'lag' when the device is at full speed, so it doesn't jump down frequencies when you don't want it to. I leave mine at default 1 sample, because I see no need for this.
Up Threshold - When a core hits this % utilization at a set frequency, then it will scale up to the next frequency. I have mine set to 96%, so the device will scale up slower and more reliably (keep in mind it makes this decision every 15 milliseconds.)
Down Differential - When the device scales down, (drops frequency) it must get below this % utilization to scale down ( UP THRESHOLD minus DOWN DIFFERENTIAL ) I have mine set to 5%, so it drops frequency at or below 91% utilization.
Frequency for Responsiveness - This helps keep the device smooth at lower frequency, and when the frequency is below the set spot, it will use a DIFFERENT up threshold so the device scales up faster and doesn't lag. My frequency setting is 500mHz, and the up threshold for it is set at 70%.
Frequency for Fast Down - this sets the frequency at which the device can use aggressive down scaling, much like the opposite of frequency for responsiveness. I have mine set to 1400mHz, and the up threshold is set to 98%, so the device only scales up if it really needs to.
Frequency Step - This applies to the Fast Down setting, and whenever the device gets above 98% utilization, then it will increase the frequency by a SET percentage of the maximum frequency. So if you set 10%, and are have 1800mHz max, it will increase to the closest step that adds 180mHz. I have mine set to 6%, so it increases by 108mHz.
The up threshold and frequency step decrease confuse me for this, but I have the up threshold set to 2%, and the frequency step set to 3%.
I didn't touch the flexrate settings, as everything else should control this area.
CPU Hotplug - This section will control how the device turns its cores on and off.
CPU Up Rate - How many samples you want to take until a core decides to turn on. (Sampling rate times your setting) I have mine set to 12, so if the conditions are correct, it takes 180 milliseconds to turn a core on.
CPU Down Rate - How many samples you want to take until a core decides to turn off. (Same thing as CPU up rate) Mine is set to 10, so it takes 150 milliseconds to turn off a core if it isn't being used.
Core Upbring Count - How many cores you want to bring online when the conditions are right. Mine is set to 1, I'm sure more will increase performance and hurt battery life.
Configuration Overrides - These can set you device to always have a certain amount of cores online, I don't use them (leave at 0.)
Hotplug Conditionals - These perameters are set to control when the cores turn on and off. Below are MY values
Hotplug 1 Core to ONLINE (make 2 cores online) - 600mHz
Hotplug 2 Cores to OFFLINE (make 1 core online) - 500mHz
Hotplug 2 Cores to ONLINE (make 3 cores online) - 700mHz
Hotplug 3 Cores to OFFLINE (make 2 cores online) - 600mHz
Hotplug 3 Cores to ONLINE (make 4 cores online) - 800mHz
Hotplug 4 Cores to OFFLINE (make 3 cores online) - 700mHz
The rest of this section, I left at DEFAULT values, because I did not understand them.
GPU - This section controls the frequencies and voltages of your GPU.
Maximum Frequency - How high you want your GPU to clock to, mine is set to 733mHz.
Minimum Frequency - How low you want your GPU to clock to, mine is set to 108mHz.
Up Threshold - Like the CPU setting, the percentage of utilization you achieve before the GPU scales up. Mine is set to 90%.
Down Differential - When you want your GPU to scale down lower, (Up threshold minus down differential.) Mine is set to 10%, so when the GPU hits 80% utilization on a speed, it drops to a lower frequency.
Utilization Timeout - Basically is the sampling speed of the GPU (how fast you want it to make decisions to change speed.) Mine is set to 25 milliseconds.
Voltages - Test these the same way as the CPU, get a GPU stress testing app, and set a certain frequency. When you see artifacts or glitches on your screen, then the voltages are too low. Below are MY values.
54mHz - 825mV
108mHz - 875mV
160mHz - 950mV
266mHz - 975mV
350mHz - 1050mV
440mHz - 1100mV
533mHz - 1125mV
640mHz - 1150mV
733mHz - 1175mV
800mHz - 1200mV (This clock speed proved to be slightly unstable at 1175mV, though still usable)
I/O section - These values/settings control how your device writes/reads things from the SD card, or internal storage.
I left both of my storage schedulers at ROW but you can change them and play around. I believe that deadline is the best for overall performance, but can be unstable sometimes.
I/O Read Ahead - These control the cache file on the internal/external storage. I have my internal set to 1536kB, and external set to 2048kB, because those values gave me overall good write/read speeds.
Dynamic Fsync - From what I know, this helps keep the data from being corrupted by creating a buffer between data being written and the storage. Correct me if I'm wrong. I kept it enabled.
The entire audio section is pretty self explanatory, and I'm getting tired of typing all of this, so if you need help, PM me or comment.
Again, take this entire post with caution. What works with my device, may make yours unstable. I only provided mine to give you a baseline, my values offer good performance and battery life anyways. Feel free to correct any of my errors by PM or comment, and I will gladly change my post to accommodate for my errors
My phone is stable at 782.5mv on perseus but in deep sleep it just isn't. Not even on 813mv.
this is XXXDDDAAA
And 2000 is max with Redpill.
this is XXXDDDAAA
Thanks for the guide, will test your settings:highfive:
McLaren__F1 said:
Thanks for the guide, will test your settings:highfive:
Click to expand...
Click to collapse
Do post your result here. It works great for me.
@moderator
Since i have been on xda for quite some time,i realised that many people here dont know much about governers,i/o schedulers etc. . So i decided to give them a guide which will help them learn the basics of these things.Please remove this thread only if u find this is a waste of time.
Click to expand...
Click to collapse
First of all ,i did not make this guide.It was made by "droidphile" ,a recognised contributor of xda forums.the original thread link is here-
http://forum.xda-developers.com/showthread.php?t=1369817
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.
4)droidphile for his excellent guide
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.
INDEX--
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
GOVERNERS
GOVERNERS
Click to expand...
Click to collapse
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-http://forum.xda-developers.com/showpost.php?p=24233103&postcount=3&nocache=1&z=3535953573882580
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!
GOVERNER TWEAKS IN NEXT POST
Governer tweaks
GOVERNER TWEAKS
Click to expand...
Click to collapse
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.
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 "#"
MODULES
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"
LIST OF MODULES
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)
I/o schedulers
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
DUAL CORE CPU Q&A and TWEAKS
DUAL CORE CPU Q&A and 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_control
Working 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.
To reduce heating of Yureka and operate it lag free, i tried several things and the best solution which I found out will be sharing here.
If you have a non-rooted yureka you can only do this:
Go to settings->privacy->privacy guard and click on advanced in menu. Locate google play services and disable
1. Wake up
2. Keep awake
3. Autostart
If you have a rooted device then along with above:
Use Sandy's custom kernel 1.3 non cpu quiet and install thunderzap control app and apply these settings
For cluster0 :
Governor- On demand
CPU Max- 1113 Mhz
CPU Min- 400 Mhz
For cluster1 :
Governor- interactive
CPU Max-1113 MHz
CPU Min- 249 Mhz
Also, you can install trickster MOD app and go to Specific menu and enable temperature throttle.
It brought down my CPU temp from 70°C to 50°C. Waiting for the update.
Hit thanks, if this did the job!