Related
I wonder which freq can save more battery and not slow
Mine:
Wake up
max:1512
min:168
Wake Governor - interactive
Sleep:
max:540
min:168
Sleep Governor - conseractive
Kernel UNITY V7
And here is the freq settings recommended by CdTDroiD:
Recommended Daemon Settings:
Wake Min 384000
Wake Max 1296000
Wake Governor - Ondemand
Sleep Min 276000
Sleep Max 384000
Sleep Governor - Conservative
Guys,please post your settings here and discuss what is the best freq settings
Mine:
Wake up
max:1512
min:168
Wake Governor - ondemand
Sleep:
max:384
min:168
Sleep Governor - conseractive
Kernel UNITY V7
jerrylzy said:
I wonder which freq can save more battery and not slow
Mine:
Wake up
max:1512
min:168
Wake Governor - interactive
Sleep:
max:540
min:168
Sleep Governor - conseractive
Kernel UNITY V7
And here is the freq settings recommended by CdTDroiD:
Recommended Daemon Settings:
Wake Min 384000
Wake Max 1296000
Wake Governor - Ondemand
Sleep Min 276000
Sleep Max 384000
Sleep Governor - Conservative
Guys,please post your settings here and discuss what is the best freq settings
Click to expand...
Click to collapse
I'd lower your sleep. No need to sleep at 500 mhz.
I have the Sensation and the Revolution HD rom installed. The rom came with the CPU upped to 384000/1512000/ondemand; 192000/384000/ondemand but I'd like to take it back down to defaults. I'm a little worried that its running too high/hot. The phone yesterday got really really warm and wouldn't turn on until I pulled the battery and restarted it. So to be on the safe side, I'd like to just put it back to defaults and then remove the Daemon Controller. My Google searches for "Daemon HTC Sensation" have come up empty handed. Any help would be appreciate! Thanks in advance.
Sleep:
All lowest setting
Wake-
Min: 1.4Ghz
Max: 1.78Ghz
*Subscribing*
Just put wake to whatever you want and sleep.to lowest settings. I change them on the fly depending on if I play games or not. Lower them when your not doing anything that needs high cpu usage
I use the stock settings that Mike has in the latest ARHD and performance is seems ok along with battery life.
jacksparr0w said:
I use the stock settings that Mike has in the latest ARHD and performance is seems ok along with battery life.
Click to expand...
Click to collapse
same for me even tough its on the inc s.
hi guys..,
pls share ur setcpu settings here...so that we can get some idea...we can choose the better ones...
To start with..,
i 've kyrillos rom 9.2 oc.., g3mod v2.2.2
My Settings:
- Main tab: Min 83Mhz, Max 1200MHz, Scaling: Conservative
- Profile (1): In call: 83min, 400max, Scaling: Ondemand, Priority:100
- Profile (2): Time profile: 1AM - 7AM (here put the time you sleep), min/max 83MHz, Scaling: Powersave, Priority: 99
- no voltage profile...
but it lags a bit at times....
pls share ur setcpu settings....here...
G3Mod 2.2.2.
Main profile : - Min 83, Max 800, Profile Lagfree.
Profiles, priorities in descending order.
1) Battery<15 : 400 Max 83 Min, Powersave.
2) Screen off : 400 Max 83 Min, On Demand.
3) Charging : 600 Max 83 Min, On Demand.
4) In call : 400 Max 83 Min, On Demand.
Kyrillos 9.3 and G3Mod 2.2.2 OC
main profile: 400-1000 - ondemand
time profile (00:00-06:59): 83-200 - conservative (priority: 100)
screen off profile: 400-500 - ondemand (priority: 99)
no undervolting and other settings, just sampling rate set to: 10000
guys...,only a few reply...
i don't know...why nobody show any interest to share ur setcpu settings...
LooksLikeSmart said:
guys...,only a few reply...
i don't know...why nobody show any interest to share ur setcpu settings...
Click to expand...
Click to collapse
simple answer... DONT USE MORE THAN 800mhz... even 801 will burn your phone's motherboard thats all i can say..
lovelyprincess said:
simple answer... DONT USE MORE THAN 800mhz... even 801 will burn your phone's motherboard thats all i can say..
Click to expand...
Click to collapse
I dont think so... It will just shorten the life of the cpu.
Sent from my GT-I9003 using xda premium
hi bscraze.,
i've posted my setcpu settings above...is it safe...?? whether i've to change max to 800Mhz...what about scaling...conservative or lag free..
pls post urs if u have...
My profiles for i5801:
Main tab - 200~700mhz on demand/lag free both works for me
Charging - 300~1200mhz on demand
Screen off - 83~500mhz on demand
Time 1am to 5.30am 83~83mhz powersave
You can try my profile, may work, may not but i advise you to change to 800mhz for your main tab.
Sent from my GT-I9003 using xda premium
lovelyprincess said:
simple answer... DONT USE MORE THAN 800mhz... even 801 will burn your phone's motherboard thats all i can say..
Click to expand...
Click to collapse
. No it won t.
hi..,dhirend_6d
i've set cpu settings used for 3 months...Main tab: Min 83Mhz, Max 1200MHz, Scaling: Conservative
no harm done...everything working fine...
but..is it safe...to continue always...? or
whether i've change it to 800MHz as suggested by bscraze...
LooksLikeSmart said:
hi..,dhirend_6d
i've set cpu settings used for 3 months...Main tab: Min 83Mhz, Max 1200MHz, Scaling: Conservative
no harm done...everything working fine...
but..is it safe...to continue always...? or
whether i've change it to 800MHz as suggested by bscraze...
Click to expand...
Click to collapse
You should keep it 800 max for normal usage because keeping high frequencies shortens processor life. Use higher frequencies(1000+) only when needed like when playing games and etc. At 800, in normal usage, all works smooth. Note I use lagfree as main profile. I suggest you also try lagfree once.
Kyrillos 9.3 and G3Mod 2.2.2 OC
main profile: min 83 - max 700 - ondemand
In call: min 83 - max 400 ondemand(priority: 100)
screen off profile: min 83 - max 400 - ondemand (priority: 98)
Ok now you scared me. Can higher freqs really damage motherboard or shorten cpu life?
These are my settings:
main 400min 800max ondemand
prof1: time 01:00 - 07:30 83min 83 max pwersave priority 99
prof2: screen off 83min 400max ondemand priority 98
prof3:In call 83min 400max ondemand priority 100
No undervolting.
Any suggestions or something?
cecenac said:
Ok now you scared me. Can higher freqs really damage motherboard or shorten cpu life?
These are my settings:
main 400min 800max ondemand
prof1: time 01:00 - 07:30 83min 83 max pwersave priority 99
prof2: screen off 83min 400max ondemand priority 98
prof3:In call 83min 400max ondemand priority 100
No undervolting.
Any suggestions or something?
Click to expand...
Click to collapse
They are perfect. You don t have to worry about anything with those settings. If you use 1000+ frequencies for longer periods continuously then it may reduce your CPU life. Use only when required.
cecenac said:
Ok now you scared me. Can higher freqs really damage motherboard or shorten cpu life?
These are my settings:
main 400min 800max ondemand
prof1: time 01:00 - 07:30 83min 83 max pwersave priority 99
prof2: screen off 83min 400max ondemand priority 98
prof3:In call 83min 400max ondemand priority 100
No undervolting.
Any suggestions or something?
Click to expand...
Click to collapse
Cpu chips are made to last at least 5 yrs so dont worry about it and like what dhirend said, only if you keep it at high frequencies for long times will it dmg the cpu more.
Sent from my GT-I9003 using xda premium
Hi, I have Kyrillos 9.4 & g3mod 2.2.2 OC.
My settings:
Main: 83-700Mhz ondemand
InCall 83-600Mhz ondemand
Screen Off 83-400Mhz ondemand
and I my i5800 freezes 3 times per day.
I don't have game, only necessary aps.
Please help me.
lefar333 said:
Hi, I have Kyrillos 9.4 & g3mod 2.2.2 OC.
My settings:
Main: 83-700Mhz ondemand
InCall 83-600Mhz ondemand
Screen Off 83-400Mhz ondemand
and I my i5800 freezes 3 times per day.
I don't have game, only necessary aps.
Please help me.
Click to expand...
Click to collapse
try cm7 marcellusbe or kyrillos, then you will never have a freeze again!
I'm on Kyrillos v9.4, kernel G3Mod v2.3
83Mhz, Max 800-1200MHz, Scaling: Ondemand
In call: 83min, 400max, Scaling: Ondemand, Priority:100
Time profile: 1AM - 7AM (here put the time you sleep), min/max 83MHz, Scaling: Powersave, Priority: 99
Screen off: 83min, 400max, Scaling: Ondemand, Priority:98
my battery lasts three days with normal/heavy usage
Hi,
I'm on kyorarom 0.5.1 with kernel G3MOD-Kyorarom-0.5.0
main: 83 - 800 lagfree
1. in call: 300 - 800 lagfree (if less I have to wait a lot to see the screen waking up) priority 100
2. screen off: 83 - 600 lagfree priority 100
3. charging: 83 - 900 lagfree priority 99
no freese, no FC, only one thing: when I wake up the phone from screen off I sometimes see the last screen before the lockscreen appears and I tried to change the off screen values and it was all the same...
baterry lasts at least 3 days with some wifi use, low BT use, some apps and games, but a lot of phone calls and sms
Everybody over here just check out this(forum.xda-developers.com/showthread.php?t=1369817) thread to understand the things better. (about governers, modules, etc) . Must see thread!!!
Rom: Leedroid V2.1, Axiom S V1.0, TrickDroid V5.0(EU)
Kernel: stock HTC, Lowkernel v1.0.1, Vistuous v06
Apps & scripts: SetCPU, CPU Editor, Quick system info pro
http://forum.xda-developers.com/showthread.php?p=28214411#post28213828
There are also some other people who reported the same issue in this thread.
I'v tried all these kernels on three ROMs and they reported the same problem. The cpu1(2nd core) always keeps as ondemand mode. I've to use CPU Editor and enable Dual Core Mode to force it to other mode but after a reboot, it will reset to ondemand again. Sticky Enabled has no use here.
Another thing is after a reboot, the cpu1 frequency will also get a reset to the kernel's max. frequency supported. I've to set it again too.
Use Quick system info pro, it will shows out the current cpu0/1 governor and cpu scaling range very clearly.
SetCpu looks messed up on One S. The max frequency actually works as cpu1's max frequency while min frequency actually works as cpu0's max frequency.
It has no club to run the cpu1 ondemand at max all day long, it's just a waste of battery. On such a powerful S4 cpu, it's also non-sense to use ondemand governor as default. Interactive, Conservative, SmartassV2 are all better choices.
As a result, by using CPU Editor to lower the cpu1's speed and switch to other governor, my battery on daily use improved.
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
22: BadAss
23: Wheatley
24:Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: IntelliActive
30: Adaptive
31: Nightmare
32: ZZmove
INFO I/O Scheduler Go Here: SCHEDULER
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."
22: BadAss Goveronor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24:Lulzactive:
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.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: Hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths
30: Adaptive
This driver adds a dynamic cpufreq policy governor
designed for latency-sensitive workloads and also for demanding
performance.
This governor attempts to reduce the latency of clock
increases so that the system is more responsive to
interactive workloads in loweset steady-state but to
to reduce power consumption in middle operation level level up
will be done in step by step to prohibit system from going to
max operation level.
31:Nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery.
In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmove
ZZmove Governor optimized for low power consumption with the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. It has three settings: battery saver, balanced and performance. In addition to a performance boost, there is also the governor zzmove optimized.
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817
20 and 21 seem to be the best choice cause it saves batery but doesnt compromise performance when its needed. What do you think? And even a better question whitch one do you use?
Sent from my Xperia S
king-dano said:
20 and 21 seem to be the best choice cause it saves batery but doesnt compromise performance when its needed. What do you think? And even a better question whitch one do you use?
Sent from my Xperia S
Click to expand...
Click to collapse
I often use intellidemand, excellent battery life and good performance
Nice guide.
For my Galaxy Note, I am using abyssplug governor. It is derived from Hot plug.
Sent from my GT-N7000 using Xparent ICS Tapatalk 2
stempox said:
I often use intellidemand, excellent battery life and good performance
Click to expand...
Click to collapse
Thanks !
Very nice guide!
Good guilde. I am using SmartassV2 on my galaxy r.
What about Lulzactive and pegasusq ?
thanks .. I hope that many of you may be a useful guide
if you want, as governor scivete used and why,
so we will have evidence of actual use
coming soon new governors
thread updated
Really good work!!
Gesendet von meinem Galaxy Nexus mit Tapatalk 2
thanks, I'm glad it's useful for you
Thanks, for the next week, renewal of the thread
Very useful thanks
Thanks to you guys
Smartassv2 is the best that I have used.
itisbasi said:
Smartassv2 is the best that I have used.
Click to expand...
Click to collapse
Also here, with nexus s use mainly smartassv2
24:Lulzactive added
This is not my work, i adjusted a bit (take several Governor out) for Sensation, 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