Related
As title says :
Which one is better for underclocking your processor ?
Im running on ROM and KErnel in my signature..
Thanks in advance
Laynee1
145 views with no replies lol..
To directly answer your question SetCPU is very user friendly and very basic, if your only changing the clock speed then sure, that's the way to go.
They both have their pros and cons. SetCPU has great profiles to setup for screen off, low battery, even certain times but limited and more tedious for changing voltages. The app in itself is well built, looks tidy and super user friendly. System tuner has all the same features but less custom profile options and in *my opinion* has an ugly interface. If you have the scripting for it, under volting is very easy on system tuner also.
I've used both very extensively and for how I have my phone setup system tuner is the best, hands down.
System Tuner suits all my needs. task manager, task freezer, task advanced details, cpu freq, voltage control and many other options. I have to admit the interface isnt really friendly, but you cand get used to it in no time.
System Tuner is better than SetCpu for advanced options
u can't undervolt the sensation with setcpu.. right?
Sent from my HTC Sensation XE with Beats Audio using xda premium
Laynee1 said:
As title says :
Which one is better for underclocking your processor ?
Im running on ROM and KErnel in my signature..
Thanks in advance
Laynee1
Click to expand...
Click to collapse
System Tuner Pro is, in my opinion, the best app for tuning CPU.
I am using IC 3.4 and all is ok.
As his question remains:
Which one is better for underclocking your processor ?
vitusdoom said:
As his question remains:
Which one is better for underclocking your processor ?
Click to expand...
Click to collapse
There is no difference between the apps if you consider JUST underclocking or overclocking ... If you take it like this, they are just mere interfaces to change some values ( which you can do by using let.s say root explorer and a text editor or a terminal emulator or etc. etc. )
System Tuner is better because it incorporates many other options, like task manager, app backup tool, uv tool, autokill features, ability to freeze apps and so on.
On the other hand, SetCPU has profiles, which can change the cpu values according to some predefined scenarios.
But, if the main question is which one is better for underclocking the answer is: whichever you like
+1 for System Tuner, the only thing missing from it that I do miss is
the profile settings that SetCPU has, fingers crossed the dev will
include it in a future update. Using System Tuner has also allowed me
to get rid of a couple of other apps that i used to sort out 'autostarts'
and a seperate terminal emulator.
snowblindd said:
There is no difference between the apps if you consider JUST underclocking or overclocking ... If you take it like this, they are just mere interfaces to change some values ( which you can do by using let.s say root explorer and a text editor or a terminal emulator or etc. etc. )
System Tuner is better because it incorporates many other options, like task manager, app backup tool, uv tool, autokill features, ability to freeze apps and so on.
On the other hand, SetCPU has profiles, which can change the cpu values according to some predefined scenarios.
But, if the main question is which one is better for underclocking the answer is: whichever you like
Click to expand...
Click to collapse
lol. you didn't get me. lets just say, he's asking for underclocking. but most of them are answering about undervolting
I prefere "echo" and manually init.d scripts
System Tuner 3.0
Just to let you know System Tuner 3.0 was released some time ago and provides improved CPU handling, new GPU, Gamma, MP, thermal controls on many custom kernels and a lot of other new or improved features (entropy, fstrim to name a few).
This is now a spawn of Android Tuner, and benefits from a larger user-base, improved stability and performance.
Given the recent hoopla in the blogosphere about how iOS places higher priority on User Interface actions than Android. I was wondering what ideas can be implemented in current Android or Linux kernels to get better UI response.
Overclocking or upgrading to a faster phone is the brute force way, a smarter way would be to give higher priority to user input instead of benchmark/multitasking score numbers. I think it makes sense to give the User input highest priority because in computation timeframes, user input is rare, and considering how important smoothness affects overall perception & enjoyment of a device, it's a good idea to allow other OS background tasks to take a backseat when the User wants to do something.
I'll start the discussion with two ideas I've implemented in a kernel recently that has shown improvements in UI response.
1. Switched to using SIO (Simple IO) scheduler (similar, but slightly lower benchmarks than Noop). Main difference is SIO prevents the system from hogging resources when large amounts of data needs to be read/written. It has a timeout so UI threads has a chance to run also.
2. Switched the touchscreen driver interrupt service request from using the general events workqueue (schedule_work()) to a dedicated workqueue (queue_work()). Touchscreen generated actions get to ride in the fast lane.
Any other ideas people have?
How bout some NSA IN THAT KERNEL
via Dan swagger
Usefull links, that clear things out:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html
the thing is i may be using a note but when using ICS with apps that are updated for ICS, i feel its smooth enough. the real difference is i think ios uses completely different method for scrolling i.e. the bounce function and slight delay in finger recognition. same with ios touch recognition, it just somehow is better no doubt.
btw when i was miui with bounce it definitely felt smoother but although it wasnt ios smooth.
Sent from my Galaxy Note using XDA App
The main difference between ios and android is the fact they use ram in two totally different ways. Ios handles ram in a manner to make the user interface smooth as possible all the time while android frees ram to make multitasking better. The problem that android has is changing the way android handles ram to make the interface smoother for the user. They wont be able to for a long time because they have to do a total overhaul on the whole dalvik cache type setup that android uses.
Sent from my Incredible 2 using Tapatalk
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
I liked the supercharger when I used the Droid Eris but since I've upgraded I get more redraws than without it. I used the 768hp I think.
Sent from my Incredible 2 using Tapatalk
you could edit the ramdisk to set more of a priority to rosie.apk or whatever launcher you use...just a thought
That would be the same as locking home in memory.
Sent from my Incredible 2 using Tapatalk
shad0wboss said:
i recently started using supercharger v6 which messes around with the ram and how it should be allocated for desired operations. I don't know if it's relevant but do you think it makes a difference and which setting would get you a better scrolling experience?
Click to expand...
Click to collapse
There are a number of issues that contribute to a "sluggish experience". The supercharger v6 script mainly keeps more memory free so that switching to new apps cuts down on the garbage cleanup of older apps. One of the downsides I've noticed with more aggressive lowmemkiller settings is a lot of apps get killed in the background when they need to stay for when users want to multitask.
The hardware acceleration route has downsides too from what I've heard, it requires more RAM per app just to have it enabled.
One of the articles posted earlier has good insight. Mainly because a lot of apps share a general events queue, and developers should not have a lot of blocking code in there, but developers make mistakes. The tools available for Android to develop and tweak UI performance seems lacking at this point.
How about SIGSTOPping everything else when you touch?
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to General
does it work with samsung i9000?
Supercharger?
Sent from my Sabotaged Droid Incredible 2.
I find that either turning off cpufreq (by using the Performance governor) or increasing the lower frequency makes things a bit more snappy. For most governors, there's a delay between CPU load and the frequency being increased. This delay is usually noticeable if the CPU load is due to me working with the interface. By increasing the min frequency to, say 800mhz on a Nexus S, this makes things a lot more snappy than the default setting of 200mhz.
Another thing that helps with the smoothness (at least for me, in ICS) is the setting that forces GPU acceleration for all apps. For example, apps these days (well twitter and Facebook) have that pull down to refresh widget from iOS. Without forcing GPU acceleration, the rotating arrow animation usually hitches quite a bit, but is smoothed out with this setting on. This setting can be found in the developer options in the settings.
Hope these help,
- chris
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
System tuner pro has alot of tweaking options that on memory use
those that use launcher pro can find a memory usage setting in launcher pro to.
disconnecktie said:
Turning up the min CPU can cause freezes on some peoples phone though and using the performance governor can drain the battery quick. The reason the CPU scales up the way it does before it gets to max frequency is to save battery.
Sent from my Sabotaged Droid Incredible 2.
Click to expand...
Click to collapse
Agreed, but the whole point here was to help improve UI responsiveness. Without rearchitecting the OS, a good way is to allow the CPU (which is busy sharing its resources with non-UI work) to react more quickly is to ensure the CPU is at a higher clock rate before the UI needs it.
As for battery life, it really depends on your usage pattern. If you have a lot of background processing going on, preventing the CPU from going to sleep when idle, you may be better off scaling back the minimum cpufreq frequently. If your CPU actually goes to sleep, give scaling things up a try. A handy tool you can use to see how often the CPU is sleeping is CPU Spy. To see which apps are keeping the CPU awake, there's a program called Better Battery Stats available on XDA and market.
As for stability, I don't mean over clocking the CPU...all I'm suggesting is to increase the frequency the CPU goes to when the screen is on, but nothing much is happening. This should still keep things within safe limits.
Hope this helps,
- chris
I find the interactive governor does a very good job of ramping to max right from idle (instead of waiting even a few ms like ondemand does). It assumes coming out of idle the CPU is starved. Then scales back once demand lowers. No fancy locking to min freq when screen is off (which can stutter some background apps).
There is many thing what can be done in the code of the applications. For example once I had a really sluggish app. It turned out that while I was dragging an item in the UI, the UI needed to be relayouted, and the draw calls were simply postponed: in android (at least that was the case before ICS) the drawing of the UI is delayed while the UI thread is too busy with events and layout requests.
To find these issues it's really useful to use traceview.
Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.
niiiiick said:
Hello everyone,
I've been using the cm9 release candidate since it was released, and still can't figure out how to make it snappy (I was on Apex before, and found it much more responsive). I'm not sure which the performance/memory management settings the Nexus S can handle well (there are lots of other threads for other phones, but I'm not sure if some of the settings require better hardware), so I'd appreciate it if anybody could tell me what they've found to be good for the following options:
Performance settings:
- Surface dithering
- 16bit transparency
Memory management:
- Allow purging of assets
- Kernel samepage merging
Misc. information that may or may not be relevant:
- Using Matr1x kernel (CFS, v21.0 I think)
- Processor is running at 200/1200 most of the time, ondemand governor (same settings that used to give me great performance on Apex).
- Also tried running Supercharger script, but it didn't seem to change things as much as it usually does
- Fixing permissions didn't fix it
- Battery life seems fine
- What I mean by "unresponsive" is that the launcher takes longer than usual to redraw and is laggy switching between windows, apps often force close or take forever to start up, and the browser reacts much more slowly to pinches, swipes, etc.
Thanks!
tl;dr: CM9 users, please share your performance + memory management settings. Explanations not required, though appreciated.
Click to expand...
Click to collapse
You don't need to mess with those settings.
Besides, if your applications FC, it's likely because of:
a) instability regarding your overclock
b) instability regarding the undervolt that matr1x kernel comes with
c) the fact v21 was canned due to being judged unstable by so many, upgrade to v22
d) all of these
Cheers
If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.
063_XOBX said:
If you don't know what a setting does, don't change it. Messing with the CM performance settings if you don't know what you're doing is a great way to mess your phone up.
Click to expand...
Click to collapse
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.
Fensterbank said:
are you completly retarded? there doesnt happen much when you change the settings there. you are talking like the settings are just for pros and he is a kid, lol. kernel samepage merging for example just "bonding" two similiar proccesses so they dont need too much ram.
Click to expand...
Click to collapse
Are you? This thread has been dead for almost 3 months. The OP had his answer. Resurrecting this thread just to argue is incredibly pointless.
Orig!n MOD
Hey Folks.........
Introduction
What is Origin MOD
Origin MOD is script package by me, DC07, full of tweaks and system optimization with more features to give you better experience on your phone for great battery life and high performance. Based on pikachu01 Thunderbolt! script but repacked by me to optimized even further to fit our device. Huge thanks to pikachu01 for his Thunderbolt! script.
Features
✔Overall better performance and better battery life
✔ Less RAM usage through zipalign
✔ Reduced /dbdata, /data, /sdcard usage of *.db files and faster database access
✔ ZRAM script include
✔ Better network throughput from TCP tweaks and 3G tweaks
✔ Faster disk access through remount script (noatime, disable barrier etc)
✔ Faster SDCARD Read/Write Speed
✔ VM Tweaks, battery tweaks and kernel tweaks
✔ Build.prop tweaks and improvements.
✔Cleans log files and tombstones at every boot.
Requirements
-Android 2.3.x (Gingerbread) and higher.
- Kernel with init.d support.
- Root.
- ClockworkMod. (4 or higher)
- At least 4 MB of free space in "/system".
Package Includes
/etc/init.d/ scripts :
1_builder
60ZRAM
67OriginCalcx
78OriginMod
83OriginControl
99Origin_lagReduction
cpugputune
S99Systemcleaner
z_optimization
/system/xbin/ :
haveged
sqlite3
zipalign
\system\usr\idc
mxt224_ts_input.idc...... Thanks to NiTzZ
Installation
1. Delete all others script you have installed in "/system/etc/init.d"
2. Copy zip to your phone SD card
3. Reboot your phone to recovery mode
4. Mount /system and /data
5. Flash the zip you have downloaded
6. Reboot Recovery
7.Clear/Wipe Dalivk Cache
8.Reboot Phone
Credits
- pikachu01 - ThunderBolt
- Zacharias.maladroit
- XDA's devs for some reference of some tweaks in Zach's scripts
- Darkyy for zipalign
-Ne.xt For Pointing Out my mistakes.....
-All My Supporters
-All My Haters
Downloads
Dev-Host
Ne.xt said:
99Origin_LagReduction is a launcher tweak, you should inform users to change the "USER_LAUNCHER" value to the launcher they're currently using.
Click to expand...
Click to collapse
TIPS & Tricks
GUIDE TO GET BETTER BATTERY LIFE
WIFI: Turn off wifi when not in use.
NETWORK: Navigate to setting>more and choose gsm only in network mode when not use 3G. Also use manual search mode.
DISPLAY: Set brightness to 25% to get better battery life cause the major battery drainer come from screen. Use dark wallpaper or theme due to the fact that one black pixel does not consume any battery.
CPU: We can customize our cpu to our personal optimized system. As we now that underclock and undervolt are the great combo to achieve better battery life. I personally not recommend to overclock more than 1Ghz(In Some Kernels) cause it can damage our phone. I personally prefer SetCPU for control cpu but this is the outdated version. Go buy another one on play store. Combination of smartassV2 and sio is perfect for well balance to get better battery life without sacrifice performance.
SERVICE AND APP: Freeze any app that not in use like maps and facebook with titanium backup or simply remove any unwanted app. This will optimize our system giving some battery juice. Also dont use too much widget cause it also running in service. Use only needed
SYNC: Turn off auto sync in setting. This is because that auto sync will running all the time and at the same time our battery flow like water.
OTHER: Turn off gps, google location and google backup the get extra juice in battery.
Thanks To ZN6 For Tips....
Our devices' max. frequency is 832MHz. The 83OriginControl script wont work on our device unless it runs an overclocked kernel. Also, V6 supercharger will conflict with this mod since this mod has a minfree script. Lastly, 99Origin_LagReduction is a launcher tweak, you should inform users to change the "USER_LAUNCHER" value to the launcher they're currently using. I don't mean to flame or destroy, I just want to point out what mistakes are here.
Ne.xt said:
Our devices' max. frequency is 832MHz. The 83OriginControl script wont work on our device unless it runs an overclocked kernel. Also, V6 supercharger will conflict with this mod since this mod has a minfree script. Lastly, 99Origin_LagReduction is a launcher tweak, you should inform users to change the "USER_LAUNCHER" value to the launcher they're currently using. I don't mean to flame or destroy, I just want to point out what mistakes are here.
Click to expand...
Click to collapse
Thanks alot for my mistakes...and my apologies.....
But I mentioned 1Ghz in Some Kernels i.e Merruk,Eve,Jarvis....
ill remove the compatibility...
once again thanks
Downloading .. gonna try later
The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*At least on the Mi4i, you shouldn't be turning your screen brightness above about 50%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
After a bit of tweaking and experimenting, I developed some settings that provide absolutely incredible battery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even a Mi4i. This will work on any ROOTed phone with the Interactive governor!
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
(Note: If your device supports per-core hotplugging, you might be better off using the old guide to determine your nominal clock rates. The Mi4i and all current kernels only support hotplugging entire CPUs, so your results may vary if you use any other device.)
For example, on my Mi4i, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the second CPU clock rates are no less than 460Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Mi4i is 460Mhz.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
This section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Mi4i's Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Mi4i. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 345Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 800Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1651Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
What About Touchboost?
Touchboost is a nifty feature in a lot of kernels (including stock on Mi4i) that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the 1st CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable. On the Mi4i, touchboost adds no perceptual performance gain and only hurts efficiency and battery life. If your kernel doesn't allow you to turn off touchboost, try another one, like the excellent Sensei.
Your battery life will thank you!
The Setup
In the "CPU" section, turn off "Touchboost". (This is crucial!! YOU MUST TURN OFF TOUCHBOOST OR ELSE YOU WILL NOT SEE ANY BATTERY SAVINGS!!!) Make sure the "Max CPU Frequency" is set to the maximum possible value for each CPU. Make sure the "Min CPU Frequency" is set to the minimum possible value for each CPU. Under "CPU Boost", set "input boost milliseconds" to "0". Then set the following values for each CPU under "Governor options" for each CPU respectively:
CPU #1 (aka "Big", aka "has 4 cores", aka "maxes out at 1665Mhz")
target_loads - 1 960000:80 1113600:85 1344000:90
timer_slack - 80000
hispeed_freq - 1113600
timer_rate - 20000
above_hispeed_delay - 20000 1113600:50000
go_hispeed_load - 85
min_sample_time - 50000
CPU #2 (aka "little", aka "has 4 cores", aka "maxes out at 1113Mhz")
target_loads - 1 800000:80
timer_slack - 80000
hispeed_freq - 998400
timer_rate - 40000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 40000
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
I will be happy to answer any questions, or provide any guidance I can. However:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.
I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.
I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized Mi4i running any kernel, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
Thanks to @soniCron for the original thread here : http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
Woah, Will try it soon. Thanks for the awesome thread and work.
The interactive governor from your Sensei kernel already had all these settings tuned.
I will come back in 24-48 hours with results.
One question that I have is: will something like Amplify (deals with wakelocks) interfere with this?
mandarin91 said:
The interactive governor from your Sensei kernel already had all these settings tuned.
I will come back in 24-48 hours with results.
One question that I have is: will something like Amplify (deals with wakelocks) interfere with this?
Click to expand...
Click to collapse
I've dealt with a few wakelocks in the kernel, Amplify won't disturb anything I guess.. Also this is just for future refs for users who are either on stock or any other kernel...
How exactly does this target load list work - why the loads are not progressive, but 85 - 90 - 80? set target to 90% load at 1.1ghz, but then we want 80% at 1.3ghz? Shouldn't the target loads only go up?
target_loads - 1 960000:85 1113600:90 1344000:80
are you sure that above_highspeed_delay for CPU#2 is correct?
danb1974 said:
How exactly does this target load list work - why the loads are not progressive, but 85 - 90 - 80? set target to 90% load at 1.1ghz, but then we want 80% at 1.3ghz? Shouldn't the target loads only go up?
target_loads - 1 960000:85 1113600:90 1344000:80
Click to expand...
Click to collapse
Exactly. And where are the lower frequencies?
The lower frequencies are left untouched. I've been testing this for some time now. Look at the screenshots.
mandarin91 said:
Exactly. And where are the lower frequencies?
The lower frequencies are left untouched. I've been testing this for some time now. Look at the screenshots.
Click to expand...
Click to collapse
bump (?)
Will we get an answer?
I've fixed the settings, target load will now go up rather than up-up-down... Also these settigs are a WIP, right now this is the optimal settings I have that will provide battery life and performance. I will update the settings each time an improvement is made.
Lower frequencies aren't doing much fr me but I'll try to include them into the formula...
haikalizz said:
Lower frequencies aren't doing much fr me but I'll try to include them into the formula...
Click to expand...
Click to collapse
I am talking about these:
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
Click to expand...
Click to collapse
If these "aren't doing much" then there will be only five frequencies: 200, 960, 1113, 1344, and 1651.
And most of the time is spent on 200 or 960. Won't the frequencies between 200 and 960 give better battery life?
How can an awesome thread like this die?
mandarin91 said:
I am talking about these:
If these "aren't doing much" then there will be only five frequencies: 200, 960, 1113, 1344, and 1651.
And most of the time is spent on 200 or 960. Won't the frequencies between 200 and 960 give better battery life?
Click to expand...
Click to collapse
no it doesnt quite work that way. not all lower frequencies will give better battery life. it also depends on the SOC in question and the nature of the SOC. I think hakalizz has mentioned previously of several optimized voltages and frequencies which we don't know for the snapdragon 615. let's use the 615 and some hypothetical values
200mhz - 650mv
400mhz - 650mv
you would have thought that 200mhz would give better battery savings but that isnt the case over here. even though the 400mhz would use more power (even though it is rated the same as 200mhz), technically you get battery savings because 400mhz gets the job done in well, twice the speed of the 200mhz. So you need to either figure out which of your frequencies are optimized in such a way that it can take advantage of the race to idle factor too.
for now i'm still on zzmoove but only to a point where i figure out how to optimize interactive for my own usage (with hotplugging etc)
just to further the point on this advance interactive tweaks - theory-wise and practicality-wise it is sound, you use the best frequencies(Bare minimum that you can stand) and you enjoy battery savings as well. the only issue I see is if you use your phoen differently from the OP. that's why haikalizz says you need to tweak and adjust it on your own
davtse said:
no it doesnt quite work that way. not all lower frequencies will give better battery life. it also depends on the SOC in question and the nature of the SOC. I think hakalizz has mentioned previously of several optimized voltages and frequencies which we don't know for the snapdragon 615. let's use the 615 and some hypothetical values
200mhz - 650mv
400mhz - 650mv
you would have thought that 200mhz would give better battery savings but that isnt the case over here. even though the 400mhz would use more power (even though it is rated the same as 200mhz), technically you get battery savings because 400mhz gets the job done in well, twice the speed of the 200mhz. So you need to either figure out which of your frequencies are optimized in such a way that it can take advantage of the race to idle factor too.
for now i'm still on zzmoove but only to a point where i figure out how to optimize interactive for my own usage (with hotplugging etc)
just to further the point on this advance interactive tweaks - theory-wise and practicality-wise it is sound, you use the best frequencies(Bare minimum that you can stand) and you enjoy battery savings as well. the only issue I see is if you use your phoen differently from the OP. that's why haikalizz says you need to tweak and adjust it on your own
Click to expand...
Click to collapse
Dude, haikalizz mentioned those frequencies in the post but never implemented them in the settings. That is what I'm saying.
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
mandarin91 said:
Dude, haikalizz mentioned those frequencies in the post but never implemented them in the settings. That is what I'm saying.
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
Click to expand...
Click to collapse
dude, i was responding to your question, should these freq inbetween give better battery life
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
Please tell me how to optimize my phone ?
rmusa06 said:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
Please tell me how to optimize my phone ?
Click to expand...
Click to collapse
Debloat, amplify, things like that...
haikalizz said:
Debloat, amplify, things like that...
Click to expand...
Click to collapse
Thank you sir
What app are you using to implement the changes?
Well I got some nice results applying this technique and have overall 1/2 hours more sot using interactive gov. The only profile that works and follows the normal rules is the Ghostpepper profile. I have a moto x play with the same soc so it should work for the mi4i to. First you must calculate the max and min target loads before you can do something power efficient using this technique.
My advice is try to translate the nexus5x ghostpepper profile and replace your min and max target_loads with the ones in the original profile.
And why is this thread just copied and pasted from the original nexus5 thread and only replaced some words with "mi4i". You also forgot the most important part: calculating the min and max target_loads.