Related
Spreadsheet of Governor Power Use
BENCHMARK DATA
Summary
Out of the five most popular governors (ondemand, conservative, smartassV2, lazy, and lulzactiveV2) which one can save the most battery?
Total power use is calculated from the mA drain at the frequency x the %age of time spent at that frequency. mA drain figures available here.
Best Power Saving Governors
Best for Screen ON: Ondemand
Best Screen ON + performance: SmartassV2
- Good choice if you need a performance governor with some power saving
- SmartassV2 is also the winner of the governor benchmark: here.
What about when my Screen is OFF?
Best Governor for Screen OFF
Without Deep Idle: Same as Screen ON > Ondemand
With Deep Idle: Any governor...
...now it get's technical...
...Why 'any'? If you look at the spreadsheet, on average, with music ON and the screen OFF, the difference between the best (smartassV2) and worst drain (lazy) is 0.05mA (a tiny amount). Harrb already did a 10 hour test to establish how much each governor drains the battery while using deep idle:
Harbb's spreadsheet
Here's two of Harbb's results (phone's own stats for battery drain with matr1x):
- 23% - Lazy with DI
- 15% - SmartassV2 with DI (35% more efficient)
And my results (mA drain using matr1x):
- 0.30mA - Lazy with DI
- 0.24mA - SmartassV2 with DI (20% more efficient)
Harbb's result is the most reliable, as my original battery drain mA readings were all somewhat approximated due to the difficulties of reading accurately off a small scale on the analogue amp meter, especially when the scale is logarithmic and the mA drain is in the lower register. This means, if I assume my Smartass mA reading is correct, then my Lazy reading should be 0.405mA
While playing music, with the screen off, with DI enabled,
over a period of 1 hour:
a constant drain of 0.240mA = 864mA
a constant drain of 0.405mA = 1458mA
So choosing SmartassV2 over Lazy would prevent about 600mA being wasted in one hour. To put this in context, that is enough to power your screen for 3 seconds (assuming a drain of 200mA).
Since it will take about 3 seconds to change your governor, in practice, it would be a waste of effort to bother. Pick your preferred governor for screen ON, and don't worry about what happens while the screen is off (again, only if you have deep idle. If you don't, but want some power savings with the screen off, choose ondemand).
F.A.Q.
[Q] But Harbb's data clearly shows that the battery drain is much better under smartassV2. How can you say governor choice doesn't make a difference?
[A] Harbb's result is an 8% benefit over ten hours, so in one hour it's a 0.8% benefit. It's not a very practical amount.
For more battery saving tips, see my battery drain thread: here.
Where did the other benchmarks go?
Battery Drain Benchmarks: this thread
All ICS ROM Benchmarks: this thread
Kernel Features and Benchmarks: this thread
CPU Governors and I/O Schedulers: this thread
These tests were based on an the procedure first used by XDA user glennkaonang. Credit and thanks to Glenn. Thanks to r_data, mathkid95, steve.garon, and eugene373 for their kernels.
Conservative is not the Best
When the screen is ON, i.e. the phone is in active use. Generally Conservative does not save power. This is because most developers have included a tweaked version of conservative that keeps the frequency at its highest state for longer to improve the responsiveness.
There is one exception where conservative saves more power than other governors, and that is when the screen is off, music is on, deep idle is on, and this only applies specifically to Air Kernel. However, we are talking about a tiny amount of power (for more detail, see the first post.)
PLEASE NOTE: Steve Garon does not include deep idle, but is working on it, neither does Eugene, but I've asked him to consider it. For these two kernels, if you are listening to music with the screen off, currently, the best power saving governor is Ondemand.
Governor Parameters per Kernel
SG-NS-ICS (11th FEB TEST VERSION)
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 3 @400
Up sample time: 20000
Down sample time: 40000
MAT1X v17.0
-Conservative
Sampling Rate: 40000
Up Threshold: 80
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 768000
Sleep ideal freq: 245000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
ICUP SPEEDY-7
-Conservative
Sampling Rate: 39062
Up Threshold: 70
Down Threshold: 30
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 30000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 1
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2 (not settable in NSTools, checked /sys/devices/system/cpu/cpufreq/lulzactive/)
Inc CPU load: 90
Pump up step: 4
Pump down step: 1
Screen off min step: 6 @400
Up sample time: 10000
Down sample time: 40000
AIR KERNEL 3.0 (TEST VERSION)
-Conservative
Sampling Rate: 20000
Up Threshold: 60
Down Threshold: 20
Ignore Nice Load: 0
Freq Step: 5
Sampling down factor: 1
-Ondemand
Sampling Rate: 40000
Up Threshold: 95
Ignore Nice Load: 0 (settable in SetCPU)
Powersave Bias: 0
Sampling down factor: 10
-SmartassV2
Awake ideal freq: 800000
Sleep ideal freq: 100000
Sleep wakeup freq: 99999999
Min CPU load: 25
Max CPU load: 50
Ramp down step: 256000
Ramp up step: 256000
Down rate: 99000
Up rate: 48000
-LulzactiveV2
Inc CPU load: 60
Pump up step: 1
Pump down step: 1
Screen off min step: 5 @400
Up sample time: 20000
Down sample time: 40000
The I/O Scheduler Selections
I selected the likely/proven best I/O scheduler for each kernel and governor combination, based on my previous work here: http://goo.gl/iJXWI
-SG-NS-ICS and Matr1x
Conservative: cfq
Ondemand: noop
SmartassV2: noop
LulzactiveV2: deadline
Lazy: deadline
For these two it's a little different in places:
-ICUP Speedy-7
Conservative: cfq
Ondemand: deadline*
SmartassV2: deadline*
LulzactiveV2: cfq*
Lazy: deadline
-Air Kernel
Conservative: deadline*
Ondemand: noop
SmartassV2: sio*
LulzactiveV2: noop*
Lazy: deadline
I've emboldened and marked with an * where the differences are.
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
bedalus said:
UPDATE: Summary now includes more detail.
I was unable to complete the necessary details and caveats when I first opened the thread as I desperately needed sleep! Hopefully someone can check over my conclusions and make sure they all add up.
Click to expand...
Click to collapse
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Waiting for your feedback on this bedalus.
Bedalus is loving benchmarking too much that sometimes, he tries to benchmark his benchmarks
tchaari said:
Awesome Benchmark again bedalus. Very instructive
I would add these points to the conclusions:
- There is a big difference in governors power consumption when screen is on (more than 10 mA between the best and the worst against a small 0.05 mA difference when screen is off)
- Conservative is the worst governor for screen on usage according to the benchmarks (Taking this point with reserves because conservative was tweaked by kernel developers).
- If we have a high "screen on" usage, onDemand will save us so much power
- If we have a low "screen on" usage, it should be better using SmartassV2 and have the best performance for the little time we use the phone
Click to expand...
Click to collapse
0.05mA difference: good point. I should probably mention that in the OP.
Yeah, conservative sucked pretty badly on all four of the kernels. Weird.
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
EDIT: Just noticed your benchmark benchmark idea. Only if I am not sleeping.
bedalus said:
0.05mA difference: good point. I should probably mention that in the OP.
Click to expand...
Click to collapse
If you found that the last two points are useful, can you also integrate them in the OP too?
bedalus said:
Yeah, conservative sucked pretty badly on all four of the kernels. Weird
Click to expand...
Click to collapse
Yes it was a surprise to me too but when joining your benchmark results and the theoretical basics of conservative, it all makes sense. Conservative is taking too much time to compute a task (scaling up slowly). It also scales down too slowly when finishing. This is noticeable especially in discontinued use like browsing.
bedalus said:
For me, all I do now is use my phone to check XDA, and I don't use it with the screen off, so I can save power with ondemand. But smartassV2 is provides a very smooth experience. What do I want more? Battery life or smoothness? Hmm... decisions, decisions...
Click to expand...
Click to collapse
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
kernels ; battery ; ROM ; gov/sched
bedalus said:
Yeah, testing ondemand now, back on slim ics, feels the same as smartass.
I'll look at the OP tomorrow, early night for me today.
Click to expand...
Click to collapse
I hope you will sleep smoothly now that this benchmark is finished
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
nice work.. AGAIN
so this explains why im happiest with ondemand.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
You could visit bedalus' other benchmark thread http://forum.xda-developers.com/showthread.php?t=1478418&page=1 and see which fits your taste best.
Anyway, great job on this new benchmark thread, bedalus.
I can't believe that you would actually go further on this.
Looking at your results, the best for me would be ondemand.
I rarely used my phone, only for messaging and XDA-ing , so most of the time the screen is off.
And as tchaari said, I couldn't see any difference between ondemand and smartassV2 in terms of performance.
Once again, thanks bedalus
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
AeroEchelon said:
Frankly, I thought everything that could be benchmarked already was. However, this data proves even more useful! Thanks, bedalus.
Now there is nothing left to tweak on my phone!
Click to expand...
Click to collapse
There is ALWAYS more to tweak on our phones
Good work bedalus, your lack of sleep truly amazes me. I think we can enhance this a bit more by messing around a little with modified conservatives though. It shouldn't be very difficult at all to scale it down far quicker. I'm doing a couple of usage tests with various conservative settings and will let you know if i get any setups that may fit the bill.
As we know, conservative can easily give better performance than ondemand if told to, but i reckon we can get the best of both worlds. Does anyone know where i'd be looking to find the defaults of each governor in the kernel source? Saves me kernel crackflashing.
deetailed said:
Can you indicate what schedulers you use for each of the governors? In my experience schedulers also have an effect to battery life so it'd be good to see whether they're the same or different.
Click to expand...
Click to collapse
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
simms22 said:
nice work.. AGAIN
so this explains why im happiest with ondemand.
Click to expand...
Click to collapse
Does morfic tweak on demand, I can't remember, I think I read it somewhere... ?
For completeness, and to save Harbb from becoming an emaciated crackflasher like us, I might just go through all the governers for each kernel I tested and note their settings down in the third post.
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
I think he was asking which scheduler you used with this benchmark. I'd bet it's deadline.
edit: bedalus, at least give me a couple of kernels to do and i'll note them down. You've had enough fun
bedalus said:
To save me trying to copy and paste on my phone this early on the morning, just follow the link below to gov/sched and you'll see a summary in the first post about which scheduler goes best with which governor, e.g. ondemand and noop.
kernels ; battery ; ROM ; gov/sched
Click to expand...
Click to collapse
Ah, I don't mean to ask what scheduler is recommended for each governor (because I've already got that info from your gov/sched thread ). Like Harbb said, I'm just asking that the specific scheduler used in this battery-saving benchmark is mentioned, whether you use the recommended for each or use the same scheduler for all of them (also I'm a she, not he ). Every phone is different and usage habits vary too, so I like to replicate the setup of benchmark winners to see if what you find best is best for me too.
My apologies deetailed. At least i got something right
As i said before, it is most likely deadline that was used since it has very uniform capabilities with each governor. Clarification would definitely be nice though, lack of sleep can do weird things.
tchaari said:
I don't think that you can "feel" the performance difference between ondemand and smartassV2 in such tasks. it should be better to stick to ondemand in this case I think
Click to expand...
Click to collapse
After repeatedly flashing all the kernels, ROMs, and trying all the governor / scheduler combinations that are possible, I've become attuned to the device. For some people they may 'feel' the difference intuitively, others might imagine a difference. But for me, I've had over ten years of practice in timing tiny fractions of a second, all thanks to sound engineering. For example, I used to add Haas delays to close mic'ed instruments to simulate 'early reflections', giving the psychoacoustic impression of greater depth and imagining to these instruments in the mix. These delays are anywhere from 5ms to 40ms.
For me, smartassV2 will always go from input on the touchscreen to an animated transition virtually instantaneously, but with ondemand, if you are coming from an idle state, there is always a little delay. It's tiny, maybe 100ms, but for a sound engineer, 100ms is a huge gulf.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ultimate battery guide
Battery, one of the most important thing on todays phones. Even if we have awesome battery life we always want more and it is never enough.
This is the small guide to tips, trick and tweaks to improve battery life.
This topic is to share tips and tricks and basically just small talk about battery and sharing screenshots.
Use Gsam or Android battery history to show your battery life.
Our goal is to make most of the screen on time with average use of 24 hours. So lets start.
Post 1: Tips
Post 2: ROMS, kernels, undervolting, underclocking
Tips to improve battery life
Location services
One of the first thing that your device will ask when you are setting up your phone. Most of the users let them ON and just forgot about them. Location services are battery hungry and the will drain your battery like you drinking juice.
Thing is that you do not need them always, just sometimes. Turn it OFF then. I have them turned off always and when I need it I just simple turn it ON.
Wi-Fi
Wi-Fi scanning is thing that will drain your battery always. When you are out and you are not expecting to use wi-fi any time soon turn it off. You do not need to run scanning all the time.
You could also edit build.prop to reduce.
Edit wifi.supplicant_scan_interval. Default value is 180. You can set it higher to reduce the scanning intervals.
Signal strength / Network mode
Signal strength is always trouble for battery. Weak signal will drain more battery. Also, constant changing between 4G/3G and 2G will drain battery faster.
Tweak to this is to set your phone to only use 2G, 3G or 4G.
Example: when I am not using my phone, or it is connected to wifi my network is on 2G. I dont need 3G or 4G then and changing network state is disabled then because it will stay always on 2G. I found it has positive effect on battery.
When I need, I just simple toggle 3G or 4G.
Screen brightness
Screen is the thing that drains most of our battery. There is not much philosophy here. Higher brightness will drain more battery.
My personal setup is that I do not use auto brightness. I always change brightness manually. Right now during winter my brightness does not go more then 25% outside, and inside it is lower. At night it is under 10%.
I found that not using auto brightness has also slight positive effect on battery.
Syncing / Airplane mode / Vibration / Animations / Task Killers
Lets start in order.
Syncing: more syncing your device does it drains more battery. On your phone probably you do not to sync all accounts and apps you have every few minutes or hours. Set those apps you do not need on manual sync.
Airplane mode: I am using airplane mode during night because I do not want to be disturbed during sleep. With airplane mode battery consumption during night is 0%. Yes, zero percent.
Vibration: more your device vibrates, more battery it drains. You can reduce vibrations on keyboard settings and similar. I found that is not much effect on battery but it has slight.
Animations: animations drains your battery also and who really needs them. Personally, I am annoyed with them and I always switch them to 0 or .5. You can do that in Settings-Developers options
Task Killers: task killers, clean maters and similar software is a big NO. You dont need it. It does more damage then good.
Bloatware
Yes, bloatware. There is huge amount of bloatware on our phones and we really do not need it. So, what to do? Freeze that bloatware.
You can find list of apps HERE. There is also available tool for auto disable, ImproveG3
ROMS and kernels
Custom ROMs and kernels will give you in most cases better battery life then stock firmware. Plus there is huge amount of options to play with. You can read more in posts bellow.
Summary:
If you change some of those thing you will see the effect.
You can always use apps like Greenify or Tasker and play with their options.
How to follow your battery life
GSam Battery Monitor
This one of the most useful apps to track your battery. On Lollipop (even on Kitkat) it will not give you much useful info without root.
If you are using it without root everytime you reboot the phone statistic would be reset also. If you have root it will give you access to wakelocks and some other stuff, plus stats would not get reseted.
Play store link
Wakelock detector
Wakelocks, one of the painful things on phone. If you see your battery is draining faster in idle then you got problem with wakelocks. This is useful app because it shows wakelocks on very simple setup and you can discover which app is causing which wakelock.
Play Store link
Disable service
If you are using Wakelock detector you need this app also. With this app you can freeze every single process that app can launch. It will provide detail look on all processes from apps. With this app I have reduced wakelocks to 1%.
Play Store link
ROMS
Discussion about ROMs never looked nice. It always gets to what you personally like. Some ROMs will be easier on battery, some will be rough. You will never know before you try them.
Kernels
Kernels are similar to ROMS but you can play with them. Currently there is not much kernels available but you can play even with stock one.
I recommend to use Trickster MOD Kernel Settings app to play with kernel settings.
Undervoting
Undervolting is the thing when you control how much power each CPU frequency can have. Trickster MOD app gives really nice view on them. You can undervolt every frequency by itself or all in one.
My personal recommendation is to undervolt them at once. I always use -50 value. Found it stable.
Of course, you can always play with different values but remember: when you play with this do not click on option "Set on Boot" or you will end in bootloop if you click it. Click that option when you find out that values are safe for using and stable.
Underclocking
Underclocking is changing your CPU frequency. Rough truth is that we dont need our CPU to run on 2,7 GHz in normal use. Only gamers will need that probably but since this is not thread were we are aiming gamers we dont need that high frequency.
Me personally, I use always 1,7 GHz or 1,9 GHz. To my daily usage (most common like everyone else but without games) this is more then enough. Everything is still smooth and runs fast.
Governors
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
You can find explanation hidden here.
Many users have wrote about governors and they are practically the same on most of the phones so I will copy list from droidphile.
On his topic you have more details about governors.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
I) MANUAL:
These are the 19 governors we're talking about.
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
20) Wheatley
21) Smartmax
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
19) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
20) 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.
21) Smartmax
Its no benchmark or ultimate perfromance governor, its a proper balanced ondemand.
The basic idea - which comes from smartass - is the concept of an "ideal" frequency.
The following strategy is used:
1) If load is above upper-threshold and current frequency is below ideal freq
-> jump to ideal in one step
2) If load is above upper-threshold and current frequency is at or above ideal freq
->do "ramp up" steps which will include all frequencies for a specific
amount of time - so compared to ondemand no "jumping" to max frequency
3) if load is below lower-threshold and current frequency is below ideal freq
->do "ramp down" steps
4) if load is below lower-threshold and current frequency is above ideal freq
-> jump down to ideal in one step
All those thresholds ramp steps and frequency stepping times are
fully configurable using sysfs. By default I tried to create a good balance.
The ideal frequency for "us" is 475000 which is the maximal frequency
of the LP mode of the tegra chip. This will allow using LP mode as much as possible
Additional to make it "snappy" smartmax has "touch poke"
So input events from the touchscreen will boost the cpu for a specific
time to a specific frequency.
Schedulers
Everything has been said about them so I will use droidphile explanations.
Link to original topic: http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
I/O Schedulers
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
reserved
Lets talk and share tips
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Ok so the best setting for governors and I/O control battery life and perfomance
veekay said:
Do you have a preference for governor and I/O? I'm coming from a rather old phone that didn't have most of these options. I think I've been using interactive and zen, which apparently wasn't even listed.
Click to expand...
Click to collapse
I am using SmartassV2 and noop.
TIP
For those who most of the day stay indoors and don't need a very bright screen like me, may install this xposed module, Minimum Brightness.
With this you can lower the minimum brightness of the screen beyond the usual value. It aids in saving quite some juice. :good:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Saratoga79 said:
Nice thread my frind!
I'm using this settings on Cloudy Rom and Rin Kernel:
GOV: Intellidemand 300/1,9 GHz
I/O: 4096/vr
MP off
Intelliplug on
GPU: simple_ondemand 578 MHz
UV MPU:
300 MHz = 675 mV
422 = 700
652 = 725
729 = 730
883 = 750
960 = 760
1036 = 770
1190 = 790
1267 = 800
1497 = 830
1574 = 840
1728 = 870
1804 = 885
1958 = 915
2112 = 945
2188 = 960
2342 = 990
2457 = 1010
2534 = 1025
2611 = 1040
2688 = 1055
2764 MHz = 1070 mV
Still testng as this is my second week with the device.
Click to expand...
Click to collapse
Nice setup.
On first look it looks like stable setup.
DelBoy said:
Nice setup.
On first look it looks like stable setup.
Click to expand...
Click to collapse
Thanks buddy!
Yes it is pretty stable with no reboots or feezes. Also perfomance seems to be good enought and I haven't notice any lag.
This is my todays battery.
22% left. Used 75% with 19 hours on battery and SOT 5 hours for now.
During this 19 hours airplane mode was ON for like 6 hours during the night.
Results can get better. This is on V20A. I believe V20D will get me better results.
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
Early to judge, but it is the same I believe. Not much difference.
Updated post with few more governors
Very nice one
Would you mind adding a link to ImproveG3 to the "Bloatware" section?
Oh and I didn't change much cpu wise, just Amplify'ed Wakelocks RILK, NlpWakeLock and NlpCollectorWakeLock, device remains at 100% during night (~7-8 hours) without using airplane or turning off data/wifi/syncing
Don't have extremely many apps installed though, and set syncing intervals that make sense, depending on app/account.
Thank you very much.
Regards,
sub
@subworx - added
How can I use those governors I have Stweaks but can't find it there
Saratoga79 said:
Wow! Really nice stats!!!
Do you have better battery on 5.0 or 4.4.2? I'm still on 4.4.2 but looking forward to jump to 5.0.
Click to expand...
Click to collapse
For me 4.4.2 has a lot better battery life
AAA118 said:
How can I use those governors I have Stweaks but can't find it there
Click to expand...
Click to collapse
You need to have custom kernel that has that governors (Rin kernel, or ChupaChups).
After that use TricksterMod or CPUcontrol to change governors.
S2 custom kernel tuning thread
Updated: 22/10/15
Welcome to my universal tuning guide for the Samsung Galaxy S2 i9100. This guide will cover different profiles I've created to meet every single situation, whether you want to save more battery life or to have more gaming performance.
Here is a following list of kernels that this thread will apply to:
- DorimanX kernel
- Apolo kernel
- Gustavo kernel
- DU kernel by Arnab
- Other kernels with variable changing support with underclocking and overclocking support
Guides:
- General Profiles
- Special Profiles
- Kernel Specific Profiles
List of things to do:
- Down threshold tuning
Changelog:
Code:
[B]24/10/15:
v1.1 [/B]
- updated most profile settings
- Added sampling rate tuning
[B]22/10/15:
v1 [/B]
- initial thread bring up[/SIZE]
General Profiles
These profiles will suit most devices and are generally used by most people with custom kernels. Of course, settings here are found on all custom kernels listed in the OP.
Please also be mindful that some governors behave better on certain kernels than others. Here is a list of governors that are known to work well on the following kernels:
- DorimanX kernel -> HYPER
- Apolo kernel -> PegasusQ
- Gustavo kernel -> PegasusQ (I think most governors work fine anyway)
Normal use/Default
Max CPU frequency: 1200mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/PegasusQ
Sampling rate: 50000
Up threshold: 85 or 75
IO scheduler: SIO/CFQ/ROW
Performance
Max CPU frequency: 1200
Min CPU frequency: 200
CPU governor: HYPER/NeoX/PegasusQ
Sampling rate: 50000
Up threshold: 60
IO scheduler: SIO/ROW/ZEN
Even more performance!!!
Max CPU frequency: 1300mhz (Personally, I don't recommend 1600mhz because it can be unstable, 1300mhz or 1400mhz should be fine on most devices)
Min CPU frequency: 200mhz or higher (Don't set this too high, personally, I think anything below 500mhz is still capable of good performance)
CPU governor: HYPER/NeoX
Sampling rate: 30000
Up threshold: 50 or 60
IO scheduler: SIO/ROW/ZEN
Gaming
Max CPU frequency: 1200mhz
Min CPU frequency: 200mhz
CPU governor: HYPER/NeoX/PegasusQ
Sampling rate: 40000
Up threshold: 60 or 75
IO scheduler: SIO/ROW/ZEN
Battery life
Max CPU frequency: 1000mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/zzmoove
Sampling rate: 120000
Up threshold: 90
IO scheduler: SIO/noop
Even more battery life!!
Max CPU frequency: 800mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/zzmoove
Sampling rate: 120000
Up threshold: 90
IO scheduler: SIO/noop
Special Profiles
These profiles are for people who want the best settings for specific situations
Good gaming performance with less battery drain
Max CPU frequency: 1200mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/PegasusQ
Sampling rate: 80000
Up threshold: 80
IO scheduler: SIO/ROW
Good gaming performance with even less battery drain
Max CPU frequency: 1000mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/PegasusQ
Sampling rate: 80000
Up threshold: 80
IO scheduler: SIO/ROW
Minimum drain from watching videos
Max CPU frequency: 800-1000mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/PegasusQ/zzmoove
Sampling rate: 100000
Up threshold: 85
IO scheduler: SIO/ROW
Minimum drain from listening music
Max CPU frequency: 800-1000mhz
Min CPU frequency: 200mhz
CPU governor: Ondemand/PegasusQ/zzmoove
Sampling rate: 120000
Up threshold: 90
IO scheduler: SIO/ROW
Kernel specific Profiles
These profiles are for people who have custom kernels that have unique settings
gsstudios's dorimanx default profile
Max CPU frequency: 1200mhz
Min CPU frequency: 200mhz
CPU governor (AWAKE): HYPER
CPU governor (SLEEP): Ondemand
Awake Up threshold: 70
Sleep Up threshold: 75
IO scheduler (Awake and Sleep): SIO
TCP algorithm: Westwood
gsstudios's optimized apolo kernel profile
Max CPU frequency: 1200mhz
Min CPU frequency: 200mhz
CPU governor: PegasusQ
Up threshold: 75
IO scheduler: SIO
Any suggestions will be great so that our fellow S2 users can have the best custom kernel experience!
I also encourage sharing of your own profiles in this thread. Just stay on topic and all will be fine :good: :victory:
@gsstudios
http://forum.xda-developers.com/showthread.php?t=2432029
This thread should be in OP. I learned a bit from there , because i could take a profile , test it , adjust some valumes test (...) again again... and finally create STweaks profile , thay suits be best.
MikiGry said:
@gsstudios
http://forum.xda-developers.com/showthread.php?t=2432029
This thread should be in OP. I learned a bit from there , because i could take a profile , test it , adjust some valumes test (...) again again... and finally create STweaks profile , thay suits be best.
Click to expand...
Click to collapse
I will have to ask eskriminal to update the stweaks OP, but since we don't see him on XDA anymore, this may not happen.
Is there a chance someone will add back the 100MHz CPU step? Siyah had it and I think it helped save power in some situations, like when playing music.
Also, can someone recommend a widget to quickly change profiles? Voltage control was good but it doesn't seem to work anymore.
apphoarder said:
Is there a chance someone will add back the 100MHz CPU step? Siyah had it and I think it helped save power in some situations, like when playing music.
Also, can someone recommend a widget to quickly change profiles? Voltage control was good but it doesn't seem to work anymore.
Click to expand...
Click to collapse
What kernel are you using? Dorimanx kernel allows underclock to 100mhz, apolo kernel uses stock frequencies, Gustavo kernel also allows 100mhz (i think)
Edit: Gustavo kernel doesn't support 100mhz
gsstudios said:
What kernel are you using? Dorimanx kernel allows underclock to 100mhz, apolo kernel uses stock frequencies, Gustavo kernel also allows 100mhz (i think).
Click to expand...
Click to collapse
Using Gustavo_s kk kernel 04-02-TWRP-TRIM... 200mhz is minimum, according to Synapse. To be honest, I've had bad experience with Dorimanx kernels before (tried 5-6 versions, always buggy or horrible performance). I might give it another try, I see that you maintain it now. Thank you.
Now that we have root access and are able to make modifications to the interactive governor, I have worked through the same principles of the nexus 6p governor tweaks as they would be applied to the Pixel C X1.
Original Guide:
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
and extra help from @xSilas43 to further refine the settings
So the main differents between the qualcomm and nvidia are core count and cpu freq steps are different, so some options aren't available (touchboost etc) but the theory is still the same. The only thing missing now is a method to determine voltage of each cpu freq step so we can get better effective values.
So I went through and did all the maths based on the proper target loads and i think its optimised properly now with lower cpu values then before.
Important: set the min cpu speed to 102Mhz as seems that its set to 204 by default but perfectly fine to sit that low.
So based on my testing with stock given the recently discovered bug on stock
I don't recommended using these tweaks at present so please only use if you are on dirty unicorn or other asop build
V3.1 PixelBits testrev
target_loads - 8 102000:40 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
Previous Versions
V3.0 PixelBits
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:82 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.2 more refinements edition with help from @xSilas43
target_loads - 45 102000:45 204000:60 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:81 1020000:8 1122000:8 1224000:83 1326000:8 1428000:8 1530000:84 1632000:6 1734000:99 1836000:99 1912000:99
timer_slack - 50000
hispeed_freq - 204Mhz
timer_rate - 50000
above_hispeed_delay - 30000 408000:20000 612000:20000 816000:20000
go_hispeed_load - 99
min_sample_time - 80000
V2.0 Optimised for X1 (based on nomial loads with min and max thresholds based on target loads)
target_loads - 45 102000:45 204000:50 306000:68 408000:72 510000:20 612000:77 714000:14 816000:80 918000:11 1020000:10 1122000:9 1224000:83 1326000:8 1428000:84 1530000:7 1632000:85 1734000:6 1836000:86
timer_slack - 80000
hispeed_freq - 306Mhz
timer_rate - 40000
above_hispeed_delay - 30000 612000:20000 714000:20000
go_hispeed_load - 99
min_sample_time - 30000
V1.0 Lazy Values
target_loads - 75 408000:69 612000:80 714000:79 816000:80 918000:81 1020000:69 1326000:84 1632000:82 1836000:86
timer_slack - -1
hispeed_freq - 306Mhz
timer_rate - 20000
above_hispeed_delay - 30000 612000:20000 714000:10000
go_hispeed_load - 75
min_sample_time - 60000
Attached the latest profile for use with EX Kernel Manager for those that have it.
Place in Elemental X/gov_profiles and should appear in the app under gov options.
Please try out and let me know any feedback or issues with these settings, but everything should be stable as i have been running this for about 3 weeks now with no issues.
What other governors are available with the pixel kernel?
bill3508 said:
What other governors are available with the pixel kernel?
Click to expand...
Click to collapse
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
beardymcgee said:
Just the standard bunch: conservative, interactive, ondemand, userspace, powersave, and performance
Click to expand...
Click to collapse
Does the conservative governor have the touch boost option?
bill3508 said:
Does the conservative governor have the touch boost option?
Click to expand...
Click to collapse
nope nothing does
So no one interested in trying it?.....
beardymcgee said:
So no one interested in trying it?.....
Click to expand...
Click to collapse
Trying it now. Feels real snappy so far.
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
beardymcgee said:
Cheers for testing, Would you agree, that its running better then stock?
So far I've found it doesn't get hot on basic stuff anymore and no impact to performance, also ex manger has been saying 7% battery per hour which was 10% before tinkering
Click to expand...
Click to collapse
I definitely think so. Ive never really been a big fan of interactive but until the 5x and 6p threads no one has really modified the values like that. I still haven't messed with any of the scripts folks are running on those devices but I may play around with the numbers some. Seems to be working great on the C. Thanks again.
So based on my usage I got 3 days of use with 9.5 hours SOT and 10% to go, would love to hear from more people if this did anything.
I just charged up so I'll let you know at the end.
Cheers for helping out, its sad that people would rather complain about software issues that will be fixed soon, than do the normal xda custom thing.
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
beardymcgee said:
So i have updated the stepping to better match the x1 cpu in post #2.
as always feedback on this would be great, incase i made it too low for usecases beyond my own
Click to expand...
Click to collapse
I'll try the new values next charge up.
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
Root method has been fixed just don't flash su in twrp and follow the method in the twrp thread.
riro56 said:
I will try it when a safety root method will be release By the way, The X1 CPU owns 8 cores, why only 4 of them are activated ? Is there a way to activate both of 8 cores ?
Click to expand...
Click to collapse
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
beardymcgee said:
So based on the anandtech review seems that its only the a57 cores and the a53 cores are disabled but has stepping from 51mhz to 1912mhz. That said I don't think there is a need for the a53 cores as on the pure CPU performance space it benchmarks the same or better then snapdragon 810 with all 8 cores enabled
Click to expand...
Click to collapse
But I doubt we would have the throttling problems that the 810 does so I could only see it as beneficial. Also the smaller cored would likely only improve already stellar battery life using setups like we're seeing on the 6p.
so I been reading the original thread and came up with 2 paths.
one using the original basic tuned method to have a nominal target speed for different functions like web browsing and video playback etc and increase the focus on these speed steps only while minimising the time on others.
or based on what the current recommendation in the "easy way" say to just use max efficient loads on each step
but as I have been tinkering too much i cant tell any more which is better so I have created a poll so please try these 3 version and vote on which is better
So I wanted a different thread to make a list of different Power Profiles from users of my custom Kernel. My threads are usually pretty big so it gets hard to manage and this is also a safe place for me to post the defaults I'm using.
I'll review each profile and include your Power Profiles in the app if they seem to make sense.
Please follow the template below when posting. Keep off-topic, requests, etas and useless conversations out of here.
FrancoKernel defaults:
Low Power Cluster
Max CPU freq: 1440000
Min CPU freq: 384000
Governor: interactive
Governor parameters:
above_hispeed_delay 0
go_hispeed_load 100
hispeed_freq 0
target_loads 85 600000:45 787200:50 960000:60 1248000:80
timer_rate 20000
min_sample_time 60000
ignore_hispeed_on_notif 1
max_freq_hysteresis 80000
timer_slack 30000
Max Power Cluster
Max CPU freq: 1824000
Min CPU freq: 633600
Governor: interactive
Governor parameters:
above_hispeed_delay 20000 960000:40000 1248000:20000
go_hispeed_load 90
hispeed_freq 960000
target_loads 90 1248000:95
timer_rate 30000
min_sample_time 20000
ignore_hispeed_on_notif 1
max_freq_hysteresis 80000
timer_slack 30000
Input boost frequency
Low power cluster: 1248000
Performance cluster: 768000
Input boost duration
1500
Join the beta here http://beta.franciscofranco.xyz and starting with the next beta8 profiles will be included and be available to apply in a single tap.
FrancoKernel thread: http://n5x.franciscofranco.xyz
Saved to post profiles from users.
Saved to post profiles from users.
What's your opinion on these?
I'm using the Glassfish 1.2 profile since 2 days with your latest kernel, seems to be working great, cannot give an elaborate opinion yet though, obviously.
sigurd_LU said:
What's your opinion on these?
I'm using the Glassfish 1.2 profile since 2 days with your latest kernel, seems to be working great, cannot give an elaborate opinion yet though, obviously.
Click to expand...
Click to collapse
I think there's a lot overcomplication in all of those, but I'll include one or other because users like to play with 'em.