So I flashed Imnuts' new kernel and i am trying to OC/UV. Using the voltage control app i can get the CPU frequencies and I/O scheduler to stick at boot. However, the governor always resets to ondemand. Is there a fix to the init.d script that would change the governor too? I really like this app, as opposed to No Frills Cpu Control, which runs all the time to apply at boot.
What are best settings for optimal/same performance and maximum battery savings in SetCPU or CPU tuner for stock ICS 4.0.4 KERNEL?
Thanks
I have Arc S LT18i (model 12w17). I can't unlock bootloader with testpoint at the moment and I do not wan't to do it officialy. I'm using SetCPU.
I have ondemand, conservative and interactive governors and noop and deadline schedulers. I'm always using using noop scheduler.
I have set ondemand 122-1401MHz for ScreenON & InCall profiles with sampling rate 40000 and up treshold 95.
I have set conservative 122-1024 for ScreenOFF profile with up treshold 70 and down treshold 30 and sampling rate 200000 (lowest possible for my stock kernel).
Will test it for a few days. If anybody has better settings and tested ones please help...
I think conservative is best for screen off, thinking about lowering freq to 122-806. What I'm mostly interested is if interactive is better for ScreenON and InCall use than ondemand for battery durability?
Updated some setting based on CPU Spy and some reading on xda forum.
ScreenOFF profile
Up/down 70/30 thresholds no good for conservative, changed to 90/40. Enabled ignore nice load. Changed freq_step from 5 to 10 to balance change of thresholds.
When playing music in background freq was 368 and was jumping to 768. With new settings freq was mostly 245 with jumps to 368.
ScreenON or Incall profile
Ondemand up threshold changed to 90 (smoother), enabled ignore nice load, sampling rate left to 40000.
Unsure if 122MHz freq is good to use because when playing music in background there are significantly more jumps to 1401 than from 245MHz.
On stock kernel, 122 and 245 both run on 900mV. Read on forum that 122MHz can use more battery because processes need more time to finish than on 245MHz, instead processes finish faster on 245MHz (and what bugs me is that both freq uses same voltage) and phone enters deep sleep faster.
245MHz is stock kernel minimum default. Any HELP?
you can search on xda about the settings of setcpu... there is a detailed description about all the settings and you can choose the ryt one according to you usage:good:
---------- Post added at 08:52 PM ---------- Previous post was at 08:50 PM ----------
hope this may help you http://forum.xda-developers.com/showthread.php?t=843406
Imho profiles are useless since the more profiles you have, the more often the app needs to get active to check for a particular situation such as screen of, and governours already do that - they are profiles for the cpu
Hello,
I'm using SmartassV2 as CPU Governor and And SIO as I/O Scheduler.
But when i check the CPU frequency it stays at the max frequency (1728) and doesn't change, except when my device goes in sleep mode.
Am i the only one with this? Is this normal or is something wrong?
Thanks in advance!
Many basic android users must be confused about what are Governors...what to they do.
So in this thread Each & Every governor is well explained..to clear all of ur doubts.
I am just sharing the work of XDA member @stempox
Link to another thread where Android Kernel/Governors/Tweaking well explained by @droidphile
http://forum.xda-developers.com/showthread.php?t=1369817
Most of us are flash maniacs, and we do it a lot. But
after a kernel flash, we wonder: what actually are governors :what:
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 on I/O Scheduler go here:
http://forum.xda-developers.com/showthread.php?t=2793259
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 (= 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/showthread.php?t=1369817
__________________
So here is the situation. On my s5 901f
The kernel + rom combo I use sets noop as default governor confirmed by the dev androidgx.
If I boot the phone e.g. 10 times, about 70% of time it boots with noop, the other 30% with cfq.
Even if it boots with noop or I change to noop, eventually it changes back to cfq (without rebooting, so e.g. if I check day later its back to cfq).
The only 2 apps I have that by design can adjust the io scheduler are trickstermod and setcpu.
If i remove trickstermod the issue still occurs.
If I remove setcpu, the issue still occurs.
I have never removed both at once tho as I need an app to show me the governor in use.
Is there anyone else who has ever had this issue and knows how to resolve? is there a log I can do which shows what is changing the io governor?