Database Users

CPU governor or SetCPU or both questions

I currently have UD 1.1b2 with sibere kernel v13 installed.
Now I think, it clocks not to 1200 but to 1000, due to a report of Quadrant System information.
Do I have to edit a file (which one) on my device so CPU governor is clocking to 1200 or is installation of SetCPU required?
Somewhere I read, these two interfere with each other.

Posted the same in the other Thread:
I installed Stab. Test but it tells me with the root testing (name forgotten) that only 1000 MHz max are tested.
I have an overclocking kernel which should go to 1200.
How can I test 1200 with this app?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=16548823#post16548823
€dit:
It seems the 1200 max freq setting is constantly overwritten by something.

The governor is responsible for the adjusting of the clock while Android is running.
SetCPU allows for an easier switching between installed governors and to set other Min-Max Frequencies.
They both do a complete different job.
Please check with either SetCpu or Overclock Widget that the min-max values are 300-1200 and then you should be good.
And keep in mind, with any other governor then performance you will prob. never see 1200 on any widget.
Setcpu has an info page where you can see (time in state ) what freqs are used.

I just let Uruk handle the CPU governor. I also use the following...
CPU Spy is simple app to display the time the CPU spends in each frequency state:
https://market.android.com/details?id=com.bvalosek.cpuspy
Temp+CPU V2 is a widget and will show current CPU speed, CPU load, batt temp, and ram:
https://market.android.com/details?id=com.sanels.tempcpuv2

That is the problem.
I set SetCPU to 300 - 1200.
Shortly after doing that, it switches automatically to 800 or 300 - 1000.
No more 1200 anymore on SetCPU main Screen.

I like to minimize the number of apps not written by me doing stuff behind the scenes, and so I just use a startup script to set the CPU settings. This also fixes a problem with video player apps on the Gen8 archos automatically fixing the CPU rate at 800 MHz (which is sometimes not enough for Netflix and sometimes too much for other things), though it may be that the current version of SetCPU also fixes this (I reported the issue to the SetCPU author).

CPU Governors explained

Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/showpost.php?p=26884865&postcount=2
Android CPU governors explained
What is a governor?
A governor is a driver for the regulation of CPUFreq - CPU frequency. As the name suggests, we, the Governor of the decision, when at full capacity, the MaxFreq - will be achieved or how fast the minFreq - - maximum frequency is reached minimum frequency or center frequency. He decides when, how and how long the CPU and still responds battery saving is still soft and still works.
There are many types of governors. Some are for single-core processors and some designed for dual-core processors. In stock kernel, there are five governors and quasar kernel, there are a lot more.
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: Wheatley
23: Lulzactive
24: AbyssPlug
25. BadAss
26. Ktoonservative
27. AssWax
28. Sleepy
29. Hyper
30. Zen
31. Dyninteractive
32. SmartassH3
33. Smartmax
34. Pegasusq
35. Nightmare
36. Darkness
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 scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.
The key difference in the “hotplug” governor is that it will disable auxillary CPUs when the system is very idle, and enable them again once the system becomes busy. This is achieved by averaging load over multiple sampling periods; if CPUs were online or offlined based on a single sampling period then thrashing will occur.
Sysfs entries exist for “hotplug_in_sampling_periods” and for “hotplug_out_sampling_periods” which determine how many consecutive periods get averaged to determine if auxillery CPUs should be onlined or offlined. Defaults are 5 periods and 20 periods respectively. Otherwise the standard sysfs entries you might find for “ondemand” and “conservative” governors are there.
Obviously, this governor is only available on multi-core devices.
22: Wheatley
in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice.
23: Basically interactive governor with added smartass bits and variable (as opposed to fixed amout) frequency scaling, based on currently occuring cpu loads. Has, like smartass, a sleep profile built-in. See link for details on exact scaling.
24: Abyssplug governor is a modified hotplug governor.
25. BadAss Governor:
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.
26, Ktonnservative
Ondemand scales to the highest frequency as soon as a load occurs. Conservative scales upward based on the frequency step variable which means for the most part will scale through every frequency to achieve the target load thresholds. What this practically means is ondemand is prone to wasting power on unneeded clock cycles. Ondemand also features something called a down differential, this variable determines how long the governor will remain at the given frequency before scaling down. Conservative does not have this, but instead relies on having a down threshold which insures that as soon as the load drops below a given variable it scales down as fast as the sampling rate allows. The result to this is a governor which attempts to keep the load level tolerable and save you battery! Now ! Ktoonservative Is that but in addition contains a hotpluging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior. While by default conservative is a poor performer it can be made to perform comparably to even performance governor. Here are some settings to discuss and start with. They are slightly less battery friendly under a load but very very well performing.
27. AssWax
So far, all I have found about this Governor is that it belongs in the interactive family. I'll update this when I find more
28. Sleepy
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on the getweakten Ondemand of Arighi and is optimized for the SGS2. It may include imoseyon's Ondemandx with some tweaks Down_sampling and other features that set by the user through the sysfs of "echo" call. Sleepy is the behavior of Ondemandx when he is in action, very similar.
29. Hyper
The Hyper (formerly known as kenobi) is an aggressive smart and smooth, optimized for SGS2 getweakt and, based on the Ondemand, which was getweakt of Arighi and was equipped with several features of Ondemandx suspend imoseyon. (Added by sysfs, the settings suspend_freq and suspend Imoseyon's code) is the behavior of the hyper Ondemand if he is in action, very similar. He also has the Arighi's fast_start deep_sleep and detection features. In addition, the maximum frequency is in suspend mode 500Mhz.
30. Zen
Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V(R), but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op. (Credit bbedward http://forum.xda-developers.com/showthread.php?p=33327389)
31. Dyninteractive
All I can find about this governor is that the DynInteractive seems to behave perfectly in terms of frequency ramping so far and keeps the system running mostly on low clock speeds, unless really needed (games, heavy browsing, etc).
32. SmartassH3
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of.
33. Smartmax
This is a new governor which is a mix between ondemand and smartass2 By default this is configured for battery save - so this is NOT a gamer governor! This is still WIP!
34. Pegasusq
Read This: Pegasusq Governor
35. 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.
36. Darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. * Alucard updated nightmare gov and improved stability, so far what stable in tests
Credits goes to:
http://icrontic.com/discussion/95140/android-cpu-governors-and-you-setcpu-system-tuner-tegrak
http://forum.xda-developers.com/showthread.php?t=1369817
What is a scheduler?
In a multitasking operating system, there must be an instance, the processes that want to run, CPU time and allocates it "goes to sleep" after the allotted time (timeslice) again. This instance is called the scheduler, such as opening and closing applications. that is, how fast they are open and how long they are kept in RAM.
I / O scheduler can have many purposes like:
To minimize time searching on the hard disk
Set priorities for specific process requests
To regulate a particular portion of the bandwidth of the data carrier to each running process
To guarantee certain process requests within a certain time
Which scheduler are available?
CFQ
Deadline
VR
Simple
Noop
Anticipatory
BFQ
Sio
Row
Anticipatory:
Two important things here are indicative of that event:
- Looking on the flash drive is very slow from Equip
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.
Benefits:
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like the noop
Disadvantages:
- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives
CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Prozess-I/O-Warteschlange, ie the available I / O bandwidth tried fairly and evenly to all I / O requests to distribute. He created a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, ie each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There is a V2 and the CFQ has some fixes, such as were the I / O request, hunger, and some small search backward integrated to improve the responsiveness.
Benefits:
- Has the goal of a balanced I / O performance to deliver
- The easiest way to set
- Excellent on multiprocessor systems
- Best performance of the database after the deadline
Disadvantages:
- Some reported user that the media scanning would take this very very long time and this by the very fair and even distribution of bandwidth on the I / O operations during the boot process is conditioned with the media scanning is not necessarily the highest should have priority
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
Deadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ very popular and in many well known kernels, such as the Nexus S Netarchy. He was indeed better than the BFQ, but compared to the VR he will be weaker.
Benefits:
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage does a CPU is easy to calculate.
- As the Governor-noop ideal for flash drives
Disadvantages:
- If the system is overloaded, can go a lost set of processes, and is not as easy to predict
SIO:
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. With him there is no conversion or sorting of requests.
Benefits:
- It is simple and stable. - Minimized Starvations (starvation) for inquiries
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers. - Sequential read speeds on flash drives, not as good
Noop:
The noop scheduler is the simplest of them. He is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our SGSII's to use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. ie the data that come first are written first. He's basically not a real scheduler, as it leaves the scheduling of the hardware.
Benefits:
- Adds all incoming I / O requests in a first-come-who-first-served queue and implements requests with the fewest number of CPU cycles, so also battery friendly
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance einhergehendem
VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request. The VR is a very good scheduler with elements of the deadline scheduler. He will probably be the best for MTD Android devices. He is the one who can make the most of the benchmark points, but he is also an unstable schedulers, because his performance falter. Sometimes they fluctuate below the average, sometimes it fluctuates above the average, but if above, then he is the best.
Benefits:
- Is the best scheduler for benchmarks
Disadvantages:
- Performance variability can lead to different results
- Very often unstable or unzverlässig
Simple:
As the name suggests, it is more of a simple or simple scheduler. Especially suitable for EMMC devices. He is reliable, maybe not as good as the VR, when this time has a good day, but he is despite all this very performance-based and does his best. At the moment it is the default scheduler in quasar kernel.
Advantages: - not known
Cons: - not known
BFQ:
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks.
Benefits:
- Has a very good USB data transfer rate.
- Be the best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
Disadvantages:
- Not the best scheduler for benchmarks - higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
Row:
Q: What is the ROW I/O scheduler?
A: ROW stands for "READ Over WRITE"
The ROW IO scheduler was developed with the mobile devices needs in
mind. In mobile devices we favor user experience upon everything else,
thus we want to give READ IO requests as much priority as possible.
In mobile devices we won’t have AS much parallel threads as on desktops.
Usually it’s a single thread or at most 2 simultaneous working threads
for read & write. Favoring READ requests over WRITEs decreases the READ
latency greatly.
How can I change the governor and scheduler?
There are two ways to change the governor and schedulers, as well as the settings for the Governorn. Either manually, in which you use a file manager like Root Explorer and then knows how to / sys / devices / system and then change the files to his wishes, provided you what you're doing, or via a graphical interface or by phone as SetCPU Voltage Control. These are the most prominent apps when it comes to adjusting the governor and / or scheduler.
- SetCPU are, besides the possibility of the clock speed of the CPU, setting profiles in certain situations, only to change the way the governor. The scheduler can not change it.
- Voltage control can alter both the governor and the scheduler, but has no way to adjust behavior profiles. While you can set various overclocking, Governor and scheduler profiles manually, but nothing more. Nevertheless, I prefer the VC, since it is simple and gives me the opportunity to change the scheduler.
Credit goes to [url="http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html]Tinzdroid[/url]

Damn learn something new today. Bookmark this page....
that dude drives a A-Team van. yeah that's right, I'm working on it. Z.R.T.

hey hip kat which are you running?

SmartassV2.
Seemed like the best mix of performance vs. battery life from what I was reading.

link to Wheatley:
http://forum.xda-developers.com/showpost.php?p=21864389&postcount=75
link to lulzactive:
http://tegrak2x.blogspot.com/2011/11/lulzactive-governor-v2.html

good reading hipkat..... thanks for the info

Nice info, thx mate

This was really helpful, thanks!

Dude thank you for this writeup. Extremely helpful. OndemandX works great on Sense ROMs IMO

Thanks for the info .

I'm gonna sticky this as the info is great to have for users. The only thing I ask is that along with credits you attach a link to the original thread please.
xda moderator/recognized contributer

Thank you, Papa!!!
I'll go look for it and get the link in here asap
I'll update it, too, as I learn about the newer governors that come out, etc.

thanks for the info

Thanks, now how about schedulers noop or bfq

jasonwojo75 said:
Thanks, now how about schedulers noop or bfq
Click to expand...
Click to collapse
Good idea, plus there are newer governors coming out that I need to get added to the OP

Wow man, summed it up pretty damn good. I was curious as to what differences there were between all the governors out there.
Well written and in-depth, this helped my understanding of them a great deal, you are thanked.

Performance Governor
I thought too that running at "Performance" governor was a crazy idea, and I just tried setting it on my HD2 at around 1:10 PM today, little over an hour ago. I'm on NexusHD2-ICS-4.0.4-CM9-HWA V2.3 ( tytung_HWA_r3), BDW. I'm running gmail, Skype and other "push" apps on the background all the time, and WiFI is constant ON.
To my surprise, after looking at SystemPanel history, the battery has been flat for almost an hour! (See screenshot attachment)
So I guess the theory is correct, where the variable bitrate (up/down scaling) consumes more cpu and battery that just runing full speed while processes demand it, and then fast fall time to low power. So fast rise/fast fall seems to be best battery saver and performance.
More tests need to be done, but so far, I hadn't seen my battery consumption this good, with any other governor!
Cheers

I totally agree with that, that scaling up and down puts more of a load on the cpu. Think about a car motor. Idling, vs revving it over and over

Awesome thread! This helps a lot on which gov to use! +1

Nice thread. I personally like SavagedZen. 2nd choice is Wheatley.

[Kernel] Overview for SGSIII [14/06]

Hey xda´s,
here i´ll post some kernels for SGSIII. If anyone knows another plz give me a link and i´ll add it with link to devs original thread.
-----------------------------------------
CF-Root 6.2 - SuperSU+CWM5.5+CWMManager
stock as possible
-----------------------------------------
★TITANIUM KERNEL★ OC/UV • CIFS • TUN • SIO • And lots more!
Features - What my Kernel is made up of-
Root, Busybox
Bootanimation Support (/system/media/bootanimation.zip)
CIFS/TUN Support
XZ Compression and Decompression Used
PegasusQ and Adaptive Governer along with other stock Governers
Readahead size set according to disk size
Many lowmemorykiller Tweaks
CFS Autogroup
SLUB Memory Allocator with slight improvements
Some mm Parameters Tweaked
Used memcopy macros and functions
Used Makefile Optimizations!
Disabled GENTLE_FAIR_SLEEPERS
Overclock upto 1.8Ghz (Thnx to AndreiLux)
Undervolt, and UV_mV_table support (Thnx to AndreiLux)
Added Simple IO Scheduler
Triangle Away Compatible Kernel.
CFS Parameters tuned for best performance
Refer to my github and changelogs for more details!
Known issues-
WIFI
Mounting of external SD-CARD
-----------------------------------------
Perseus [OC/UV][WIP]
Features:
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
-----------------------------------------
SiyahKernel S3-v1.0
Features:
CPU over/underclock: 100-1800MHz 18-steps
CPU underclock (600mV-1500mV). vdd_levels and UV_mV interfaces.
GPU undervolting/overclocking (40MHz-800MHz)
Insecure adb even though we have ro.secure=1
optional smooth_scaling for those who wants to limit fast scaling of governors (such as ondemand)
triangle-away app support
added hotplug governor and modified it to support quad-core
Auto-root. You can also remove root via ExTweaks app and install it without rebooting your phone again. Auto-root can be disabled as well.
You can completely disable android logger using ExTweaks app
Adjustable charging speeds for AC and USB
Cpu governor optimizations
Gpu voltage, clock and stepcount interfaces in ExTweaks
governor-aware stand-hotplug for old conventional governors
Available CPU Governors: Pegasusq (default), Hotplug, Ondemand, Lulzactive, Conservative, Performance, Userspace, Powersave
CIFS as module
Available I/O schedulers: CFQ (default), noop, Deadline, SIO, V(R)
init.d support
ARM topology support (SCHED_MC)
default idle mode is IDLE+LPA (highly recommended). however you can change the default to AFTR+LPA using ExTweaks.
Automatic EFS Backup
Samsung proprietary ExFat modules are loaded
Lots of I/O tweaks and filesystem optimizations via some parts of thunderbolt scripts.
NTFS automounting for USB sticks. When you plug in an NTFS formatted USB flash it will be automatically mounted to /mnt/ntfs folder.
Almost everything is configurable such as scheduler features, hotplug thresholds, GPU frequencies, voltages, arm topology modes... and they are configurable via simple and free ExTweaks App from Google Play
mDNIe negative effect toggle with home button (press it four times). the purpose of this feature is to inverse the colors especially when the background is white or bright. making the background darker will make your battery last longer.
and some more not worth mentioning as separate items such as disabling mali state tracking and disabling some unnecessary debugging etc...
-----------------------------------------
Abyss S3 kernel 1.0 Final Stable Version by Angelom
Full Changelog Abyss S3 kernel 1.0 Final:
- Based on Update 1 Samsung Sources, with update up to 3.0.33 patches
- CPU overclocking & undervolting (50MHz-1704MHz 18-steps, UV_mV, UV_UV and vdd_levels interfaces)
- Added and enabled smooth scaling for battery life
- Added and enabled frequency regulation based on screen on/off events
- Added selectable ASV Table (form 0 to 11), set to 4 as default
- Added adjustable vibrator levels
- Added BFQ, v(r) and sio I/O schedulers
- Set v(r) i/o scheduler on boot
- Selectable idle mode (AFTR as default)
- Selectable Sched_MC power-saving (off as default)
- triangleaway support
- GPU undervolting & overclocking (600mV-1200mV, 40MHz-800MHz)
- Added Abyssplug, lulzactive v2, lazy, interactive, smartass v2, intellidemand, lagfree governor
- autorooting
- Auto backup EFS
- Added and Enabled CGROUP_TIMER_SLACK
- sched-features: enabled HRTICK, disabled GENTLE FAIR SLEEPERS
- Added and enabled Joe's RCU
- Added SLQB Allocator
- mali: disabled STATE_TRACKING
- Added and enabled sync & sw_sync frameworks
- slicing-by-8 algorithm for crc32 and crc32c
- Introduce some memory copy macros and functions.
- Added ext4 tweaks
- Added Support for Multi-Core interface (Thanks Simone201)
- Added NTFS module and CIFS module
- init.d support
- Added Abyss Logo
- Added New S90uvabyss and S90ASVabyss script
- Other functions of Abyss kernel for GS2
-----------------------------------------
franco.Kernel r1
Features: will be edited
-----------------------------------------
Hacre's Kernel
Features:
Inc...
-----------------------------------------
plz post some experience for them.
greets
F1tty

Isn't this why we have the dev section?
Sent from my GT-I9300 using XDA

yes but not all are listed here ...you should know.

we already have a thread for this:
http://forum.xda-developers.com/showthread.php?t=1674286

Darkside Agent said:
we already have a thread for this:
http://forum.xda-developers.com/showthread.php?t=1674286
Click to expand...
Click to collapse
i never look into generall if i search for custom stuff...btw there are only xda´s threads i can easily find my self here...and in my thread can be talket about kernel and own experience...whats wrong on it ? i didnt like such big threads with all stuff in it and i believe most of users too.
best regards

Moved to general, please read this thread for more information about what belongs in each section.

Siyah is my Favorite atm!
Fast, stabile & smooth
Gesendet von meinem GT-I9300

Added Franco kernel :thumbup:
Runs like a hunted bunny^^
Gesendet von meinem GT-I9300

exfat support is in v0.94b (the OP is a little outdated for siyahkernel).
since I have no thread, I will answer the questions that I receive via PMs here for this time: I need some more testing and also some more things to implement/fix before releasing v1.0. I have very limited time to work on the kernel in this week. so, don't expect v1.0 anytime soon.

.
gokhanmoral said:
exfat support is in v0.94b (the OP is a little outdated for siyahkernel).
since I have no thread, I will answer the questions that I receive via PMs here for this time: I need some more testing and also some more things to implement/fix before releasing v1.0. I have very limited time to work on the kernel in this week. so, don't expect v1.0 anytime soon.
Click to expand...
Click to collapse
thanks for 0.94....device is stable and seems to have lower temperature in standby...little cooling my hands

Init.d folder
gokhanmoral said:
exfat support is in v0.94b (the OP is a little outdated for siyahkernel).
since I have no thread, I will answer the questions that I receive via PMs here for this time: I need some more testing and also some more things to implement/fix before releasing v1.0. I have very limited time to work on the kernel in this week. so, don't expect v1.0 anytime soon.
Click to expand...
Click to collapse
Hi there,
Thanks for your work and finally I installed it due it supports EXfat format SD Card. I have a nood question, does your kernel normally has init.d folder?
Thanks.
Edit: My Quadrant score decreases from 5611 down to 3507 after using Siyah kernel 0.94b using 1400mhz ondemond.

will try that new siyah

[Q]Cpu Governors / IO Schedulers question

ive been seeing this kernels with lots of CPU governors and stuff.. but i just wanted to ask do i really need a CPU control app like no-frills or SETCPU to use or switch between these governors? or android does this automatically?

You need no frills cpu to set cpu govenors
android will automatically scale up and down between the min and max frequency you set depending on the govenors settings
ie performance govenor will keep frequency at max higher boosting phone performance but at a cost of draining the battery alot quicker
full list of governors and what they do can be found by searching

[Unofficial] Boeffla Kernel Profile Sharing Thread

Boeffla Kernel App Profile Sharing Thread​
In this Thread you can share your Profiles based on the Awesome Boeffla Kernel​Official Boeffla Kernel Thread by Lord Boeffla -> here​#Downloads:
- [Official] CM11s/CM11/CM12 Builds by Lord Boeffla -> here
- Linaro(l474)/Sabermod(sm484) Builds by ZaneZam -> here
more information about the Linaro/Sabermod builds here
- Boeffla Config App -> here
#How to Activate the Profile:
- download .bcprofile
- put it into /data/media/0/boeffla-kernel-data
- activate profile through Boeffla Config V2
- open Boeffla Config V2, tap on DEFAULT, then LOAD FOREIGN, choose downloaded profile, activate it in the list (it should be blue)
You can post your Profile with some information about it and I will add it in post #2
Now we can start sharing profiles and discuss about it!
Have a lot of Fun
If you like to read more about Battery saving tips/performance tips/Governors/IO Scheduler -> here
Boeffla Kernel FAQ -> here​

Profiles​
ZZMove Basic Profiles in one Package: Package Info & Download
==========================================
@P1nGu1n_ Profile
- P1nGu1n_ Profile
==========================================
@PhrAok
- PhrAok Normal and Gaming Profile
==========================================
@S1ay3r666 Profile
- Slayer_Normal_OPO Profile
==========================================
@raybit10 Pofile
- raybit10 Battery Profile
==========================================
@real_pac Profile
- real_pac
==========================================
@BlakeSm Profile
- BlakeSM
==========================================
@ZaneZam Profile
- Information about the Profile -> here
- ZaneZam Profile
==========================================
@rlsroufe Profile
- rlsroufe Battery Profile
==========================================
 @Clark789 Profile
- Clark789´s Profile
==========================================
KCAL COLOR PROFILE Amoled Style:
Colors: 255,255,255
Saturation: 285
Hue: 0
Display: 255
Contrast: 264
Gamma: 0

reserved #2

Slayer_Normal_OPO for CM12
The first profile I like to share allows smooth scrolling and normal Gaming without lags for CM12,
while being Battery friendly:
- SmartMax
- Stock Cpu Speed
- I/O: Deadline 512
- CPU Tweaks: Aggressive
Download: Slayer_Normal_OPO

Good idea. Hopefully people will explain their choices too so we can understand and learn not just copy.

What I use is a balance between performance and battery life. If you have such a powerful device you don't want it to lag just so you have an extra 30 mins screen of time...
My settings give you a stable and fluid experience while saving you some juice. On average I have 5-6 hours screen-on time and 2 days in stand-by with wifi always on and using 4g.
What I use most of the time running CM11s:
Governor: zzmoove - optimal
Scheduler: zen
Hutplug profile: optimized
Touch boost frequncy: 1190 MHz
AC charge current: 1800 mA
The rest is stock.
Have not experimented with GPU yet, curious about everyone elses findings
Download link: P1nGu1n.bcprofile

P1nGu1n_ said:
What I use most of the time:
Governor: zzmoove - optimal
Scheduler: zen
Hutplug profile: optimized
Touch boost frequncy: 1190 MHz
AC charge current: 1800 mA
The rest is stock.
Have not experimented with GPU yet, curious about everyone elses findings
Click to expand...
Click to collapse
Do you like to upload your profile to a hoster?
Then i will add it to second post ?

My Config:-
Governor - zzmoove - optimal
I/O Scheduler - zen
Readahead - 1536
CPU Min - 268MHz
CPU Max - 2457 MHz
GPU -27MHz
Hotplug - zzmoove
Multicore Powersaving - ON
Boeffla Sound - ON
Head phones - +2
Speakers - -2
A/C Current - ON /w 1500mAh
Swappiness - 10%
Touch Boost -1267Mhz
LED Tweaks - ON (6 & 85 respectively)

ViditM14 said:
My Config:-
Governor - zzsmoove - optimal
I/O Scheduler - zen
Readahead - 1536
CPU Min - 268MHz
CPU Max - 2457 MHz
GPU -27MHz
Hotplug - zzsmoove
Multicore Powersaving - ON
Boeffla Sound - ON
Head phones - +2
Speakers - -2
A/C Current - ON /w 1500mAh
Swappiness - 10%
Touch Boost -1267Mhz
LED Tweaks - ON (85 & 6 respectively)
Click to expand...
Click to collapse
Same for you export you profile in a file and upload it. Then i will add it to the second post.
And you can post some Screenshots with your sot.
Cheers Slayer

S1ay3r666 said:
Do you like to upload your profile to a hoster?
Then i will add it to second post
Click to expand...
Click to collapse
Done, I edited my post. Could you link to my post instead of directly to the download link of my profile? It has an explanation and this way I could update my profile without the OP needed to be updated.
S1ay3r666 said:
Same for you export you profile in a file and upload it. Then i will add it to the second post.
And you can post some Screenshots with your sot.
Cheers Slayer
Click to expand...
Click to collapse
I am against screenshots. People will probably post the best result they ever got and brag about it, which is not that interesting. Battery life depends on many factors, like wifi and 2g/3g/4g/no data and your reception of both, if you've gamed and your number of apps. I'd rather have everyone posting their average screen-on and stand-by time with a context. For example: on average 5-6 hours screen on time, 2 days of stand-by time with wifi always on and using 4g.

The first profile is the one I use most of the time. Stable and battery saver, is my good compromise between fast response, with undervolting and underclocking. The second I use for gaming, it automatically activates with Tasker. I can not share my file to avoid the obvious problems related to undervolting because we have different grades of cpu.
First "normal" :
Governor: zzmoove
Governor profile: zzmoove - Optimal
Scheduler: fiops
Readahead buffer: 2048
CPU freq max: 1497mhz
CPU freq min: 268 mhz
Hotplug profile: zzmoove native 2 cores min (kernel v2.2 beta 1)
Multicore powersave: Off
UV profile: -100mv THIS THREAD
GPU governor: powersave
Touch boost frequency: off
Miscellaneous
System tweaks: Boeffla tweaks
Second "gaming" :
same as "normal" but with
CPU freq max: 1958 mhz
Governor profile: zzmoove - game
Miscellaneous
Touch boost frequency: 1497 mhz
System tweaks: Speedmod tweaks
General configuration:
Screen on time 9 hours (best)
2 days complete (light use) - Wifi and 4G are activate when screen is activate with task to periodically sync
All android animations are off
ROM: CM11 CARBON ROM with Boeffla kernel 2.2-beta1

P1nGu1n_ said:
I am against screenshots. People will probably post the best result they ever got and brag about it, which is not that interesting. Battery life depends on many factors, like wifi and 2g/3g/4g/no data and your reception of both, if you've gamed and your number of apps. I'd rather have everyone posting their average screen-on and stand-by time with a context. For example: on average 5-6 hours screen on time, 2 days of stand-by time with wifi always on and using 4g.
Click to expand...
Click to collapse
I tend to agree. We want useful posts, not bragging.
How many times do you see screenshots with massive SOT and no apps usage.

P1nGu1n_ said:
Done, I edited my post. Could you link to my post instead of directly to the download link of my profile? It has an explanation and this way I could update my profile without the OP needed to be updated.
I am against screenshots. People will probably post the best result they ever got and brag about it, which is not that interesting. Battery life depends on many factors, like wifi and 2g/3g/4g/no data and your reception of both, if you've gamed and your number of apps. I'd rather have everyone posting their average screen-on and stand-by time with a context. For example: on average 5-6 hours screen on time, 2 days of stand-by time with wifi always on and using 4g.
Click to expand...
Click to collapse
Just Perfect thats the way we go!
Will always link the post with the Description and pls include a Download link!
Cheers Slayer

PhrAok said:
The first profile is the one I use most of the time. Stable and battery saver, is my good compromise between fast response, with undervolting and underclocking. The second I use for gaming, it automatically activates with Tasker. I can not share my file to avoid the obvious problems related to undervolting because we have different grades of cpu.
First "normal" :
Governor: zzmoove
Governor profile: zzmoove - optimal
Scheduler: bfq
Readhead buffer: 2048
CPU freq max: 1497 mhz
CPU freq min: 268 mhz
Hotplug profile: zzmoove native hotplug
Multicore powersave: Off
UV profile: None with -115 mV for all entries !!! not to do if you don't know what you are doing !!
GPU governor: simple_ondemand
Miscellaneous
System tweaks: Boeffla tweaks
Second "gaming" :
same as normal but with
CPU freq max: 2457 mhz
Governor profile: zzmoove - game
UV profile: -100 mV for all entries !!! not to do if you don't know what you are doing !!
Miscellaneous
System tweaks: Speedmod tweaks
General configuration:
Screen on time 7 hours (best)
2 days complete - Wifi and 4G are activate when screen is activate with task to periodically sync
Click to expand...
Click to collapse
I will add it to second post, but can you say me for which type of rom (CM11s/Cm11/Cm12)?
So we will get a bit of structure.
Thanks

S1ay3r666 said:
I will add it to second post, but can you say me for which type of rom (CM11s/Cm11/Cm12)?
So we will get a bit of structure.
Thanks
Click to expand...
Click to collapse
sorry you are right, post edited.

PhrAok said:
sorry you are right, post edited.
Click to expand...
Click to collapse
Perfect! post #2 updated!

Zzmoove - yank
Zen
Max 1958
Readahead 1024
Light undervolt
Hot plug default
Gpu max 389
Touchboost off
Current stats
On battery : 1 day 14 hours - 40% left.
Screen on : 4hours 45minutes.
LTE only.
Trying this for everyday light use and haven't come across any hangups so far. Just flashed this kernel a couple days ago so this is my first run.

Hi guys, I just tried PhrAok's config, but I may did anything wrong because my phone freezed and rebooted after quitting boeffla app, and at each reboot.
I tried to wipe dalvik cache, flash my rom again and delete boeffla app, but still freezing after reflashing boeffla...
Anyone have an idea ?
Thanks in advance.

Tweetix said:
Hi guys, I just tried PhrAok's config, but I may did anything wrong because my phone freezed and rebooted after quitting boeffla app, and at each reboot.
I tried to wipe dalvik cache, flash my rom again and delete boeffla app, but still freezing after reflashing boeffla...
Anyone have an idea ?
Thanks in advance.
Click to expand...
Click to collapse
Instead embarrassing, for next time with kernel 2.0 beta 18 you can reset all settings due to a configuration problem with boeffla-config-reset.zip in boeffla-kernel-data folder, flash in recovery.
if you don't already done, maybe you should delete the boeffla-kernel-data folder that contains the profile that you had previously registered before reflashing boeffla kernel.

Thanks, it worked like a charm !
I did not knew that a reset file was on the phone, I looked on the web for a similar file that I had on my S3 (called ultimate kernel cleaning script), but I didn't find anything...
Thanks again !