This guide is meant for ALL smartphones that runs the Interactive governor, copy-pasted here for better visibility. Credits goes to @soniCron for starting up the guide and @Alcolawl for further implementing it.
The Introduction
So, I tried copy-pasting the entire thread and realised it looks ugly therefore I'll rewrite it to be more simpler and straightforward.
Imagine a car with manual gears, you choose what speed is best suitable for the road conditions. Going into a curve? Best slow down. Clear straight road? Go fast so you reach the destination safely and efficiently.
That's what this guide aims to do with the Interactive governor, based on the CPU load it will choose the best and the lowest frequency to complete the task without compromising performance.
For example, if you scroll your Facebook page your CPU might clock up to the highest frequency for smooth scrolling. Now lower the frequency one step down and you may find that it's still smooth, so why isn't it choosing that instead? Don't blame the phone companies or Google, that's just a way of ensuring performance at all times. This guide will push the limits of that capability.
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.
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.
Click to expand...
Click to collapse
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 lags or stutters. (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.)
Remember what was said about scrolling FB pages? This is it.
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.
Imagine a staircase with steps of different heights. You climb these stairs better depending on the height of each steps, do you skip some steps if you can reach the next one easily? Or do you take one step at a time because they are too high?
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 - 384Mhz
Page Scrolling - 600Mhz (Tested by browsing FB on Chrome browser cause they're intensive enough)
Video - 787Mhz (Same thing, watch 60fps videos on different resolutions on the Youtube app to detect stutters and lags)
App Loading - 960Mhz
High Load Processing - 1440Mhz
(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 Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
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.
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
Click to expand...
Click to collapse
SO there you go, that's the gist of it. I got some smaller examples written up later so hopefully it's more understandable.
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
GlassFish (For most devices!) - High battery savings with buttery smooth interface!
HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
DrunkSauce - Supreme UI fluidity coupled with excellent active and idle battery drain. Idle Drain was consistently measured to be ~1%. And while I don't rely on SOT figures that people constantly throw around, active drain spanned from 15-20%/hr depending on usage. YMMV. And as always, flawless audio playback for you audiophiles and ARISE users out there.
Those are the ones compiled for now, please remember that these are all up to the users' preference. It will improve YOUR own SOT, not straight up 8 hours on every device. You can copy off the profiles and use your own device frequency and target loads, use an app like Kernel Auditor to help edit them. It works for stock and custom roms too.
Extra credits:
Thanks also to:
Every developer who has seen this guide, modified it, and implemented it.
All the members who contributed and argued about the inner workings of this guide, your constructive feedback is amazing and helped fine-tune future profiles.
To the poisonous and toxic trash member(s) of a certain thread for their lack of help and elitist behaviour. Their embarrassing attitude helps open our eyes to the dos and don'ts of internet manners.
This is for calculating target loads.
Let me give you an example from my Note 1:
My clock rates are (in MHz): 200, 500, 800, 1000, 1200, 1400
Their voltages are (in V): 950, 950, 1050, 1125, 1225, 1300
If I were to plot the differences in voltage, it would appear like this:
{
"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"
}
From the graph, 500MHz to 800MHz has a huge difference in voltage increase compared to 1000MHz to 1200Mhz. That frequency BEFORE the huge jump is the efficient clock rate: 500MHz and 1000MHz.
So, the nominal clock rate on the other hand is the minimum frequency you can use to complete a task (such as watching videos, loading apps, page scrolling). In this case, mine are: 200MHz, 800MHz, 1000MHz
Now, we just calculate (from the first post) the minimal efficient loads for efficient clock rate and maximal efficient loads for nominal clock rate.
That means my target loads will be:
500: 60
800: 72
1000: 75
1200: 17
I skipped the calculations but this will be what it looks like from there. Someone pls do let me know if I made a mistake, as it does tend to confuse people with other devices.
Nominal clock rate: Maximal load
Efficient clock rate: Minimal load
Edit: Those are for the target loads, for the rest of the settings I'll use the profiles'.
Eh, mmight as well reserve this too
Nice looking guide, about to read
wtf,you just copy pasted in the end
Nice beginning, but half is missing, and you are referencing things that haven't been done before
Related
I've been staring at BatteryStatus' CPU Scaling function wondering what good it does if I use it... and how do I use it if I decide that it was useful. I'm sure some users here are wondering the same thing, especially on our low-powered Wizards. Can someone lay it thick for us CPU-shy users?
The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)
Sweet
starkwong; said:
The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)
Click to expand...
Click to collapse
Awesome! Something usable when my phone's bluetooth connected to my car.
Now, how does one set up these options to take advantage of this function?
It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.
shantzg001 said:
It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.
Click to expand...
Click to collapse
Well said !
Dont get me wrong but pls search before shooting off questions.
Plz read the forum,you'll find all the answers to your question in here,these kind of questions have been asked hundreds of times in various threads or shud have posted in the appropriate thread from you downloaded your present rom TNT 5.0. Or hit the 'Search' button at the top with your specific word to locate,you'll be amazed.There's no need to start a new thread for this.
Just remember...
More Mhz translates into less power efficency.
ie.
195 mhz (stock speed) = Regular Baterry consuption
240 mhz (overclocked speed) = Over Regular Baterry consuption
260 mhz (overclocked speed) = High Baterry consuption
280 mhz (overclocked speed) = you got the idea
Also remember that when increasing the processor Speed may cause your system to hang or not wakeup if you are using a very low frequency.
Best regards.
Welcome to Smurf Land.......Where you are whisked away to a smurfalicious place!
LA LA lalalala LA LA LA LA LAAAAAA....
Alright enough with the cuteness of all this.
Basically I have created a script that prompts you (the user) to answer some vital information them based on your answers the script will inject specific tweaks to your build.prop and also to a file in your init.d folder. These tweaks include battery tweaks, memory tweaks, speed tweaks, governor tweaks, 3g and wifi tweaks, SD card tweaks, and a bunch of random tweaks. Some collected from a bunch of different phones tweaks and others created by me.
The script will search out every line in your build.prop and remove any line that is there that I am adding and remove it first to reduce duplicate codes. It will remove a whole list of other init.d files that conflict with it. Will also create a few other files and folders to add functionality and speed optimization to your phone.
What if you do not like the tweaks that I added.....well the script creates back-ups for you and you can choose the option to Un-Smurf and it will set you back to before you installed.
CREDITS
zeppelinrox for his excellent scripts.
tommytomatoe for answering all my ridiculous questions and also the space in which to post my work
Lpy for his loopy smoothness
eoghan2t7 for his tutorial on loopy smoothness
knzo for his collection of tweaks
[email protected] for his collection of scripts which I pulled some tweaks from
metalspring for his explanation of a lot of tweaks and some build.prop and init.d tweaks
scottypeterson for his ultimatescript
cwc3 for his collection of scripts which I borrowed settings from
tazzz811 for his thread on some great init.d tweaks
droidphile for his incredible guides and some great governor tweaks and I/O scheduler tweaks
Each persons name has a link attached to it to show their work and threads which to thank them.
These Settings are all over the Internet across multiple forums and presented by more than a dozen people. If any setting in here was initially created by you and you did not get credit please PM me with your Info so I can add you to the credits. No work here has been stolen or taken on purpose. If you created or founded any of these setting and do not wish for me to use them then again please PM me and I will remove them as soon as possible. Please do not start a flame war on this thread due to my ignorance. I am just trying to get these settings out to as many people as possible to bring the smoothest experience to Our phones.
Instructions
1. Download Smurfed Out script.
2. Open up Script Manager found here if you don't have it
3. Scroll Down to the Smurfed_Out.sh file and click on it. This could Possible be in your downloads folder.
4. Click on the su key, the skull and crossbones, or run as root depending on which version of script manager you have then click run
5. Follow instructions on the screen.
!!! Warning !!!
By using this script you acknowledge that it could possible break your phone. In other words don't come running to me when you phone burst into flames and or it leaves you for someone as sexy as it has now become.
Download
{
"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"
}
Smurfed Out V 6.6
Other Phones
Please feel free to post a thread in other forums or other site but please link back to here for the downloads. I am trying to give the user the best experience possible and if dl links are made all over the place then there is possibility for them to not get updated when I release a new version. Plus the info in the first three post here explains alot.
Developers
If you would like this baked into your ROM the PM me and I can help. I already have a ZIP file created with he exact files that you need and instructions with how to implement. I need to make a few corrections based on your specific Rom but it is an easy fix and would rather do it or help you do it so there arnt any conflicts at all. I have already helped a few other DEV's bake it into their Roms and it works great.
Thank Me
If You Find this post USEFULL and ENJOY using the SMURFED OUT Script then Please take the time out to THANK ME. I'm Not asking for Donations but this does take countless hours to put together. Also you can click the links in my sig to see my working in the google market(PLAY) follow me on my Twitter and Facebook sites
Info
I/O Scheduler descriptions
Different Governors
LMK Settings (Low Memory Killer)/ADJ & MINFREE Values
ICS USERS
IF running ICS then go here to auto patch your SERVICE.JAR for new OOM settings.
FYI your services.jar can be found /system/frameworks/services.jar.
Seriously
If your coming from a version before 4.0 I Highly recommend Un-Smurfing First
Highly Recommended
If you want to make sure the settings stick....go into your /system/etc/init.d folder with script manager and set the 45smurfed file to run as root and run at boot. Some say this makes the setting stick others see no effect.
MUST READ
If your launcher does not show up in the auto detector then please inform me of the package name (found in /data/data) usually looks like this blah.blah.launcher. I will add it to the database and update the script rather quickly.
Change log
V 6.6
Added Instant Smurf-Power option which will clear out caches and give your phone an oh so fresh feeling (kinda like restarting your phone without having to)
Added in half a dozen build.prop tweaks
Fixed Some issues with the 45smurfed file
Added in ability to choose how much you want your Dalvik heapsize to be
Rearranged the Loopy Smoothness Tweak
Added in EXT4 Tweaks (convert your sd card over to ext4 and answer the question in the script for it to go into effect)
Added in swap support
Added in some new checks
Added in some permission sets so settings dont get overwritten
I'm sure there are more but can't think of any
Highly recommended that you UN-SMURF before you run the newest version as some of the files that the script removed in last version are needed in this version.
V 6.5.1
Fixed name of Launcher not being correct
Fixed wifi and 3g not switching, addition of last minute build.prop tweak jacked it all up
V 6.5
Fixed some syntax errors
Corrected names of a few launchers
Added in redundancies to back up everything the script removes so when unsmurfing there is no residual effects and everything is returned to Pre-Smurfed conditions
Everything is now backed up to a folder created on your SD card now instead of spread all over. File is called SmurfedBackups
Tried to fix Launcher Detector not reading some Launchers but cant get pm list packages to sent list to a file with out getting a segmentation error...any suggestions would be helpful
If your launcher is not found and you know the name of it try it out cause its saved in the detector as a launcher just isn't being autodetected
On AOKP and roms based off of it some of the init.d tweaks you find in rom control startup tweaks will not work anymore as i removed them becuase my script does it for you now. They will be restored if you Un-Smurf
Updated HTML doc with latest build.prop edits
Changed a few settings in build.prop
V 6.4
Fixed launchers not being found
Reorganized code
Added the google dns servers to the resolv.conf file
Added in check for HWA and if there it removes cpu rendering to speed up os
Fixed some syntax errors in init.d file
Added in a few new build.prop tweaks
Added in regroupings of OOM Settings into the build.prop
V 6.3
Added Miui Launcher
Added Lightning Launcher
Changed the way the I/O Schedule List shows up
Changed the defraging database process. Should be a lot cleaner now.
Added a few extra build.prop tweaks. If you look at them the values are
supposed to be blank.
V 6.2
Fixed problem with Cron files not copying over correctly
V 6.1
Fix syntax error
V 6.0
Added checks to make sure no typing error occur
Added info on which settings you are using to menu
Added more options to the menu that allows you to
Change your Launcher
Change your LMK Settings
Change your I/O Scheduler
Changed LMK settings names (Spaceballs Reference now)
Added adj actual numbers to LMK settings so user knows the values
Added CRON to wipe different cache every hour ever day and every week
Script now Auto finds your Launcher(s) and has you select from a list (If
yours doesn't show up tell me in this thread and I will add it. I already have over 60 different launchers presearched)
Fixed init.d file (some variables wernt getting sent correctly
Removed some build.prop edits as to fix 3g and wifi issues
I think that's it. But im sure I missed something
V 5.0
Changed delivery of the init.d file
Changed the numbering of the init.d file
Took away 3g/wifi tweaks that were interfering with wifi connecting and toggles not working
Added in checks to remove some conflicting init.d scripts
Added in checks for Selection of aggressivness of OOM (adj & minfree) settings
Added in an option of what I/O scheduler you want to run
Added in a few other build.prop tweaks
Cleaned up some code
V 4.7
Added OOM levels
Added Min free values
Added Min KB values
Added option to choose from AOSP or SENSE
Added Option to Choose from ICS or Gingerbread
Lowered the Wifi option to normal levels for connection issues
V 4.6
Changed ro.ril.enable.a52=1
Changedro.ril.enable.a53=1
Changed net.tcp.buffersize.default=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.wifi=524288,1048576,2097152,524288,1048576,2097152
Changed net.tcp.buffersize.umts=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.gprs=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.edge=6144,87380,524288,6144,16384,262144
Changed net.tcp.buffersize.hspa=6144,87380,524288,6144,16384,262144
Changed net.tcp.buffersize.lte=524288,1048576,2097152,524288,1048576,2097152
Changed net.tcp.buffersize.hsdpa=6144,87380,1048576,6144,87380,1048576
Changed net.tcp.buffersize.evdo_b=6144,87380,1048576,6144,87380,1048576
Added ro.media.enc.hprof.vid.fps=65
Govenor Tweaks for Interactive, Ondemand, OndemandX, SmartassV2, Lulzactive, and Conservative
Changed kernel.msgmni=64000
Cleaned up Code even more
V 4.5
Added a few more tweaks to the 01Smurfed file
Added a few more build.prop tweaks
Hopefully fixed the wifi->3g->wifi issue
Cleaned up the code a little
V 4.1
Changed picture and video settings...camcorder works now
Increased and decreased a few values
Added a huge amount to the init.d file
Removed the minfree values from the init.d (if you want them back I can release one for Gingerbread and one for ICS)
V 4.0
Removed some tweaks that were causing issues
Added in some new tweaks
Changed a few Settings for better response
Script now checks to see if your using a local.prop and if so copies settings to it as well
Now script creates a file in you init.d folder called 01smurfed. This has many new tweaks that will run on every boot
Comments put into script to explain what exactly is going on
Credits given in OP
V 3.3
Removed some setting that were either not necessary or we causing issues for some
Added in some new tweaks I figured out
Fixed 3g not connecting right after turning off WiFi
Fixed WiFi not connecting sometimes
Script now wipes dalvik-cache and requires a restart. Restart will take a little longer due to rebuild of dalvik
I HIGHLY recommend UN-SMURFING before you apply the newest script. I have noticed huge improvements from this last update
V 3.2
Added a few more tweaks
Fixed a typo
Made sure system was remounted as read/write before settings took place
V 3.1
Removed super user check. (Giving errors to some)
Fixed my bad spelling (lol)
V 3.0
Added 10 new edits
Cleaned up code
Made sure temp files were being deleted correctly
Change a number of setting for better tweaking
V 2.0
Huge code change. Now with options.
Now scans and removes duplicate lines
V 1.0
Initial release
Over 30 build.prop edits with more to come.
For a detailed list of settings that this script copies to your Build.prop go to /sdcard/SmurfedBackups/Smurfed_Out.html
!!! WARNING !!!
This Script now interferes with alot of other scripts. I'd recommend unsupercharging and removing some other scripts as well...Tweaks, Read Ahead SD card tweaks, Governor Tweaks, and I'm sure there are a few others. This script searches for some of the scripts mentioned and removers them if found.
Un-SMURF
During the Smurfing process a copy of all removed files is sent the the SmurfedBackups folder on your SD card. When un-smurfing your phone will be restored back to the exact way before Smurfing.
Future Releases
1. Adds in as many battery saving, speed, and responsiveness tweaks as I can find throught out many different forums.
2. removes any other script that is previously installed that may be using same tweaks....if not removing the script itself it will search out each line of each script and remove the lines individually.
FEEDBACK & BUG REPORTS
Please leave feedback after you run so others know how well this script works. I will try my best to help with any bugs that are found. If found please report in this thread with the following info
What Rom are you running?
What Phone are you using?
What settings did you choose in Smurfed Out script?
What Governor are you running?
What kernel are you using?
What things did you try before reporting?
What issues are you running into?
What is your Name and Social Security number? (lol)
What is your Blood Type? (LMAO)
Have you ever thought about donating an organ? (LMFAO)
Syntax Errors or Suggestions
If reporting syntax errors or suggestions to improve the script then please put them into code brackets so I can easily read them and also line number if you happen to remember helps as the script is over 2500 lines now. I appreciate all help with these errors and suggestions to improve the script.
Troubleshooting
My WiFi or 3G doesn't work or wont switch?
Go into recovery and wipe dalvik-cache and cache and reboot.
Check to see if data is enabled in your settings.
Check to make sure if your using a battery saver app like battery xl or juice defender that is not turning off your radios
My camcorder isn't working?
Make sure your using the most recent script. The fix was made available on V 4.1
Does this script work for other phones?
Yes in theory it does. Let me know if it works or not and I'll put it in the OP so others know
I can't get this script to run in script manager?
Make sure you are opening the script with superuser rights within script manager
Can I run this in terminal emulator?
yes type this is command line. also make sure that Smurfed Out is on root of your sd card
Code:
su
sh /sdcard/Smurfed_Out.sh
After running the script and rebooting Im getting a blank black screen?
First scroll down and read just in case and follow those instructions then follow Bug Reporting procedures
My phone got up and ran away from me?
Well this can be a problem....On one hand that would mean that this script really works...on the other hand it means your just not cool enough for you phone anymore and it found someone better.
Just In Case
Build.prop.zip attached is a flashable zip in case of emergency. It has the build.prop of aokp rom in it. If your not running that rom...download the zip. open it up. go into the system folder. Replace the build.prop with the build.prop from the Rom.zip that you are running. Put on your sd card. Flash in recovery. I am putting this here cause in the past there were issues with the script causing a freeze after boot and some people had to nand back or reflash their rom. This will fix that. Enjoy.
[SCRIPT] Smurfed Out V 5.0 (ultimate build.prop/init.d tweaks) Updated 3-18
I/O Scheduler Descriptions
Taken from this post here
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.
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.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device
Explanation of Different Governors
Pulled from this page here
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) 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.
8) 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.
9) 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.
10) 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.
11) 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.
12) 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.
13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
17) 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).
18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
[SCRIPT] Smurfed Out V 5.0 (ultimate build.prop/init.d tweaks) Updated 3-18
Explanation of LMK Settings (Low Memory Killer)
and
Explanation of Adj and Minfree settings
When your phone boots up, a file inside the boot image (init.rc) sets the system parameters. Things like the path to framework files, setting up your networks, and setting the limits at which programs are killed off to free RAM are done by this file. Now a super-Android-geek might dig inside the init.rc file and completely customize the low memory killer, but you don't have to do this to still get good results. The init.rc sets up six different "levels" of open applications. Let's have a look at them:
FOREGROUND_APP: This is the application currently on the screen, and running
VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something
SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something
HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running
For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:
CONTENT_PROVIDER: This is apps that provide data (content) to the system. HTC Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Android Market, or Fring. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.
EMPTY_APP: I call these "ghosts." They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. To satisfy the geekier people (like myself) Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes, so there's no need to touch this part
So when you see settings like this 8,14,40,50,60, 75 you start with the first setting and it looks like this
FOREGROUND_APP = 8
VISIBLE_APP = 14
SECONDARY_SERVER = 40
HIDDEN_APP = 50
CONTENT_PROVIDER = 60
EMPTY_APP = 75
You can manipulate these numbers so that they are better managed and give You different aggressiveness and a faster UI
For the Smurfed Out script the settings are as follows
Lite = 8,14,55,70,85,100
Medium = 8,14,75,90,95,125
Max = 25,35,55,70,150,250
Extreme = 25,35,75,90,150,250
Minfrees are set as well but they are equal to the LowMemoryKiller ADJ settings.
I personally run them at Max while using ICS but everyone's experiences will be different.
Nice idea.....good job.
Sent from my PC36100 using XDA App
Looking forward to trying this!
Sent from my PC36100 using xda premium
Interesting
Sent from my PC36100 using XDA App
gonna try this now .
Um, where is the file?
Roman G said:
Um, where is the file?
Click to expand...
Click to collapse
Click on the link that says smurfed out basic
Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!
moreno4xl said:
Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!
Click to expand...
Click to collapse
Feedback is always welcome. As this is the first release I have many other changer that will be taking place in the future on this script nut wanted to release something I had working for now
Papa Smurf151 said:
Click on the link that says smurfed out basic
Click to expand...
Click to collapse
Thanks.
Typing with it now, will report back tomorrow.
I will say I do notice an instant difference, linpack say so as well.
Roman
When I click the link it just opens the file. How do I save it, so I can run it.
nickmus said:
When I click the link it just opens the file. How do I save it, so I can run it.
Click to expand...
Click to collapse
Same with me, I just opened the thread in the browser and saved file by pressing n holding. Renamed it "smurfedoutbasic.sh" and ran it in scripts manager.
Sent from my PC36100 using xda premium
Ya just long press and save. Don't need to rename. Then open it where ever downloads are saved.
Roman
So far I like being Smurfed
Mmmh... Ice Cream Sandwich
Got it using the web browser.
Thanks
Roman G said:
Ya just long press and save. Don't need to rename. Then open it where ever downloads are saved.
Roman
Click to expand...
Click to collapse
What he said lol i had to rename it cause for me it saved as a .bin file
Sent from my PC36100 using xda premium
Sweet. Been seeing the teaser in AOKP thread. Gonna give this a shot and see how it sits in after a day or so.
Sent from my PC36100 using xda premium
I've turned blue and I'm singing
Can anyone recommend whats best to use to get max battery life with reasonable performace ( btw i dont do heavy gaming, only CoC from time to time ) and mabey some additional governor settings for stock 4.4.2.
My kernel supports:
Governors:
-ondemand
-interactive
-userspace
-powersave
-performance
Schedulers:
-noop
-deadline
-row
-cfq
Thanks in advance
nasye said:
Can anyone recommend whats best to use to get max battery life with reasonable performace ( btw i dont do heavy gaming, only CoC from time to time ) and mabey some additional governor settings for stock 4.4.2.
My kernel supports:
Governors:
-ondemand
-interactive
-userspace
-powersave
-performance
Schedulers:
-noop
-deadline
-row
-cfq
Thanks in advance
Click to expand...
Click to collapse
everybody's usage varies, just try them out and make a record of what you got from each one then go back and check out to see what worked best for you
-----------------------------------------------------------------------------------------------------------------------------------------------------
laggy? Snappy? Battery life? SOT [screen on time]?
-----------------------------------------------------------------------------------------------------------------------------------------------------
-ondemand:::-noop
-ondemand:::-deadline
-ondemand:::-row
-ondemand:::-cfq
--------------------------------------------------------------------------------------------------
-interactive:::-noop
-interactive:::-deadline
-interactive:::-row [stock setup]
-interactive:::-cfq
--------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------
[-powersave]::: .not really worth trying, probably gonna lag if you try to game, etc. CPU frequency at the lowest frequency when doing a task
[-performance]::: May not be worth trying, it runs max cpu all the time when doing a task [1200 Mhz] it will idle and sleep though if kernel allows it and is set up that way
[-Userspace]::: This governor, exceptionally rare for the world of mobile devices
--------------------------------------------------------------------------------------------------
:::: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
--------------------------------------------------------------------------------------------------
:::: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
-----------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------
:::Noop:
The noop scheduler is the simplest of them. He is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our SGSII's to use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. ie the data that come first are written first. He's basically not a real scheduler, as it leaves the scheduling of the hardware.
Benefits:
- Adds all incoming I / O requests in a first-come-who-first-served queue and implements requests with the fewest number of CPU cycles, so also battery friendly
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance einhergehendem
--------------------------------------------------------------------------------------------------
::eadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ very popular and in many well known kernels, such as the Nexus S Netarchy. He was indeed better than the BFQ, but compared to the VR he will be weaker.
Benefits:
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage does a CPU is easy to calculate.
- As the Governor-noop ideal for flash drives
Disadvantages:
- If the system is overloaded, can go a lost set of processes, and is not as easy to predict
--------------------------------------------------------------------------------------------------
:::Row:
Q: What is the ROW I/O scheduler?
A: ROW stands for "READ Over WRITE"
The ROW IO scheduler was developed with the mobile devices needs in
mind. In mobile devices we favor user experience upon everything else,
thus we want to give READ IO requests as much priority as possible.
In mobile devices we won’t have AS much parallel threads as on desktops.
Usually it’s a single thread or at most 2 simultaneous working threads
for read & write. Favoring READ requests over WRITEs decreases the READ
latency greatly.
--------------------------------------------------------------------------------------------------
:::CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Prozess-I/O-Warteschlange, ie the available I / O bandwidth tried fairly and evenly to all I / O requests to distribute. He created a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, ie each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There is a V2 and the CFQ has some fixes, such as were the I / O request, hunger, and some small search backward integrated to improve the responsiveness.
Benefits:
- Has the goal of a balanced I / O performance to deliver
- The easiest way to set
- Excellent on multiprocessor systems
- Best performance of the database after the deadline
Disadvantages:
- Some reported user that the media scanning would take this very very long time and this by the very fair and even distribution of bandwidth on the I / O operations during the boot process is conditioned with the media scanning is not necessarily the highest should have priority
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
--------------------------------------------------------------------------------------------------
credits
http://forum.xda-developers.com/showthread.php?t=1663809
although wheatley governor is not here, i HIGHLY reccommend it.
What is a CPU governor?
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.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors for the Xperia M2
NOTE:not all govenors listed will be available for every rom or every kernel
1) Ondemand
2) Interactive
3) Intellidemand
4) Userspace
5) Powersave
6) Performance
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) 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.
3) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. 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.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
4) Userspace:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
5) Powersave
Powersave governor locks the CPU frequency at the lowest frequency set by the user.Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
6) Performance
The performance governor locks the phone's CPU at maximum frequency(Used for benchmarking)
GOVERNOR TWEAKS
PARAMETERS & TWEAKS:
1.ONDEMAND
[ PARAMETERS ]
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
v) down_differential - This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step
percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.
[ SAMPLE TWEAKS ]
i) For battery:-
To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.
up_threshold : 95
sampling_rate : 120000
sampling_down_factor : 1
down_differential : 5
ii) For performance:-
To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.
up_threshold : 70
sampling_rate : 50000
sampling_down_factor : 2
down_differential : 15
2.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:-
go_hispeed_load : 95
hispeed_freq : 1000000
min_sample_time : 10000
timer_rate : 40000
For performance:-
Assuming your scaling_max_freq is equal to or above 1400 MHz
go_hispeed_load : 80
hispeed_freq : 1400000
min_sample_time : 40000
timer_rate : 20000
Additional Info:
{
"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"
}
Hotplugging drivers:
mpdecision: Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
msm_hotplug: Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
intelliplug: Great balance between battery life and performance. It is also a popular hotplug driver from faux123
Hotplug tunables guide
1) msm_mpdecision
[ PARAMETERS ]
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (70)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1.
max_cpus = max cpus to be online (if you set it to 2 and min_cpus to 1 you will basically have a dualcore)
idle_freq = a value against that will be checked if a core +/- is requested.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
I/O Schedulers:
Available I/O Schedulers for the Xperia M2:
1.Deadline
2.Noop
3.SIO (Simple I/O)
4.ROW
Deadline:
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
Benefits:
- Nearly a real-time scheduler.
- Excels in reducing latency of any given single I/O
- Best scheduler for database access and queries.
- Does quite well in benchmarks, most likely the best
- Like noop, a good scheduler for solid state/flash drives
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
The bottom line: A good all-round scheduler. If you want good performance
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.
Benefits:
- Serves I/O requests with least number of CPU cycles.
- Best for flash drives since there is no seeking penalty.
- Good data throughput on db systems
- Does great in benchmarks
- Is very reliable
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance
- Not the most responsive I/O scheduler
- Not very good at multitasking (especially heavy workloads)
The bottom line: Modern smartphones now use noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons).
SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between noop & deadline. No reordering or sorting of requests.
Benefits:
- It is simple and stable.
- Minimized starvation for inquiries
- Not the best scheduler for benchmarks
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers.
- Sequential read speeds on flash drives are not as good as other IO schedulers
The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.
ROW:
The ROW I/O scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ I/O requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.
Benefits:
- Faster UI navigation and better overall phone experience
- Faster boot times and app launch times
Disadvantages:
- Not great for heavy multitasking
- Slower write speeds
The bottom line: Most phones will get a nice I/O boost, however experience varies between devices.
I/O Read Ahead Cache :
If you've used a custom kernel, you probably have heard of a term called Read Ahead cache or size. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more cache means that more files can be cached, this can mean higher read and write speeds, but also this can result in more i/o latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.
Have a look at the graph below:
Recommendations:
For stability:
Use 128kB read-head value
For performance:
Use 2048kB read-head value
For any internal storage:
Use 128kB read-ahead value
For external SD cards with less than 8GB:
Use 128kB read-head value
For 16GB external SD cards:
Use 1024kB read-head value
For 32GB external SD cards:
Use 2048kB read-head value
For 64GB+ external SD cards:
Use 2048kB read-head value
What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Not all kernels allow users to change the I/O read ahead
- Performance difference varies between devices
In simple, a 1024kB read ahead should suit most devices today. 2048kB and 512kB are also good options I recommend too.
GPU Governors
MSM-Adreno: The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life. It is still a balanced governor for everyday usage.
Ondemand: Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings. This is a widely used governor in qualcomm devices.
Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
I have spent many hours compiling all of the info on CPU governors and I/O schedulers.If you want to use the descriptions and info in your own thread, make sure to give me credit for gathering this info and also mention the others for their descriptions too. Remember that this info is for free and can be used for your own help and for others if you follow XDA rules
https://www.youtube.com/user/UmeshCahill
Thanks for the post, really interesting :good:
wow, that's really awesome sir . Nice info
iFlashed said:
Thanks for the post, really interesting :good:
Click to expand...
Click to collapse
You are welcome
FunSucker said:
wow, that's really awesome sir . Nice info
Click to expand...
Click to collapse
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes
Umesh1041 said:
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes
Click to expand...
Click to collapse
Would be great If u could suggest these tweaks to ROM developers
Hi Guys, this is a continuation from initial discussion (and my promise) on InsigniuX kernel thread HERE
UPDATE 1 : After further testing, incorporate input boost to CPU 1 and 5 actually help the performance without affecting battery, as long as we set it within the optimal frequency. I also put fine tuning in hispeed_delay value, please use latest Profile File if you are using PRESET, or check the new values bellow if you do manual config
NOTE : If you are too lazy too read all the technical stuff, simply download the PRESET KERNEL ADIUTOR PROFILE HERE, and apply it to your Kernel Adiutor (choose "profile" from side bar, hit the (+) icon, and choose "import" and choose the downloaded .json file)
as we all know and aware, we always look and try to find the most optimum configuration to achieve best battery life without sacrificing performance. And while of course Qualcomm and Xiaomi have the most talented developers in their team, sometimes the implementation between both in their mass product might left a room for improvement. And in that exact room, we as community here play our role,
so, in an attempt to get a better fluidness out of this device, without sacrificing battery life, i remember one of the guide made by @soniCron i used to stumbled upon few years ago. This Guide give a very detail insight on how to optimize the interactive governor on almost any device/any kernel/any rom (as long as you have root), and thats what i gonna try to apply to our device - if you want to check the guide yourself : HERE
so i take a look into Whyred Kernel Sources to see the voltage values being used by our processor for each frequency step. And here's the voltage/speed table in case you want to see :
{
"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"
}
from that table, we can see which frequencies are using most power, and where is the most jump in voltage usage happen when switching between frequency.
Higher voltage jump will cost more power, means less battery life.
in conclusion, i found few frequencies which are less favorable, which is
LITTLE CPU :
1136Mhz - step by step Speed Gain is fine, but when compared to straight jump to 1401Mhz, the Speed to Power Ratio is become less favourable
1536Mhz - Smallest Speed Gain compared to Power Usage
and i also found some which might be the best/favourite frequencies :
LITTLE & BIG CPU :
900Mhz - Best contender for base speed, as it use almost same power with 633Mhz, but with plenty of speed gain
1401Mhz - Good Speed to Power Ratio
and
1747Mhz - Good Speed to Power Ratio for BIG CPU
_____________________________________________________________________________________________________________________________________________________
Now we take into account of the minimum frequency needed to ensure smooth task (if you dont know what am talking about, read the GUIDE i mention in my opening paragraph) :fingers-crossed:
For Whyred, i've found the best frequency is as following :
Idle = 633MHz (Lowest we can go at the moment)
Scrolling = 900MHz (Use Chrome browser to scroll Facebook in desktop mode)
Video = 1401MHz (Play 1080p*60fps videos in Youtube app)
App load = 1747MHz (Can use any app really)
High load = 1843MHz (Max out just in case)
Using the formula take from soniCron guide, i tried calculate optimum CPU load (this will be used as target load config) config for each frequencies
If you want to see the formulas :
Code:
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
with this config, logically speaking we want to make the Governor to favour the "best" frequencies above, and minimize the usage of unfavourable freqs.
LITTLE
Code:
633Mhz : 63
900Mhz : 71
1136Mhz : 23
1401Mhz : 82
1536Mhz : 4
1612Mhz : 83
BIG
Code:
1136Mhz : 73
1401Mhz : 9
1747Mhz : 85
1843Mhz : 90
Now that we already get the optimum number, time to apply it
Use your favorite Kernel Manager, in my case, am using Kernel Adiutor, and go to CPU Config - CPU Governor Tunables and input these value (am using Hawktail base profile from soniCron thread, as it seems it work best for most of devices, and i already do trial & error with some other value like timer rate as well ) :
(LITTLE)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 0 633600:60000 902400:75000 1401600:100000
timer_rate: 80000
hispeed_freq: 902400
timer_slack: 200000
target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
min_sample_time: 35000
boost: 0
boostpulse_duration: 0
(BIG)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 32000 1136000:60000 1401600:75000 1747200:80000
timer_rate: 60000
hispeed_freq: 1747200
timer_slack: 100000
target_loads: 98 1113600:23 1401600:9 1747200:85 1804200:94
min_sample_time: 20000
boost: 0
boostpulse_duration: 0
Other necessary adjustment :
Boost : ON For CPU 1 at 902400 and CPU 5 at 1401600 both for 100ms
Min Big CPU Hot Plug : 0
Disable all Toggle in Thermal Section
Run Terminal and command :
Code:
su
stop perfd
or Install this MAGISK MODULE to disable Stock Thermal & Hotplug Control (Courtesy of @Mr.Nguyen0504)
Now you can test it. Do full charge and use it normally, see whether you can see the improvement or not,
be mind that this config is not really adjusted towards battery life, but rather overall fluidness/performance, yet without sacrificing too much power
Hopefully it helps you as it seems to help me (you can expect no less than 7-8Hrs SoT, am quite heavy user myself, with 2 WhatsApp account and 1 LINE account constantly active. YouTube & Gaming at least hour/day as well). Discussion is more than welcome here, as these are considered an initial calculations that still yet to furtherly fine tuned for our CPU.
Thanks mate, was waiting for this.
Initial thoughts = project butter:good:
xdarkstar said:
Thanks mate, was waiting for this.
Click to expand...
Click to collapse
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
otonieru said:
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
Click to expand...
Click to collapse
Excellent guide as well. Will test parameters over the weekend.
I will test this
mxilil said:
I will test this
Click to expand...
Click to collapse
yes please,
in the meantime, i also testing another config with input boost enabled, and some fine adjustment to hispeed_delay,
if it turn out to be better, i might create 2nd preset, along with custom control to disable BCL and Perfd. So we do not need to type it in terminal manually after reboot and let adiutor do that.
otonieru said:
Run Terminal and command :
Code:
su
stop perfd
Click to expand...
Click to collapse
I think "stop perf-hal-1-0" is the proper command.
@otonieru Great thread, very nice presentation of the matter with just the right info and setup example.
I have followed the same tutorial for my previous device but ended up using the tunables from my ROM maintainer as I never managed to calculate it properly, probably because I overlooked the voltage jumps.
Now, I wonder whether the minimum freqs of 300mhz for both clusters would help in battery life gains, taking into account the proper target loads are set for both and "timer_rate" and "min_sample_time" are tuned to make CPU ramp up quickly to avoid lags and stutters.
Logically, voltage is lower for lower frequencies, but in this case, 300mhz and 633mhz might be the same on little cluster or the voltage jump might be insignificant, but the voltage jump on big cluster might be bigger. And since the big cluster is on minimum frequency most of the time we might see some gains there.
Can you check the sources of some kernels with full range of frequencies (not the ones who have undervolt applied) and see the voltage tables?
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
Code:
[init.svc.perfd]: [running]
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Cirra92 said:
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Click to expand...
Click to collapse
Actually, i didnt include 300Mhz in my calculation because i try to check various whyred kernel source, and found that not too many of them make the 300Mhz available to beanually selected, but i do check the voltage used by 300Mhz and its saving is almost neglectible,
and as i do this tweak based on my current kernel set up (InsigniuX), i do it with 633 as base.
as for 1612 being used much,
i found that there's probably a bug in our device kernel code that make cpu sometimes lock in its highest frequency (1804 & 1612), it only happen after you restart the phone, (and it happen with most kernel out there, so its not literally the dev mistake, more like xiaomi messed up some codes)
the fix for now is by opening adiutor, ensuring that the freq not locked up. If its locked, change it back manually to 633 and 1133 (for small and big respectively), i found that it manage to stay until another reboot.
my cpu usage is as how i expected from my target load. so i think it play nicely for now.
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
I am still on first charge since tweaking the kernel. So far it seems that the battery life is going to be the same, but it feels to me that everything is just a bit faster now, app opening and loading times are shorter and a bit smoother, might be a placebo, but it works nice.
One thing you should fix in main post, your target load for 1612 mhz in little cluster is set to 8, but in calculations it is 83, I suppose you missed the 3 when you wrote the tunables
I am going to update the settings you added after it falls to 20% and I recharge it.
One more thing, if I use the Magisk module for thermal and hotplug (or simply turn off the Core control in Kernel manager) does it mean that the cores will go offline if there is no load?
I remember having different hotplug solutions on SD801 devices which actually turned off 3 cores and left only one to do basic functions in deep sleep, or turn on 2 of them when there is low load on the CPU.
@Cirra92 ah right ! i might hit the backspace accidently, LoL
about hotplug, honestly am still testing it myself to figure whether the config work as intended or not, since the behaviour of this chipset it quite different. And since oreo its a bit harder to really track the cpu activities, we need to run an app to see the activities, but the app itself is giving load to cpu, thus the reading might not actually accurate.
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
blackbellz said:
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
Click to expand...
Click to collapse
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
crap, i cant even attach 2 picture in one post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
Can you add an image of the voltage table? The original image is not visible^^
otonieru said:
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
Click to expand...
Click to collapse
i tought this was towards battery but still keeping performance.
Try it or die said:
Can you add an image of the voltage table? The original image is not visible^^
Click to expand...
Click to collapse
Yup, it's not visible. But OP said its visible to him...
raptorddd said:
i tought this was towards battery but still keeping performance.
Click to expand...
Click to collapse
no, its the other way round as i wrote in my main post, LoL. But i guess 9-10Hrs SoT is more thwn enough wasnt it ?