{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
TEAM INSOMNIA PRESENTS THE SPEEDY GONZALEZ KERNEL
DISCLAIMER: WE DO NOT TAKE ANY RESPONSIBILITY TO WHAT HAPPENS TO YOUR DEVICE. FLASH AT YOUR OWN RISK
CHANGELOG 12/10/2012 V1.5.5
-REMOVED SMARTASS2 SINCE IT WAS CAUSING PROBLEMS
-UPDATED SPLASH SCREEN IMAGE THANKS TO MRAZNDEAD
CHANGELOG 12/09/2012 V1.5
-ADDED MORE OC FRENQUENCIES
-ADDED VOLTAGE CONTROL (I SUGGEST USING SYSTEM TUNER)
-OVERALL A LOT OF CLEANING UP
CHANGELOG 12/02/2012 V1.4
-INCREASE VOLTAGES FOR OC FREQUENCIES
-FIXED USB CHARGING
-MORE SPEED TWEAKS
-OVERALL MORE STABILITY ACCORDING TO TESTERS
CHANGELOG 11/22/2012 V1.3
-INCREASE VOLTAGES FOR OC FREQUENCIES
-MAY OR MAY NOT HAVE FIXED USB CHARGING
-MORE SPEED TWEAKS
DOWNLOAD: SpeedyGonzalez-v1.5.5
DOWNLOAD: SpeedyGonzalez-v1.5
DOWNLOAD: SpeedyGonzalez-v1.4
DOWNLOAD: SpeedyGonzalez-v1.3
DOWNLOAD: SpeedyGonzalez-v1.2
CM9 DOWNLOADS
DOWNLOAD: SpeedyGonzalez-CM9-v1.2
DOWNLOAD: SpeedyGonzalez-CM9-v1
FEATURES:
-OC UP TO 2.0
-ADDED SMOOTHASS, LULZACTIVE GOVERNORS
-UPED VOLTAGE A LIL BIT
-MISC SPEED AND BOOT TWEAKS
-MISC SD SPEED TWEAKS
-BUILT WITH LINARO TOOLCHAIN 4.6
FOR MORE FEATURES CHECK OUT MY GITHUB
HOW TO FLASH:
DOWNLOAD
PUT ON SD CARD
BOOT INTO RECOVERY
WIPE CACHE
FLASH KERNEL
FIX PERMISSIONS
REBOOT
Source- github.com/smartguy044
OK GUYS HERE IT IS THE INITIAL FIRST PREVIEW FOR KERNEL 3.0.XX FOLLOW THE FLASH DIRECTIONS IN THE OP*
DOWNLOAD: HERE
*VERY VERY IMPORTANT PLEASE READ BEFORE YOU FLASH OR REPORT ANY PROBLEMS*
OK GUYS I HAVE DONE A LOT OF RESEARCH ON OUR CHIPSET AND PHONE. FROM WHAT I HAVE COLLECTED OUR CPU IS ONLY OVERCLOCKABLE UP TO 1.45. WITH THAT SAID YES A LOT OF PEOPLE HAVE OC TO 1.6+ WITHOUT ANY ISSUE INCLUDING MYSELF. *IMPORTANT* DO NOT COMPLAIN OR SAY THE KERNEL IS BAD IF YOU EXCEED THIS NUMBER AND GET BUGS. ALL CHIPS ARE NOT THE SAME SOME CAN GO TO 2.0 SOME CAN ONLY GO TO 1.2. ALSO IF YOU ARE RUNNING ANY TWEAKS OTHER THEN THE KERNEL (PMR ETC.) DO NOT COMPLAIN ABOUT BUGS UNTIL ALL TWEAKS HAVE BEEN REMOVED AND KERNEL TESTED AGAIN. I TEST EACH KERNEL ON MY PHONE AND WITH MY SETUP. I DO NOT USE ANY OTHER TWEAKS OTHER THEN THEN THE KERNEL ITSELF AND IT RUNS FINE FOR ME. THANKS HAVE A GREAT DAY
OK GUYS SO I BROWSED AROUND AND FOUND THIS GUIDE FOR UV/OC SO THANKS TO Klathmon FOR PUTTING IT OUT
It seems alot of people dont know the proper way to undervolt their phones, so I'm gonna try to help out! This is my first attempt at a guide, and i tend to ramble so just tell me if it makes no ****-for-sense
Undervolting is great, it allows us to change the voltage in our phones while we use it! this can really increase battery life and reduce heat in the phone. but if its not done right, it causes many more problems than it fixes.
When you are following this guide you WILL have issues! This is not a generic disclaimer, it is the TRUTH! the goal here is to find out where your phone stops working, and you cant do that without causing it to STOP WORKING.
once again: THIS WILL MAKE YOUR PHONE FREEZE, IT WILL HAVE AWFUL BATTERY LIFE, AND IT WILL MAKE BAD THINGS HAPPEN
But after its all done it should work much better
To start off, too much or too little voltage in the phone causes any number of things including:
Reboots (Screen Off and Screen On)
Lagging
Phone Overheating (Hot to the touch)
Reduced Battery Life (this includes the phone using more power, as well as reducing the battery's ability to hold a charge)
'Strange' issues with things shutting off/not working (WIFI, Bluetooth, your favorite app, ect...)
Many other 'weird' things
If you are having any of the above issues, and you are using a custom kernel, they may be caused by inproper undervolting.
THIS CAN BE THE CASE EVEN IF YOU HAVE NOT DONE ANY UNDERVOLTING YOURSELF!!!
Most custom kernels have undervolting build into them, and even 'stock voltage' versions allow overclocking, and those frequencies have no 'safe' voltage associated with them.
How to Properly Undervolt your Phone:
*this assumes you have no idea where to start, if you have some past experience, USE IT!!!*
First, Undervolting a phone the right way is not a quick job, like most things in life the more time you put into it the better your end result will be. For me i like to take an ENTIRE WEEK OR MORE to get all my settings down right. whenever you decide to do this, expect any and all of the issues i listed above to happen while you are trying to find the right settings.
Step 1: Starting Fresh
Disable all overclocking, undervolting, AND PROFILES on the ROM, you need to get the stock speeds working before you try to push the phone to its limit.
This will be your baseline. Use the phone like you normally do, text, call, surf the web, even let it sit in your pocket for a while. Do this for as long as you need to to be sure that everything is stable.
If you have any issues during this stage. STOP! add +25mv to every frequency across the board and start over. Do this up to 3 times if necessary, if after you have added +75mv to your stock voltage and you are still having issues, it is most likely something else in the rom causing the issue (rogue app, wrong kernel version, phone was dropped in the toilet too many times...) try to fix that first, or just try to ignore the issue, its up to you.
Otherwise, if everything is stable, Continue to step 2!
Step 2: Start Lowering Voltages
Lower all of the voltages by -25mv across the board. (If your phone needed any voltage added over stock to be stable, skip this step.)
This is where you begin testing the waters. Once again use the phone like normal, including some screen off time, as well as some CPU intensive tasks (playing music while websurfing, gaming, ect.)
If your phone is still stable after a good amount of time, then do it again. Your looking for the moment when things start to go wrong.
When you notice your first random reboot, or you start to feel the phone getting hot, or not responding STOP! you found the limit of your phone. Go back to the last working voltages you have and use them for step 3.
The more time you spend at this step the better your overall result will be! if you dont get any symptoms in an hour, they might show up later in the day, or overnight. Just take your time and have some patience.
Step 3: Lowering Voltages Independently
Now that you have a stable working phone. you can start lowering voltages one by one!
Starting with the lowest frequency, lower the voltage by -25mv.
Run this for a while, until you feel it is stable. Then move to the next highest voltage and do the same.
*If you have any issues, undo ONLY that frequency!!! Write down that frequency somewhere. you are done with it! you know that frequency is stable, and you shouldn't need to touch it again!!!
Keep doing this till you get to your stock maximum frequency, then continue to step 4!
*NOTE:* if any 2 voltages have more than a 100mv difference (125mv difference on Morfic's Kernels) between them, you need to raise the others around it to be equal or less than that. For exampe:
if at 1ghz, the phone is at 1000mv and at 1.2ghz the phone is at 1150mv. the higher one needs to be lowered (set 1.2ghz to 1125mv). if that is not stable for you then you must raise the lower one higher (set 1ghz to 1025mv).
Step 4: OVERCLOCKING!
At this point you should have a completely stable phone with no overclocking, grats! Now you get to start raising the frequency.
starting with the next highest frequency, set it to its stock voltage. if this is more than 100mv (125mv for Morfic's kernels) more than the previous frequency, set it to 100mv (125 for morfic) more than that.
run this until it is stable, and keep reducing it as much as you feel until you find instability. set it one step higher and move on to the next highest frequency.
if, after setting the voltage to 100mv (or 125mv) more than the last one, it is not stable, you need to raise the lower frequency's voltage up. sometimes this can cause a chain reaction that makes you raise 3, 4, or even all of the other frequencies up, if this happens you need to decide if that frequency is worth it to raise all the other frequencies to the next level.
If all is running good, proceed to step 5!
Step 5: The part where you hate me
(this step is optional, its just something i do to help with stability)
Now that you have a fully overclocked phone that is running as low of a frequency as it can safely, raise all of the voltages up by +25mv!
yes yes, i know, it sounds retarted to just undo that hard work and all that time you just put into finding the perfect voltages, but just hear me out.
Even if you spent a week on each step, did everything perfectly and tested everything you ever do on your phone and it is all completely stable. one day you are going to do something that will push the phone, which is running at its limit. so by adding 25mv to everything you are giving yourself some insurance. you may loose some battery life (i honestly don't ever notice a change with only 25mv) but when your phone alarm goes off in the morning to get you up for class, or you get that call you got that job you wanted, just be happy its not frozen on the table, or black screened in your pocket.
There you go! you should now have a stable phone with great battery life, and now you can stop bugging the devs about 'that strange reboot that is still there' or 'how every time you use his kernel you get black screens'
Click to expand...
Click to collapse
Android CPU governors explained
Credits!!!!
Deedii for taking the time to compile all this!
Click to expand...
Click to collapse
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
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: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: 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.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: 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.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
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: 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.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
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.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: 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.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
Obviously, this governor is only available on multi-core devices.
Click to expand...
Click to collapse
Awesome, thanks man
Sent from my 1.8GHz Linaro optimized Nexus 7
no problem im gonna try and do a lot more with it but this is a great improvement over stock
This is EPIC!!!! :laugh:
Great work dude!!!!
Phone locks up at 1804
Sent from my 1.8GHz Linaro optimized Nexus 7
no problem guys now if we can fix the camera issue for cm10 roms this will be a device worth keeping
IRX120 said:
Phone locks up at 1804
Sent from my 1.8GHz Linaro optimized Nexus 7
Click to expand...
Click to collapse
haha i havent went above 1.6 thats plent smooth for me :silly:
smartguy044 said:
haha i havent went above 1.6 thats plent smooth for me :silly:
Click to expand...
Click to collapse
I'll run a bunch of different tests and benchmarks either tonight or tomorrow to try to find the "sweet spot"
It's hard to say what everyone else's sweet spot will be though, as every chip is different. I think I'll be happy as long as I can get 1.4 without any adverse effects.
yea i ran 1.4 for a couple days then tried 1.6 and its fine....this is the best experience i have had with an oc kernel on any device i have owned
1.6 is fine, 1.8 locks up.
On my nexus 7, if I go above 2ghz it locks up, these CPUs aren't designed to go that high
Sent from my 1.8GHz Linaro optimized Nexus 7
yea its only a single core cpu so dont wanna strain it to hard
Freezing in 1.6 guess my phone is overheating on boot
Sent from my 1.8GHz Linaro optimized Nexus 7
thats no good ive been running 1.6 since yest with no problems
smartguy044 said:
thats no good ive been running 1.6 since yest with no problems
Click to expand...
Click to collapse
I was running benchmarks. Let my phone cool down and its fine now.
Great work
Sent from my SGH-T679 using xda app-developers app
Thanks man.....once we figure out camera I'll do some more work on kernel but it took me about 4 days non stop to get it to this
Sent from my SGH-T679 using xda premium
I'm going to try this with CM7, will report back.
Sent from my SGH-T679 using Tapatalk 2
Did you fix the USB problem?
Sent from my SGH-T679 using xda app-developers app
yes sir thats what i have been waiting on before releasing it
Related
Hi there,
I'd like to overclock my IncS to 1,3 Ghz...
But I don't know the right settings.
Can you please tell me the right setting for best performance (e.g. oc to 1,3ghz) and best battery life?
thanks
does anybody know?
Set max to your desired, min to the lowest it will go and scaling to smartass.
I'm OCd to over 1.4 and no issues... UCd to 192 with smartassv2 governor
Sent from my Incredible S using XDA App
the best performance I have experienced in my INC is when I put oc / uv beater to the following:
wake gov: ondemand
wake mins: 245000
wake max: 1228800
Sleep gov: Conservative
my sleep: 245000
Sleep max: 691200
when I take a test in antutu nenchmark for I the following result.
score: 2729
If I clocked lower or higher, the result is lower
Overclocking depends entirely on your chip.
You should use whatever governor suits your needs.
I personally use ondemandx which speeds up on demand (as the name implies), conservative tries to keep the frequency as low as possible, interactive uses max frequency if min isn't enough, smartass is an improvement of interactive that keeps performance high while improving battery life (meaning there's little reason to use interactive).
You can find it in more detail here.
So basically, smartass if you want performance, conservative if you want battery life, ondemand if you want something in between. In reality though, I don't think you'll see much difference between them and I've seen no difference in idle power draws, so if you don't use your phone all that much, they won't be that different.
Once you've picked a governor, you should set min speed to 122000 (no reason to use any higher) and max to whatever you want. Your phone will probably crash or suffer from bad performance if you go over 1.5 GHz, but it varies a lot. Might happen even earlier.
Once you've found your desired performance level, you should start tweaking your voltages. You can do that under the UV profile. In there, you can adjust voltages at different speeds and the phone will automatically use them at whatever speed it's at. You should undervolt to increase battery life, so start by reducing all by 25 or 50 and then temp apply. Use it like that for a couple of hours and if it doesn't freeze, you're probably stable. You can either stop here or spend many hours tweaking it further, but that'll take many hours to get right.
This is my setting
Sent from my HTC Incredible S using xda premium
Which would be the best O/C program out there ?! I have SetCPU, Daemon but I'm sure there is better in the market...... just need to know the name so I can get it Thanks!
I'm currently 230MIN/1150MAX
Me4oKyX said:
Which would be the best O/C program out there ?! I have SetCPU, Daemon but I'm sure there is better in the market...... just need to know the name so I can get it Thanks!
I'm currently 230MIN/1150MAX
Click to expand...
Click to collapse
In my opinion, and I'm sure many others', Virtuous daemon is the best by far.
It comes standard in a lot of roms, and using the OC/UV beater
http://forum.xda-developers.com/showthread.php?t=1207546
it would have the best performance. I've set mine similar to yours and with this method, you can set the phone to underclock when battery reaches a low level
This is not my work, i adjusted a bit (take several Governor out), so all credits go to droidphile.
i will myself accept THANKS
Explanation of Different Governors
1. GOVERNORS
These are the 9 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) SmartassV2
6) Intellidemand:
7) Lagfree
8) Userspacce
9) Performance
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) 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.
6) 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.
7) 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.
8) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
9) 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, Lagfree.
1.b) Conservative Based:
Members: Conservative,
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Smartass, SmartassV2,
3) Weird Category:
Members: Userspace, 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! smartassV2 for a balance between performance and battery. For light weight tasks. To get maximum performance, use a tweaked ondemand or conservative, but never complain about battery. NOTE: 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 apps such as system tuner,android tuner,kernel tuner etc.
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!
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/ 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
screen-on will not drain too much battery like you think!
HIT THE THANKS IF THIS INFORMATION WAS HELPFULL
Hello all !
I was bored in school today so I've written a governor concept idea for quad cores. I'm not a dev AT ALL (for now at least, i'm studying many different stuff, hardware / code related too).
I have no idea if this is possible or if this is clever but I wanted to share it anway. If it gives idea to a developer, that's totally worth it, otherwise, well... I had fun doing it
It's called Progressive.
Progressive
The name of the governor says all. The idea behind it is to be «*progressive*». It means it doesn't unleash the full power when it's not needed. It goes progressively higher in freq with more cores. This should make the phone cooler and the battery better. The delay (3 sec ) is just a number, not sure this is really nice. Also, I'm not sure how the S4 handles temperature.
Max freq 1.5 Ghz
Min freq 384 Mhz
Screen off
=> 384-918 Mhz // not too low frequency to avoid reboot
Screen on without touching since 3 sec // always check after 3 seconds for changing the state
=> 384-1134 Mhz only one core online
Screen on touched
=> 594-1134 Mhz two cores online // bump the min_freq to avoid keyboard lag and to add a bit of butter
Screen on touched with a medium load of task // not sure how quantify this
=> 594 Mhz – 1.5Ghz two cores online
Screen on touched with a high load of task // i.e. Games
=> 702 Mhz – 1.5 Mhz four cores online // max power
We also need a thermal protection to avoid any damage, this should do the trick
If the temp is >= 80°C
=> Two cores online max_freq 1134 Mhz until it reaches 70 °C // not sure about the temp, this can be adjusted
If the temps is >=70°C
=> Let 4 cores being possibly online but lower the max_freq to 1134 Mhz
Click to expand...
Click to collapse
What do you guys think ? Is this even possible ? Good, bad idea ?
I hope you enjoy reading it as much as I enjoyed to writte it
doesn't it do this already?
Fissurez said:
doesn't it do this already?
Click to expand...
Click to collapse
I'm not sure how the ondemand governor on nexus 4 works. So I can't really answer, it's really a noob idea that poped into my head today
you pretty much described interactive with mpdecision enabled.
not exactly, but quite.
3 seconds is way too long for the CPU to ramp up (just a matter of tweaking, though). you'd get more lag than you save battery.
mpdecision ramps the cpu to its maximum frequency as soon as a touch input is detected (normally only 2 cores until a certain threshold is reached), so yours should save a bit of power during smaller workloads.
also, if the touch input is released, it clocks the active cores down to 1.02 GHz for a bit before disabling them when not needed.
after all, it seems like a more conservative interactive governor with active mpdecision. could be nice for saving battery while retaining good performance.
it could be a viable choice for those who go for battery life over performance. :good:
Nuu~ said:
you pretty much described interactive with mpdecision enabled.
not exactly, but quite.
3 seconds is way too long for the CPU to ramp up (just a matter of tweaking, though). you'd get more lag than you save battery.
mpdecision ramps the cpu to its maximum frequency as soon as a touch input is detected (normally only 2 cores until a certain threshold is reached), so yours should save a bit of power during smaller workloads.
also, if the touch input is released, it clocks the active cores down to 1.02 GHz for a bit before disabling them when not needed.
after all, it seems like a more conservative interactive governor with active mpdecision. could be nice for saving battery while retaining good performance
Click to expand...
Click to collapse
Thank you Sir, I understand better how mpdecision works now
Glad to see i'm not completely stupid lol
So I want you guys to tell me which cpu governor, and which frequencies should I use.
I don't play games, so I don't need high performance, but i want smooth experience in rom itself...
And also want you to tell me which governor type gives best battery life...
AnnoyingZlatan said:
So I want you guys to tell me which cpu governor, and which frequencies should I use.
I don't play games, so I don't need high performance, but i want smooth experience in rom itself...
And also want you to tell me which governor type gives best battery life...
Click to expand...
Click to collapse
Use whatever you want xDDD
I use conservative, max frec 614mHz, min 245mHz, (I only use Whatsapp, phone, browser sometimes... It's enough for me)
Maybe it's very agressive to you o to other users, the best is that you on your own will discover which will adapts to your needs, and testing during a long time is the only way that you'll discover it.
Everyone has their personal tastes
and... a little explation about GOVERNORS (taking by GS2 forum, thank you droidphile )
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!
I let the frequencies as they were.
If you use higher ones, there will be reboots because of that. Lower ones will make the phone run slower.
Hello.
On CM 10.1 (improved, last buid - 2014/08/24) sometimes I have huuuuge lags. I encounter them often when somebody is calling me. It takes more than 10 secs to answer the call. Did anybody have similar problem?
Yes
I'm not sure but i think a fix would be a change in the build.prop .Also if something happens on your device im not the one who caused it...
krzysiekt1 said:
Hello.
On CM 10.1 (improved, last buid - 2014/08/24) sometimes I have huuuuge lags. I encounter them often when somebody is calling me. It takes more than 10 secs to answer the call. Did anybody have similar problem?
Click to expand...
Click to collapse
you changed cpu freq bellow 245 mhz and governor to power save? look in settings, => performance, min cpu must be 245 mhz, and governor ondemand or interactive/interactiveX its working fine on my mini2
ultravy said:
you changed cpu freq bellow 245 mhz and governor to power save? look in settings, => performance, min cpu must be 245 mhz, and governor ondemand or interactive/interactiveX its working fine on my mini2
Click to expand...
Click to collapse
What are the difference between Interactive and InteractiveX?
Antox97 said:
What are the difference between Interactive and InteractiveX?
Click to expand...
Click to collapse
Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
And so, which is the best governor and cpu's frequences for our Mini 2?
Min
245
Max
1125
In my phone i have this frequencies