Related
So I found a "new" benchmarking app. PassMark Perfomance Test Beta.
https://market.android.com/details?id=com.passmark.pt_mobile
PassMark is a developer of some PC benchmarks, so I believe them to be reputable programmers. Anyways, it has a slew of testing "stuff" (for lack of a better word), similar to CF-benchmark, but is more well rounded instead of CPU-centered. I would like to see if kernels/roms/etc have any impact on performance in this benchmark.
Here are my scores:
Samsung Droid Charge
GummyCharged 1.9.1
imoseyon 13.3 kernel, voodoo lagfix enabled
100-1400MhZ; I/O-Deadline; Governor: conservative
Loopy Smoothness, V6 Supercharger, 3G Turbocharger
32GB Samsung Class 2 SD
CPU: 1590
Integer Math: 44.8 MOps/Sec
Floating Point Math: 57.3 MOps/Sec
Find Prime Numbers: 24.8 thousand/sec
Random String Sort: 400 thousand/sec
Data Encryption: 232.1 Kbytes/sec
Data Compression: 195.5 Kbytes/sec
Disk: 6843
Internal Storage Write: 73.3 Mbytes/Sec
Internal Storage Read: 23.4 Mbytes/Sec
External Storage Write: 76.9 Mbytes/Sec
External Storage Read: 13.2 Mbytes/Sec
Memory: 1175
Memory Write: 189.7 Mbytes/Sec
Memory Read: 495.2 Mbytes/Sec
2D Graphics: 1646
Solid Vectors: 3515.2 Vectors/Sec
Transparent Vectors: 2567.6 Vectors/Sec
Complex Vectors: 82.4 Vectors/Sec
Image Rendering: 589.8 Images/Sec
Image Filters: 54.3 Filters/Sec
3D Graphics: 2076
Simple: 57 FPS
Complex: 56.8 FPS
Combined Score: 13330
I also have scores from my Galaxy Tab 7 if anyone would like to see them, but I don't have time to post right now.
Seems good, I'll post back in a day or two with my scores, calibrating teh batturiez right now.
Non-oc imnuts kernel on humble 1.51
Sent from my SCH-I510 using Tapatalk
Arrow New (more accurate) Benchmark? Post Scores!
Please delete
kvswim said:
So I found a "new" benchmarking app. PassMark Perfomance Test Beta.
https://market.android.com/details?id=com.passmark.pt_mobile
PassMark is a developer of some PC benchmarks, so I believe them to be reputable programmers. Anyways, it has a slew of testing "stuff" (for lack of a better word), similar to CF-benchmark, but is more well rounded instead of CPU-centered. I would like to see if kernels/roms/etc have any impact on performance in this benchmark.
Here are my scores:
Samsung Droid Charge
GummyCharged 1.9.1
imoseyon 13.3 kernel, voodoo lagfix enabled
100-1400MhZ; I/O-Deadline; Governor: conservative
Loopy Smoothness, V6 Supercharger, 3G Turbocharger
32GB Samsung Class 2 SD
CPU: 1590
Integer Math: 44.8 MOps/Sec
Floating Point Math: 57.3 MOps/Sec
Find Prime Numbers: 24.8 thousand/sec
Random String Sort: 400 thousand/sec
Data Encryption: 232.1 Kbytes/sec
Data Compression: 195.5 Kbytes/sec
Disk: 6843
Internal Storage Write: 73.3 Mbytes/Sec
Internal Storage Read: 23.4 Mbytes/Sec
External Storage Write: 76.9 Mbytes/Sec
External Storage Read: 13.2 Mbytes/Sec
Memory: 1175
Memory Write: 189.7 Mbytes/Sec
Memory Read: 495.2 Mbytes/Sec
2D Graphics: 1646
Solid Vectors: 3515.2 Vectors/Sec
Transparent Vectors: 2567.6 Vectors/Sec
Complex Vectors: 82.4 Vectors/Sec
Image Rendering: 589.8 Images/Sec
Image Filters: 54.3 Filters/Sec
3D Graphics: 2076
Simple: 57 FPS
Complex: 56.8 FPS
Combined Score: 13330
MORE INFORMATION YES, BUT TAKES LIKE 3 TIMES LONGER TO COMPLETE...
My scores are almost the same as the ( ^^^^^^ ) post #3
Click to expand...
Click to collapse
Won't let me install My charge is greyed out on the market page. Running GummyGBE
hoppermi said:
Won't let me install My charge is greyed out on the market page. Running GummyGBE
Click to expand...
Click to collapse
Strange. Have you tried clearing market data?
Sent from my Droid Charge running GummyFroyo 1.9.1
Imoseyon kernel 1 ghz. Humble 1.51.
Sent from my SCH-I510 using Tapatalk
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
Please see post #2 for instructions and change log.
BASICS/PREREQUISITES:
To begin you must unlock, install TWRP, and acquire system files and mods.
Unlocking:
Use the Asus unlocking tool from the downloads section on the Asus TF700 support website. Simply install the .apk, run the app, and follow the prompts.
Installing TWRP:
TWRP can be found here - http://forum.xda-developers.com/showthread.php?t=1797692
Instructions for installing TWRP can be found here - http://forum.xda-developers.com/showthread.php?t=1938129&highlight=root+custom+recovery
NOTE - To boot into TWRP press and hold the power and volume down button until white text appears in the top left corner of your screen. Release both buttons and press volume up.
System Files:
System files and mods can be obtained from the following links. Please thank/donate to the devs for all of their hard work.
CROMi-X [ROM] - http://forum.xda-developers.com/showthread.php?t=2425383
Hundsbuah’s Kernel - http://forum.xda-developers.com/showthread.php?t=2143093&page=80
Data2SD [Mod] - http://forum.xda-developers.com/showthread.php?t=1962507
ROM2SD [Mod] - http://forum.xda-developers.com/showthread.php?t=2501129
CrossBreeder [Mod] - http://forum.xda-developers.com/showthread.php?t=2113150
DATA2SD/ROM2SD:
Data2SD works around poor I/O performance by giving us the ability to utilize a fast microSD card as our primary mode of storage. ROM2SD follows a similar premise as Data2SD; however, it also gives us the ability to dual boot any android ROM compatible with our tablet. The application of these mods results in apps opening faster, faster boot times, faster read/write speeds, and faster downloading/less lag while downloading. Step #1 and Step #2 only need to be followed the first time you apply these mods.
Step #1 - Create GParted Live USB Stick:
In order to run your tablet from a microSD card you will need to reformat it using Gparted (a linux based partition editor) installed on a live USB stick. A live USB stick has the image (.iso file) of a program burnt onto it so that it can be run at boot on a PC.
Find Gparted here - http://gparted.sourceforge.net/livecd.php
Download the live CD/USB image. The easiest tool for burning the image is the LinuxLive USB Creator.
LinuxLive USB Creator can be found here - http://www.linuxliveusb.com/
Download the program and install it. Simply follow the instructions within the program using the Gparted image.
Step#2 - Reformat microSD Card:
This involves booting into Gparted, clearing your microSD of existing partitions, and creating new partitions to store androids /system (ROM, kernel), /data (apps and data), and /media partitions (user data and media files - "sdcard0"), which were previously stored internally.
Boot Into Gparted:
Insert your live USB and microSD card into your PC. To boot into Gparted power on your PC and select one of the "FX" buttons to bring up the boot selection menu (I need to select F9). The live USB will be labelled something like "USB Diskette", or "USB Hard Disk". Select your live USB and follow the prompts to boot into Gparted.
Create Partition for External Storage:
Once Gparted has loaded delete any existing partitions on your microSD card. Next create a primary partition using the Fat32 file system at the very beginning of your card with at least 4Gb of storage (I am using 8Gb). This is recognized and functions as external storage so that we have a place to store flashable (installable) .zips and TWRP backups. It does not contain any data relevant to the functioning of our tablet.
NOTE - Partitions should be aligned to mb and ideally be divisible by 4.
Create Partition for System Storage:
After creating a partition for external storage we need to create partitions for androids /system, /data, and /media partitions. If you plan on using Data2SD you only need to make a second partition. If you plan on using ROM2SD then you need to make 2 additional partitions.
Data2SD - Create a second primary partition using the ext4 file system with the remaining space on your microSD. This partition will contain your /system, /data, and /media partitions. After you have created this partition you will need to flag it to run at boot. Right click the ext4 partition and select “Manage Flags”. Check the box beside “Boot”. You are done reformatting, simply exit Gparted.
ROM2SD - The second partition you need to make will contain your /data and /media partitions. The third partition will contain your /system partition. It only needs enough space to store your ROM and kernel so we will create it first at the very end of the microSD card. Create a primary partition using the ext4 file system with 1Gb of space. After you have created this partition you will need to flag it to run at boot. Right click the ext4 partition and select “Manage Flags". Check the box beside “Boot”. Now create another primary partition using the ext4 file system with the remaining space on your card. You are done reformatting, simply exit Gparted.
Step #3 - Install System Via TWRP:
I do not recommend setting up Data2SD or ROM2SD using old data. Please do a fresh install to avoid issues. I am able to wipe my tablet completely, install my system, set up my apps/data, and apply all of the tweaks in this guide in less than half an hour.
Getting Started:
If using Data2SD please download the "mount-data2sd.zip" file attached to this post (credit @Mistar Muffin). If using ROM2SD please download the "mount-rom2sd.zip" file attached to this post (credit @_that). Move this file, your ROM, your kernel, and any applicable mods to the Fat32 partition on your microSD card. Power down your tablet and boot into TWRP (see basics section for details).
Install Using Data2SD:
Boot into TWRP and wipe everything other than external storage (cache, dalvik cache, data, system, internal storage). To begin setting up Data2SD select CROMi-X for installation. Next choose "mount-data2sd.zip". This resets device nodes so that TWRP will install .zips to our microSD card rather than internal storage. Begin installation once the rest of your .zips are selected (ex - themes, mods, etc). During CROMi-X installation you will be presented with a kernel selection page. In the first section select your desired kernel. In the second section choose the Data2SD compatible option. When installation has finished reboot your tablet and set it up as usual.
Install Using ROM2SD:
Before proceeding check out _that`s ROM2SD thread so you understand how ROM2SD works - http://forum.xda-developers.com/showthread.php?t=2501129. CROMi-X or miniCROMi-X users can utilize the following instructions to install ROM2SD, see the following post if you are dual-booting other ROMs - http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31.
Boot into TWRP and wipe everything other than external storage (cache, dalvik cache, data, system, internal storage). We begin by setting up our tablet to run from internal storage. Select CROMi-X or miniCROMi-X for installation. Hundsbuah's kernel and _that's kernel are available through CROMi-X and are ROM2SD compatible. Next choose any other .zips you need to flash (ex - themes, mods, etc). During CROMi-X installation you will be presented with a kernel selection page. In the first section select a ROM2SD compatible kernel, in the second section choose the 4th option. This installs CROMi-X to your internal storage and allows you to boot to an additional system on a microSD card. Once installation has finished reboot your tablet.
When you reboot you will be presented with the android set up wizard. Go through this as usual and set up you tablet. Once you have finished reboot your tablet back to recovery. Next we will set up our microSD. Select CROMi-X or the ROM2SD compatible version of miniCROMi-X for installation. Next choose "mount-rom2sd.zip". This file updates TWRPs device nodes so that .zips are installed to the correct partitions on your microSD card. Select the rest of the .zips you need to flash and begin installation. Once you reach the kernel selection page in the CROMi-X installer select your desired kernel and the third option in the second section. Once installation has finished reboot your tablet. After rebooting you should be presented with the android set up wizard again.
NOTE - To boot using internal storage remove your microSD card from your tablet and power on. To boot to using your microSD simply put it back in and turn on your tablet.
Creating/Restoring Nandroid Backups:
To create or restore a TWRP Nandroid backup you must first install mount-data2sd.zip or mount-rom2sd.zip. This resets device nodes so that TWRP will correctly backup/restore partitions on your microSD card. The "Backup" section allows you to create Nandroid backups. The "Restore" tool in TWRP allows you to restore Nandroid backups.
Wiping Partitions and Factory Reset:
Boot into TWRP and install mount-data2sd.zip or mount-rom2sd.zip. This resets device nodes so that TWRP will correctly wipe partitions stored on your microSD card. The "Wipe" section can be used to do a factory reset or selectively wipe your dalvik cache, cache, /system partition, /data partition, or internal storage.
NOTE - Partitions are mounted differently after implementing Data2SD/ROM2SD. The Fat32 partition on your microsd is recognized as "MicroSD". The media partition is still mounted as "sdcard0". It can be found in the /system/storage/ directory, along with your tablets internal storage, which is mounted as "sdcardi". If using ROM2SD you internal /data partition can be accessed via the/datai directory.
CPU/GPU FREQ CAPS:
With Hundsbuah's kernel you can set freq caps for the CPU and GPU within each of Asus' power modes (power saving, balanced, performance). The parameters we need to edit can be found in the following files:
cpu1.sh (power saving)
cpu2.sh (balanced)
cpu3.sh (performance)
Which are located in the following directory:
/system/etc/cpuX.sh
To apply the following tweaks a text editor is used to edit lines contained in the aforementioned files. I utilize the editor built into AntTek Explorer Ex.
GPU Frequency Cap:
The following lines set GPU voltage:
logi "echo GPU voltage > core_cap_level"
echo GPU voltage > /sys/kernel/tegra_cap/core_cap_level
To modify the GPU freq cap simply fill the red portion of the above lines with your desired GPU voltage. The GPU voltage determines the GPU freq cap. Here is how Hundsbuah's stock voltage table works, if you modify the voltage table these values will be different:
700 mhz - 1425 mV
650 mhz - 1387 mV
600 mhz - 1350 mV
520 mhz - 1300 mV
484 mhz - 1250 mV
446 mhz - 1200 mV
408 mhz - 1150 mV
361 mhz - 1100 mV
247 mhz - 1000 mV
200 mhz - 950 mV
GPU FPS Limit:
To unlock the GPU FPS limit and change it to 90 add the portion in red to the following lines:
logi "setprop persist.tegra.NV_FPSLIMIT 1"
setprop persist.tegra.NV_FPSLIMIT 1
logi "setprop persist.sys.NV_FPSLIMIT 90"
setprop persist.sys.NV_FPSLIMIT 90
CPU Frequency Caps:
To change the frequnecy caps for each CPU core fill the red portion of the following lines with the desired frequency:
logi "echo Core 1 freq cap > pwr_cap_limit_1"
echo Core 1 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_1
logi "echo Core 2 freq cap > pwr_cap_limit_2"
echo Core 2 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_2
logi "echo Core 3 freq cap > pwr_cap_limit_3"
echo Core 3 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_3
logi "echo Core 4 freq cap > pwr_cap_limit_4"
echo Core 4 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_4
Asus Power Saving Modes:
The following profiles are optimal for specific tasks/uses. They were designed to obtain a lag-free experience based on certain levels of CPU load.
Power Saving - Used for tasks with a moderate to high load for extended periods of time (productivity, browsing heavy websites, streaming video online, heavy multitasking)
- GPU Voltage/Freq = 1425/700
- Core 1/2/3/4 = 1750000
- Quadrant Score - 7400-7500 (Screenshot - https://www.dropbox.com/s/jqdcrwc7t...core - Power Saving Mode (max 1.75Ghz).jpg?m=)
Balanced - Used for tasks with low to moderate load (general use, light browsing, email, media consumption, etc.)
- GPU Voltage/Freq = 1425/700
- Core 1/2/3/4 = 1600000
- Quadrant Score - 6900-7000 (Screenshot - https://www.dropbox.com/s/zlfhnv1jq...ant Score - Balanced Mode (max 1.6Ghz).jpg?m=)
Performance - Used for short intense workloads
- GPU Voltage/Freq = 1425/700
- Core 1/2/3/4 = 1900000
- Quadrant Score - 8000-8100 (Screenshot - https://www.dropbox.com/s/iv5wawq49...ant Score - Performance Mode (max 1.9Ghz).jpg)
INTERACTIVE GOVERNOR TWEAKS:
The CPU governor controls how the CPU scales through frequency steps in response to changes in CPU load. CPU load reflects the difference between our processors current power (increased by freq and voltage - decreased by leakage) and the power needed to effectively process work queued up by the process scheduler. The magnitude and variability of CPU load are important indicators of processor performance. As load increases instances of lag also tend to increase. If we were to graph instances of lag/stuttering and CPU load over time you would see that stuttering happens most when load is high. An unstable, or highly variable CPU load indicates that CPU scaling is not responsive to the demands of the process scheduler; its almost as if scaling is a half-step too late. In this condition scaling is generally erratic, which decreases time spent idling, system stability, and responsiveness. Ideally we want CPU load to be as low and stable as possible as this indicates scaling is working efficiently. The amount of power a CPU can output does not matter; if it is not effectively scaled based on changes in load then lag/unresponsiveness is bound to occur. The following governor tweaks improve the efficiency of CPU scaling. To evaluate their effectiveness Android Tuner was utilized to monitor CPU load, CPU scaling in real-time, total time spent at each frequency step, and core temperature during benchmark tests and actual use. Detailed explanations can be found beneath each tweak.
NOTE - You will need to write an init.d script to apply the following tweaks. See my guide to writing init.d scripts for details - http://forum.xda-developers.com/showthread.php?t=2198510.
NOTE - CROMi-X Users - The following tweaks, aside from max_boost, are applied by default in CROMi-X.
timer_rate - 20000
Sets the rate at which the governor samples cpu load. Lower values result in scaling that is too jumpy. Higher values result in scaling that is not responsive enough.
min_sample_time - 40000
Sets the minimum amount of time spent at a freq step before scaling down. The interactive governor samples CPU load every 2 ms. If the CPU is underpowered core freq is ramped up. Once load decreases the CPU is scaled back down. By default the CPU must spend at least 3 ms at a freq before it can scale down, which does not make sense if the governor is set on a 2 ms timer. A 4 ms minimum downscaling delay makes sense - the timer samples load twice before scaling down. Load tends to fluctuate drastically with touch devices; thus we do not want the CPU to scale down if it is going to have to ramp up again. Having a 2 ms timer allows the CPU to be scaled up quickly, while a 4 ms down scale delay prevents the CPU from downscaling early.
midrange_freq = 760000 - set as close to middle of freq table as possible
Needs to be recalibrated to reflect modified freq caps. If core freq caps are increased midrange freq should be adjusted so that the governor knows how to control the CPU properly.
max_normal_freq = 1300000
Instructs the CPU to jump to this freq when midrange_go_maxspeed_load is reached. For some reason this tweak has had a greater impact on performance than any of my governor tweaks. Before applying this tweak 475 mhz and max frequency are used most while under low/moderate load. After applying this tweak 475 mhz and 1.3 Ghz are utilized more often, as are a wider range of freq steps. Despite spending far less time at max frequency benchmark scores and performance have increased.
max_boost = 1900000 - set to highest freq available
Max boost is a mechanism for clearing a mounting queue as quickly as possible to prevent lag. It will do its job most effectively if we give it as much juice as possible. Controlled by go_maxspeed_load.
NOTE - CROMi-X Users - To apply the above tweak delete or edit the line changing max_boost under "#CPU and VM Tweaks" in sdbags 50CleanTWEAKS init.d script.
midrange_go_maxspeed_load = 65
go_maxspeed_load = 85
Optimal for keeping CPU load low and stable. Through my testing I have found that it is more efficient to adjust freq a little earlier by setting load thresholds lower (65/85) than it is to make adjustments when load has already gotten relatively high. Improves responsiveness without hurting battery life because the CPU spends more time idling.
To implement the above tweaks add the following lines to your init.d script:
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "760000" > /sys/devices/system/cpu/cpufreq/interactive/midrange_freq
echo "1300000" > /sys/devices/system/cpu/cpufreq/interactive/max_normal_freq
echo "1900000" > /sys/devices/system/cpu/cpufreq/interactive/max_boost
echo "65" > /sys/devices/system/cpu/cpufreq/interactive/midrange_go_maxspeed_load
echo "85" > /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
NOTE - Detailed descriptions of each governor can be found at the following link - http://forum.xda-developers.com/showthread.php?t=1369817.
HOTPLUG CONFIG:
The hotplug config in Hunds Kernel allows you to control how CPU cores are brought online as threads are processed. A thread is the smallest sequence of instructions that can be managed independently by a process scheduler. Threads are contained within a process. A process is the execution of instructions contained within a program. On a single processor system multi-threading (multitasking) is generally implemented by transmitting/sending signals over a common path; the processor switches between different threads. This switching generally happens frequently enough that the user perceives the threads or tasks as running at the same time. If the CPU is overloaded and a thread is queued up by the process scheduler then lag/stuttering is likely because thread switching does not occur quickly enough to be hidden from the user. On a multi-core system threads can be truly concurrent, with every processor or core executing a separate thread simultaneously, which decreases the potential for lag/stuttering. If core 1 is busy processing a thread and another thread is queued up by the process scheduler we want an additional core to become active so that core 1 does not have to switch between threads. However, we also do not want to bring cores online needlessly. If a core is able to process multiple threads fast enough such that switching is unnoticeable then it would be inefficient to bring another core online.
NOTE - CROMi-X Users - The following tweak is applied by default in CROMi-X.
To change the hotplug config add the following line to your init.d script:
echo "2 4 6" > /sys/kernel/rt_config/rt_config
Instructs the kernel to bring core 2, 3, or 4 online when more than X threads are active. Core 2 is brought online when 3-4 threads are active, core 3 is brought online when 5-6 threads are active, and core 4 is brought online when 7+ threads are active. Through my testing I have found that a single core running at 475 Mhz has enough power to effectively process a constant low load. If hotplugging values are set lower then the kernel tends to unnecessarily bring additional cores online while in a low load state. If the kernel is told to activate cores later then we begin to notice lag/stuttering due to thread switching.
KERNEL TWEAKS:
The following tweaks directly impact how the kernel controls our tablets hardware.
CPU Frequency Table:
The CPU frequency table sets the frequencies that are available to the CPU. The following tweak modifies the minimum freq step that is available to the CPU, to apply it add the following line to your init.d script:
echo "475000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Through my testing I have found that if an app is open and generating a very low load we cannot utilize frequencies below 475 mhz. If allowed to drop below 475 mhz core freq bounces between 204 mhz and 475 mhz while in an active low load state; which indicates that freq steps below 475 mhz are incapable of handling the load induced by the activation of a foreground app. Preventing the CPU from dropping below 475 mhz increases responsiveness and stabilizes CPU load as the CPU cannot drop to ineffective frequencies. This does not impact battery life because of the design of the Tegra 3 processor. The Tegra 3 has 5 cores; 4 primary fast-process cores and 1 slow-process battery saving core. If our tablet is asleep or idling/inactive (no foreground app) then processing is handled by the low-powered battery saving core. If any foreground app is open our kernel activates a combination the 4 primary cores. Scaling_min_freq has no impact on the battery saving core. Therefore, increasing scaling_min_freq ensures we utilize effective frequencies while in an active state without preventing the CPU from dropping to lower frequencies while inactive.
CPU Voltage Table:
The CPU voltage table sets the voltages that are supplied to frequencies in the frequency table. Processing power is increased by frequency and voltage; while it is decreased by leakage, which is increased by heat. As voltage increases so does heat. Therefore, voltage has a positive and negative impact on processing power. The optimal voltage table balances the costs of reducing voltage with the benefits of reducing heat. When undervolting we want to drop voltages as low as possible without decreasing the load that a frequency step can handle. If voltages are dropped too low the need to jump to higher frequencies negates the benefit of running lower voltages. At this point, stability is also compromised. In order to change your CPU voltage table add the following line to your init.d script:
echo "1337 1300 1275 1250 1225 1200 1175 1150 1125 1100 1075 1050 1025 1000 975 950 925 900 875 850 825 800 775 750 725 700 687 675" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
The voltage table above has been rescaled and undervolted such that heat production is decreased while performance and stability are maintained. Battery consumption correspondingly decreases as less voltage is drawn by each freq step. Lower voltages are used across the entire table yet the undervolting is not very severe, if voltages are dropped any lower the load that each freq step can handle begins to decrease and introduce instability. The lowest and highest freq, where CPU utilization is highest, are undervolted the most. The voltages supplied by the table are optimal for the load each freq step needs to process, which is indicated by improved CPU scaling. CPU load is lower and more stable, low to mid range freq are used more, and upper range freq are used less. The CPU responds to changes in load more appropriately; while in a low load state we are much more likely to jump to a midrange feq than an upper range freq.
GPU Voltage Table:
The GPU voltage table sets the voltages that are supplied to freq in the freq table. Hundsbuah's voltage table is nearly optimal. The voltage supplied to 700 mhz (1425 mV) cannot be dropped without negatively impacting performance. That being said, the voltages supplied to lower freq can be dropped and rescaled such that performance is maintained. The following voltage table reduces heat production and battery consumption without impacting performance and stability. To edit your GPU voltage table add the following line to your init.d script:
echo "1425 1375 1325 1275 1225 1175 1125 1075 1025 975 925" > /sys/devices/system/cpu/cpu0/cpufreq/gpu_voltage_control
I/O TWEAKS:
I/O (input/output) refers to the communication between an information processing system and external sources (users, network cards, monitors etc). I/O operations involve an input device, a processing unit, and an output device. Whether or not a device is classified as input or output depends on one's perspective because many devices can serve as an input or produce output. Within computer architecture the CPU is the processing unit and main memory (RAM) is the output device. Any operation involving the transfer of data to/from this combination (ex - from an SSD) is considered I/O. I/O operations utilize both slow-access bulk storage (ROM) and fast-accesss memory (RAM), which prevents the CPU from processing flows of information at the same rate in both directions. The bottleneck introduced by R/W operations on slow-access storage often underlies laggy/unresponsive performance. I/O scheduling is utilized to avoid lag/stuttering that results from disparate rates of information processing.
Scheduler:
I/O schedulers control the flow of information between input devices, processing units, and output devices. Schedulers utilize algorithms to maximize the efficiency of I/O operations. Thus, I/O performance is significantly impacted by the scheduler that we use. To evaluate each scheduler's performance both Quadrant and Android Tuner were used; Quadrant for global I/O performance, Anroid Tuner for specific R/W speeds. I ran all schedulers through 6 trials in Quadrant and 6 trials in Android Tuner to control for variability in test scores and the effects of confounding variables. Following trials I calculated the mean R/W speed of each scheduler for all tested file sizes. Mean memory, I/O and total Quadrant scores were also calculated. Schedulers were then ranked from 1-6 within the previous measures. Finally, schedulers were ranked globally based on the mean of all within measure ranks. Results are as follows:
1)sio
2)deadline
3)row
4)cfq, noop
5)bfq
While the aforementioned ranks accurately reflect global I/O performance schedulers excel in a different areas. I suggest checking out my data at the following link and selecting the scheduler that is optimal for your system - https://www.dropbox.com/s/iie89tn33qe07j8/Lucius.Zen - IO Scheduler Data.xlsx?m=.
NOTE - CROMi-X Users - The following tweak is applied by default in CROMi-X.
To change your scheduler to "sio" add the following line to your init.d script:
echo "sio" > /sys/block/mmcblk0/queue/scheduler
echo "sio" > /sys/block/mmcblk1/queue/scheduler
NOTE - Detailed descriptions of each scheduler can be found at the following link - http://forum.xda-developers.com/show....php?t=1369817.
NOTE - Additional I/O tweaks can be found in the "I/O Scheduler Tweaks" section in post #3.
Structural/Clerical Section
METADATA:
INTRODUCTION:
Please advance through post #1 in the order I have laid out. I include prompts to links or other sections when necessary. I suggest reading the entire guide before applying any tweaks. See the "Appendix" section (post #3) for additional tweaks, mods, and useful resources.
Kernel Compatibility:
I am running Hundbuah's latest kernel. However, these tweaks should work well with other kernels (ex - _that's kernel).
Android Version/ROM:
This guide is based on the latest version of the android 4.2 ROM CROMi-Xenogenesis by sdbags. The modifications made in newer versions of android should have little impact on the effectiveness of these tweaks.
Init.d Scripts:
CROMi-X and other users can utilize the appropriate scripts attached to post #1 to apply tweaks implemented via init.d. To activate the script simply save it and remove the .txt appendage at the end of the file. See "Step #5: Enable Your Script" in my guide to writing init.d scripts for application instructions - http://forum.xda-developers.com/showthread.php?t=2198510.
Caution:
It is not possible to brick your device by applying the tweaks/mods in this guide. I have done terrible things to my tablet and she still works like a charm. However, I suggest taking a Nandroid backup of your /system, /data, and boot partitions before proceeding (see "Data2SD/ROM2SD" section in post #1).
Disclaimer/Support:
I am not a developer. I am simply an android enthusiast. I can guarantee that if you thoroughly follow the instructions in this guide you will not run into any issues. That being said I will not hold your hand. I have spent an immense amount of time ensuring this guide is incredibly thorough and easy to follow. I welcome all feedback relating to how this guide can be improved and promise I will do all I can to help anyone with issues. However, I have already spent far too many hours preparing this guide. I only ask that you do your best to avoid being a dumbass.
Happy Tweaking!
Lucius
IMPLEMENTATION GUIDE:
The following list outlines how I set up my system on a microSD formatted for ROM2SD (related section - "Data2SD/ROM2SD" - post #1). This roadmap is meant to simplify the overall application of this guide. Detailed instructions can be found in post #1 & #3. System files and installable mods can be obtained through links in the "Basics" section in post #1.
1) Wipe old data for fresh install (see "Data2SD/ROM2SD" - post #1).
- Boot into TWRP
- Install mount-rom2sd.zip (attached to post #1)
- Wipe cache, dalvik, system, data, and internal storage
- Format /data
- Power off
2) Install system and mods (see "Data2SD/ROM2SD" - post #1).
- Boot into TWRP
- Install CROMi-X to microSD
- Install mount-rom2sd.zip
- Install CrossBreeder mod (see "CrossBreeder Mod/AdAway App" - post #3)
- Install Disable_Journal.zip (attached to post #1 - see "Disable Ext4 Journalling" - post #3)
- Reboot System
3) Disable unnecessary apps (see "Disable Apps" - post #3).
4) Modify CPU/GPU profiles (see "CPU/GPU Freq Caps" - post #1).
5) Apply init.d script (attached to post #1 - see my guide to init.d scripting for application instructions - http://forum.xda-developers.com/showthread.php?t=2198510).
6) Disable CrossBreeder's governor & I/O tweaks (See Step #2 in "CrossBreeder Mod/AdAway App" - post #3)
7) Disable boot animation (see "Disable Boot Animation" - post #3).
8) Remap dock keyboard (see "Remap Dock Keyboard" - post #3).
9) Enable AdAway app & reboot when prompted (see "CrossBreeder Mod/AdAway App" - post #3).
CHANGE LOG:
Code:
[B]Feb.24/14:[/B]
- Added "Step #2 - Disable CrossBreeder's Governor & I/O Tweaks" in the "CrossBreeder Mod/AdAway App" section in post #3 - important for CrossBreeder mod users only
- Updated Quadrant scores in the "CPU/GPU Profiles" section in "CPU/GPU Freq Caps" in post #1
- Updated "Implementation Guide" in post #3
- Added note to "Remap Dock Keyboard Section" in post #3 - found APP_SWITCH function that invokes recent apps menu
[B]Feb.21/14:[/B]
- Added "Implementation Guide" section to post #2
- Renamed "Instructions" section in post #2 to "Introduction"
- Edited and cleaned up "Disable Ext4 Journalling" section in post #3
- Updated Power Saving mode Quadrant score in the "CPU/GPU Profiles" section in post #1
[B]Feb.20/14:[/B]
- Added new flashable .zip (Disable_Journal.zip) for disabling journalling - old one wasn't configured for our device - thanks LetMeKnow!
- Updated Quadrant scores in the "CPU/GPU Profiles Section" in post #1 and added screenshots
[B]Feb.19/14:[/B]
- Added "I/O Scheduler Tweaks" section to post #3
- Updated scripts to include aforementioned changes
- Added note to "Scheduler" section in post #1
[B]Feb.18/14:[/B]
- Added "Disable Logging/Logcat" section to post #3
- Updated scripts to include aforementioned change
- Reorganized post #3
[B]Feb.17/14:[/B]
- Added "Disable EXT4 Journaling" section to post #3
- Added "Set GPU FPS Limit" section to "CPU/GPU Freq Caps" in post #1 - thanks LetMeKnow!
- Added "Search Applications Provider" to "Disabled Apps" section in post #3
Updates Related to CROMi-X:
- Updated script for CROMi-X 5.3a compatibility
- Updated "Cromi-X Installer Options" section in post #3
- Added note to "TCP/IP Protocols and Congestion Algorithms" section in post #3
- Added note to "Scheduler" section in post #1
[B]Jan.13/14:[/B]
- Caught up on editing, reformatting, and reorganizing - fewer errors, clearer instructions, increased consistency across post #1-3 - not a single sub section made it out unscathed :)
- Modified intro to post #1
- Changed "Introduction" section in post #2 to "Instructions"
- Added "Init.d Scripts" section to "Instructions" section
- Added Google Search, Search, and User Dictionary to "Disabled Apps" section
- Added link to my TCP congestion algorithm data in "Optimal TCP Congestion Algorithm" section
Updates Related to CROMi-X:
- Updated script for CROMi-X users, please use new script for compatibility reasons - script was altered and renamed as entries in sdbags 50CleanTWEAKS script need to be removed or overwritten for compatibility reasons - see notes below
- Added note to "max_boost" in the "Interactive Governor Tweaks" section
- Added note to "Optimal TCP Congestion Algorithm" in the "TCP/IP Protocols and Congestion Algorithms" section
- Added note at the top of the "Interactive Governor Tweaks" section
- Added note at the top of the "Hotplug Config" section
[B]Jan.5/14:[/B]
- Updated CPU voltage table - midrange voltages rescaled and undervolted more - results in less heat, less battery consumption, greater usage of mid range freq, lower and more stable cpu load, feels more responsive, benchmark scores maintained, no decrease in stability thus far - attachments also updated
- Apologies for the many updates, voltage table tweaking can be finicky, tends to be a work in progress, should be the last for a while
[B]Jan.4/14:[/B]
- Changed top voltage (1.9 Ghz) in CPU voltage table from 1350 mV to 1337 mV as it is running much more stable - attachments also updated
[B]Jan.3/14:[/B]
- Moved "Introduction" to post #2 - ran out of room in post #1
- Added "GPU Voltage Table" section to the "Kernel Tweaks" section in post #1
- Uploaded a copy of the scripts I use - download and remove the .txt appendage to use - see my guide to writing init.d for application instructions
[B]Jan.2/14:[/B]
- Added "CPU Voltage Table" section to the "Kernel Tweaks" section in post #1
[B]Dec.30/13:[/B]
- Added "Disable Boot Animation" section to post #3
[B]Dec.27/13:[/B]
- Updated links to descriptions of governors/schedulers as they were out of date
- Added "Noozxoide Settings" section to post #3
- Added "Optimal TCP Congestion Algorithm" section to "TCP/IP Protocols and Congestion Algorithms" in post #3
- Added note to "Remap Dock Keyboard" section
- Cleaned up "Data2SD/ROM2SD" section
[B]Dec.26/13:[/B]
- Added "Remap Dock Keyboard" section to post #3 - thanks berndblb!
[B]Dec.23/13:[/B]
- Added "TCP/IP Protocols and Congestion Algorithms" to Appendix
- Went through and edited entire guide several times over to make everything as clear and easy to read as possible
[B]Dec.19/13:[/B]
- Added "I/O Tweaks" section
- Updated "Introduction" section (disclaimer)
- General cleaning, editing, clarification
[B]Dec.17/13:[/B]
- Cleaned and updated "Data2SD/ROM2SD" section - thanks _that and Thibor!
- Updated "Caution" section
[B]Dec.16/13:[/B]
- Tested CROMi-X 5.2.3, updated guide to reflect new changes - thanks sdbags!
- Changed "Introduction" section significantly
- General editing, cleaning, and reorganizing - simpler, more concise, easier to understand :)
[B]Dec.15/13:[/B]
- Added max_normal_freq tweak to "Interactive Governor Tweaks" section
- Added scaling_min_freq tweak to "Frequency Table Tweaks" in the "Kernel Tweaks" section
- Moved "CrossBreeder Mod/Ad Blocking" section to post #3
- Fixed typo in "Set CPU Freq Caps" in the "CPU/GPU Freq Caps" section - first line editing core 2/3/4 were improperly labelled as core 1 - copy/paste error, sorry guys
[B]Dec.14/13[/B]
- More editing - Arghhhhhh!!!
- Added "CROMi-X Installer Options" and "Disabled Apps" sections to post #3
- Updated "Special Thanks" section in post #3
- Updated "CPU/GPU Freq Caps" section - dual/quad core modes are no longer needed to increase utilization of the entire freq table - better performance without hurting efficiency or battery life
- Added quadrant scores to "CPU/GPU Profiles" section
- Reorganized "Interactive Governot Tweaks" section - ready to add the most powerful governor tweak thus far
[B]Dec.13/13[/B]
- Added "Disclaimer" section in "Intro"
- Updated Post #2 and #3
- More editing
[B]Dec.12/13:[/B]
- General cleaning, reorganizing, editing
- Ready for more tweaks
[B]Dec.6-11/13:[/B]
- And the updating begins...
- Updated "Introduction", "Basics", "Data2SD/ROM2SD", and "CrossBreeder/Ad Blocking" sections
- Updated "CPU/GPU Profiles" and "Stock (Interactive) Governor Tweaks" section
- Added "Hotplug Config" Section
SPECIAL THANKS:
This guide would not have been possible without the support of the xda community. I would like to take this opportunity to thank the community at large for all of your support. I would also like to formally thank the following individuals:
@Dees_Troy for bringing TWRP to our device.
@scrosler for the original CleanROM.
@clemsyn for his awesome kernel development.
@sdbags for CROMi-X and his incredible support.
@Hundsbuah for Hundsbuah's Kernel and explaining the inner-workings of kernel tweaking.
@_that for ROM2SD, kernel development, and his incessant need to challenge everything that I do. Thank you for helping keep my brashness in check, tolerating my lack of knowledge, and explaining rather than simply lecturing.
@Mistar Muffin for Data2SD
@idcrisis and @fivefour for their CrossBreeder Mod and sticking it to the man.
@buhohitr for the essential. support he provided during my initial foray into the "Android Development" section
@LetMeKnow for GPU fps unlocking, Disable_Journal.zip, sharing his results, and general support.
RESEARCH AND TESTING:
In order to evaluate a tweak I conduct experiments using a pretest-posttest design, which involves comparing mean pretest/posttest scores within and between a test group and a control group. Both groups are subjected to testing before the application of the experimental manipulation to establish an estimate of baseline performance in the measure of interest. Following pretests the experimental manipulation is applied to the test group while the control group is left constant. Posttest measures of both groups are then made. The mean score of both groups in pretests and posttests are calculated. To evaluate the overall effect of the experimental manipulation mean posttest scores are compared between the test and control group. If mean scores in the test group are greater than the control group then it is likely that the experimental manipulation was effective. Statistical hypothesis tests are needed to validate the comparison by ensuring within group variability does not exceed between group variability. If within group variability is higher than between group variability we cannot be sure that our mean scores are actually different. The pretest posttest design gives us the ability to evaluate changes within both groups as well. This is done by comparing mean pretest to protest scores within each group. If the control group made statistically significant improvements between the pretest and posttest this decreases our confidence in the validity of our between group comparison; unless the change within the control group can be accounted for. To create a test and control group ROM2SD was used to install two seperate systems on the same microSD card (32GB Sandisk UHS-1). One install was utilized as the control group, the other was utilized as the test group. Both setups were exactly the same in all respects to ensure accurate comparisons of mean test scores. The tweak being applied represents the experimental manipulation. Each tweak was tested in a separate experiment on a clean system. In between blocks Sd Maid was used to clear caches and junk files and dalvik/cache were cleared via TWRP. Various benchmarking and system monitoring tools were used to measure performance. While benchmarking and system monitoring tools are great they are not perfect. Thus, the effect of each tweak was subjectively tested in real world use for 3 days at minimum. Generally speaking I do not put much faith in others' subjective opinions; however, I make sure I know exactly what to look for with respect to a tweaks impact on performance. This is the point where I ask you to momentarily suspend disbelief, take my word for it, and try these tweaks for yourself. If you think I am nuts after all the more power to you.
Additional Resources
APPENDIX - USEFUL RESOURCES/TWEAKS/MODS:
CROMi-X INSTALLER OPTIONS:
I select the following options during the CROMi-X installation process:
DPI - 200
Launcher - Apex Launcher
Sound Manager - X-Loud Audio Mod (Noozxoide)
Tweaks - Browser2RAM, Zip Align .apks
Apps - AdAway App
Hard Core Tweaks - Force GPU Rendering
DPI Settings:
DPI, or dots per inch, determines how images are rendered across the pixels on your display. Setting DPI to a lower value results in content looking smaller. Changing DPI settings will not impact performance. 240 DPI is standard for most tablets because it makes things easiest to see/use for the widest number of people. 200 is better if you use your tablet as a laptop replacement because more content can be displayed at any given time.
Launcher:
I suggest using Apex Launcher. It has great features that extend functionality if desired. The UI is also incredibly customizable and can be stripped down to the bare essentials. Disabling features and cleaning up the UI is more important to me than adding features. Apex also won an award for top 5 apps in 2012 from xda. Make sure you select "Lock launcher in memory" in Apex's "Advanced Settings".
NOOZXOIDE SETTINGS:
The optimal noozxoide settings depend on the speakers you are using. I am utilizing the following settings for our tablets built-in speaker.
Noozxoide Xlimiter Processor:
- Compress and reduce overload for smooth audio - Enabled
- Select Effect Strength - Hard
Noozxoide Balanced X-EQ Processor, Noozxoide Maxxbass Processor:
- Deliver balanced natural soundstage and premium bass - Enabled
- Digital Presets - Cinema
- Noozxoide VE-Engine - Stongest
Noozxoide Logic Surround ES Processor:
- Create VSUR on practical monitors and widen the soundstage - Enabled
- Create Room Size - Live
CROSSBREEDER MOD/ADAWAY APP:
The CrossBreeder Mod utilizes 5 techniques to reduce lag. See the CrossBreeder mod link in post #1 for further details. From my experience it noticeably improves web page loading speed and the responsiveness of apps relying on mobile networks. It also completely removes ads instead of covering them with the "Web Page Not Availabe" dialogue. In order to enable ad removal you will need the CrossBreeder mod and AdAway app (obtained via the CROMi-X installer or the following link - http://forum.xda-developers.com/showthread.php?t=2190753).
Step #1 - Enable CrossBreeder:
If you did not install CrossBreeder during your system installation download the CrossBreeder mod and move it to your external storage. Boot into TWRP and install CrossBreeder (if you are flashing to a microSD make sure device nodes are set correctly). Wipe cache/dalvik and reboot.
Step #2 - Disable CrossBreeder's Governor & I/O Tweaks:
The CrossBreeder mod implements governor and I/O tweaks that may interfere with the application of the tweaks in this guide. To disable CrossBreeder's governor and I/O tweaks open a root explorer and navigate to the following file:
/system/etc/CrossBreeder
Next remount the /system partition as rewritable (see "Step #5 - Enable Your Script" in my guide to writing init.d scripts for details - http://forum.xda-developers.com/showthread.php?t=2198510). Once your /system partition is mounted as rewritable locate the following files:
/system/etc/CrossBreeder/START_TWEAKING_GOVERNOR
/system/etc/CrossBreeder/START_TWEAKING_IO
And change their name to:
/system/etc/CrossBreeder/STOP_TWEAKING_GOVERNOR
/system/etc/CROssBreeder/STOP_TWEAKING_IO
Step #3 - Enable AdAway App:
Once you have rebooted open the AdAway app. Select "Download Files and Apply Ad Blocking". Reboot your system when prompted. All ads should now be completely removed.
REMAP DOCK KEYBOARD:
To remap the dock keyboard we need to edit the following file using a text editor:
/system/usr/keylayout/asusdec.kl
I suggest backing up this file to an additional location before you begin editing. To remap a particular key simply delete the function to the right of the key's number and replace it with the desired function. Once you are done editing save the file and reboot your tablet.
EXAMPLE:
key 142 SLEEP WAKE UNLOCK
key 142 FORWARD_DEL WAKE UNLOCK
NOTE - Invoking the APP_SWITCH function opens the recent apps menu.
NOTE - The files below asusdec.kl contain the keyboard mappings for various external keyboards (ex - generic PC keyboards). I suggest checking out these files as they contain numerous functions that can be remapped to our keyboard dock (ex - escape).
NOTE - For a list of useful keyboard shortcuts see the following thread - http://www.transformerforums.com/fo...list-shortcut-keys-keyboard-dock.htmlhortcuts
DISABLE APPS:
Disabling the following apps will not impact basic functionality, cause instability, or boot looping. However, I primarily use my tablet as a laptop replacement; therefore, I offload many functions that I find better suited to my phone (ex - location based anything, lockscreen, daydream, etc).
Asus Battery
Asus Sync
Basic Sleep Mode Apps
Bluetooth Share
Calculator
com.android.backupconfirm
com.android.lockscreen
com.android.providers.partnerbookmarks
com.android.sharedstoragebackup
com.asus.pcsynclauncher
com.asus.quicksearch
com.asus.youtubesearch
com.google.android.voicesearch
Gallery
Google Backup Transport
Google Partner Setup
Google Search
Google Text-to-speech Engine
Live Wallpaper Picker
Market Feedback Agent
Mobile Data
Mobile Network Configuration
MusicFX
Network Location
Photo Screensavers
Search
Search Applications Provider
Setup Wizard
Setup Wizard
Sound Recorder
Talkback
User Dictionary
Wi-fi Direct Share
DISABLE BOOT ANIMATION:
Disabling the boot animation significantly reduces heat production and battery consumption brought about by the boot sequence. Core temperature ranges between 44-46 degrees celsius following a cold boot with the boot animation enabled. Core temperature ranges between 38-40 degrees celsius following a cold boot with the boot animation disabled. To disable the boot animation add the following line to the bottom of your build.prop file (found in the /system directory) using a text editor:
debug.sf.nobootanimation=1
DISABLE EXT4 JOURNALLING:
The ext4 file system utilizes journalling as a safeguard against data loss. A journalling file system keeps track of write operations in a journal before committing them to storage. In the event of a shutdown brought about by a system error it is possible for write operations to be interrupted, which may introduce inconsistencies in the file system. Instead of doing an entire file system check the journal is examined for write operations that were potentially interrupted. Thus, journalling allows ext4 file systems to quickly recover from crashes as entire file system checks can be avoided. However, write operations cannot be executed until the journal is updated and actively maintaining a journal requires memory and processing resources. Therefore, disabling journalling is advantageous from a performance perspective. I have found that disabling journalling reliably produces an increase in performance. To test I ran through 5 trials in Quadrant with journalling disabled and 5 trials with journalling enabled. On average disabling journalling increased total score by 88.2 points. The minimum and maximum total scores out of 5 trials were also much higher with journalling disabled. These results suggest that disabling journalling is a reliable way to improve performance. Follow the steps below to disable journalling:
Step #1:
Download Disable_Journal.zip (credit - @LetMeKnow) from post #1 and move it to your microSD card.
Step #2:
Boot into TWRP and install Disable_Journal.zip (if you are flashing to a microSD make sure device nodes are set correctly). Wipe cache/dalvik and reboot.
DISABLE LOGGING/LOGCAT:
Logcat, the android logging system, provides a mechanism for collecting and viewing system debug output. Various logs from applications, portions of the system, and kernel are recorded in logcat so that users can debug system failures/crashes brought about by errors in processes. Thus, logcat can be an incredibly useful tool for developers, testers, and advanced users. However, maintaining logcat involves recording thousands of lines of data as processes are executed, which requires system resources. Despite logcat's usefulness as a debugging tool it negatively impacts performance. To test I ran through 5 trials in Quadrant with logcat disabled and 5 trials with logcat enabled. On average disabling logcat increased total score by 20.2 points. The minimum and maximum total scores out of 5 trials were also higher with logcat disabled. Therefore, disabling logcat is advantageous for users who do not require advanced debugging capabilities. To disable logcat add the following line to you init.d script:
rm dev/log/main
I/O SCHEDULER TWEAKS:
The following tweaks improve I/O performance by modifying parameters that control the behaviour of the I/O scheduler. Detailed explanations can be found beneath each tweak.
iostats - 0
Disables I/O stats, which reduces overhead.
rotational - 0
Optimizes I/O scheduler behaviour for non-rotating storage. Scheduler no longer uses logic meant to reduce seek times.
rq_affinity - 1
Forces the kernel to process I/O requests on the CPU core that issued the request. Improves the effectiveness of CPU data caching.
nr_requests - 1024
Increases the size of the I/O request queue so that more requests can be sorted before execution.
read_ahead_kb - 6144
Increases the size of the read-ahead cache, which improves the reading of sequential data.
To evaluate the effectiveness of the above tweaks I compared mean R/W speeds of various file sizes following the application of each tweak. The above parameters represent independent variables (experimental conditions) and R/W speed, measured via Android Tuner, represents the dependent variable. I subjected each experimental condition to 5 trials to control for variability in test scores. In the first set of trials no tweaks were applied in order to establish a baseline measure of R/W speed (baseline condition). After establishing baseline performance each tweak was applied and tested in a sequential manner (experimental conditions C0-C4). Following trials the mean R/W speed of each file size was calculated for each experimental condition. In order to compare the impact of each tweak the total mean R/W speed of each experimental condition was also calculated. Global R/W speed increased sequentially following the application of each experimental manipulation. These results suggest that all of the aforementioned tweaks have a positive and measurable impact on I/O performance. You can find an excel chart detailing my results at the following link - https://www.dropbox.com/s/ezkbenk1ruql9rt/Lucius.Zen - Scheduler Tweaks Data.xlsx?m=.
To apply the above tweaks add the following lines to your init.d script:
MMC=`ls -d /sys/block/mmc*`;
for i in $MMC;
do
echo "0" > $i/queue/iostats;
echo 0 > $i/queue/rotational;
echo "1" > $i/queue/rq_affinity;
echo 1024 > $i/queue/nr_requests;
echo "6144" > $i/queue/read_ahead_kb;
done;
echo "6144" > sys/devices/virtual/bdi/179:0/read_ahead_kb
TCP/IP PROTOCOLS AND CONGESTION ALGORITHMS:
TCP/IP is a core set of communication protocols used to transfer data over the Internet and similar networks. IP packets are the vehicle devices use to transfer data between an application program and a web host. They are comprised of a header, which contains the source/destinatin address (among other things), and a payload, which contains the actual data. TCP, part of the transport internet layer, provides intermediate communication between an application and a host. When sending large chunks of data a program can issue a single request to TCP instead of breaking down data into a series of IP packets and requests.
Due to network congestion and other factors IP packets are often lost. TCP maintains the ordered delivery of packets by detecting packet loss, requesting retransmission, reordering data, and minimizing network congestion. When a host receives a stream of packets it reassembles the data into the sequence that was originally sent. Once the receiver confrims the soundness of the data it sends a packet acknowledging its retrieval. To avoid overloading the connection between a program and a host this aknowledgement must occur before more packets can be sent/recieved.
For each connection TCP maintains a congestion window. The TCP congestion window is maintained by the sender and is used to prevent network congestion/overload due to packet loss. When packet aknowledments are received the size of the TCP congestion window increases exponentially until a timeout occurs or the receiver reaches its bandwidth limit. Thus, as more packets are acknowledged the maximum segment size (specifies the largest amount of data in a single TCP segment) of the congestion window becomes larger; every round-trip time the maximum segment size effectively doubles. A mechanism called "slowstart" controls the maximum segment size of the TCP congestion window. To prevent network overload TCP congestion avoidance algorithms modify TCP window size, "slow-start", and the slow-start threshold. Thus, TCP congestion avoidance algorithms have a significant impact on the speed of packet delivery between an application program and a web host.
Optimal TCP Congestion Algorithm:
NOTE - CROMi-X Users - The following tweak is applied by default in CROMi-X.
My research and testing suggests that "lp" is the optimal TCP congestion algorithm. Although "westwood" produces marginally higher download/upload speeds (see the following post - http://forum.xda-developers.com/showpost.php?p=48088128&postcount=1884) "lp" results in a stronger connection between an application and a host; which is indicated by fewer timeouts, lost connections, and more responsive web browsing. This leads to the best overall user experience. To change your TCP congestion algorithm to "lp" add the following line to your init.d script:
/system/xbin/sysctl -w net.ipv4.tcp_congestion_control=lp
I salute you just for write this up. Thanks!!!! :good::good:
Thank you very much for this very detailed guide :good:
Thanks so much for this write up :good: just one question with regards to vsync, there seenms to be a lot of people that have experienced battery drain and/or screen tearing (especially during gaming) when disabling vsync, have you noticed this with the tf700?
yew123 said:
Thanks so much for this write up :good: just one question with regards to vsync, there seenms to be a lot of people that have experienced battery drain and/or screen tearing (especially during gaming) when disabling vsync, have you noticed this with the tf700?
Click to expand...
Click to collapse
I cannot report on the effects of disabling vsync on gaming because I do not play on games on my tablet. I havent experienced excessive battery drain or screen tearing during any benchmarks or stress tests that ive used. I dont experience any while watching a 1080p youtube video in a floating browser while reading multiple articles on the web with lots of pinching and zooming. If i were going to ever experience screen tearing, I imagine that would do it lol.
lucius.zen said:
I cannot report on the effects of disabling vsync on gaming because I do not play on games on my tablet. I havent experienced excessive battery drain or screen tearing during any benchmarks or stress tests that ive used. I dont experience any while watching a 1080p youtube video in a floating browser while reading multiple articles on the web with lots of pinching and zooming. If i were going to ever experience screen tearing, I imagine that would do it lol.
Click to expand...
Click to collapse
Thanks, will give it a try.
I'm pmr there is an option for compressed ram, what choice do you use?
Sent from my MB865 using xda app-developers app
yew123 said:
Thanks, will give it a try.
Click to expand...
Click to collapse
I don't think you can disabled vsync on tf700. Even if you disable vsync in PMR it does nothing.
Great guide. Is there any way of making a flash able zip so we don't have to re do it all when we upgrade rom?
Sent from my Xperia S using XDA Premium HD app
ishamm said:
Great guide. Is there any way of making a flash able zip so we don't have to re do it all when we upgrade rom?
Sent from my Xperia S using XDA Premium HD app
Click to expand...
Click to collapse
+1 and an uninstall zip
Sent from my ASUS Transformer Pad TF700T using xda premium
Where exactly in the internal storage do the zip files for apps go if you have data2sd enabled?
---------- Post added at 05:06 PM ---------- Previous post was at 04:46 PM ----------
And has anyone else had an issue where the network tweaks cause your Wifi to be disabled? I had to stop using them because of this.
gvsukids said:
I'm pmr there is an option for compressed ram, what choice do you use?
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Only tweaks that are included are mentioned. Dont implement zram compression. Its an old optimization meant for lower end devices. It will reduce performance rather than improve it.
buhohitr said:
+1 and an uninstall zip
Sent from my ASUS Transformer Pad TF700T using xda premium
Click to expand...
Click to collapse
I include instructions on creating rescue packages in my guide, i will upload my .zip for PMR today.
primaleph said:
Where exactly in the internal storage do the zip files for apps go if you have data2sd enabled?
---------- Post added at 05:06 PM ---------- Previous post was at 04:46 PM ----------
And has anyone else had an issue where the network tweaks cause your Wifi to be disabled? I had to stop using them because of this.
Click to expand...
Click to collapse
I include instructions on how each partition and storage point is mounted in data2sd, see the "Note" at the end of Step #3.
buhohitr said:
I don't think you can disabled vsync on tf700. Even if you disable vsync in PMR it does nothing.
Click to expand...
Click to collapse
It doesnt have any impact on benchmark scores but I noticed flash elements in web pages were rendering faster with it enabled, especially when maximizing fullscreen flash videos. It used to take 3 sec for the GPU to render a streaming flash video when switched to fullscreen, now it takes around .8s.
I used to hate using flash. Which sucks, bc i use flash a lot, so I have spent a lot of time trying to optimize web browsing and flash. It still isnt perfect, but at least performance and stability are comparable to a laptop now. It just works better. At least it does exactly what you expect, no more errors, or unresponsiveness. The experience of consuming media over the web is much better overall after implmenting all my tweaks.
IF YOU HAVE A QUESTION, PLEASE REREAD THE INSTRUCTIONS IN DETAIL BEFORE ASKING IT.
I have answered 4 questions already that I really did not need to answer. The answers were already included somewhere in my guide. I dont mind answering questions, however, i wrote the guide with so much detail for a reason lol. The answers are there, please make sure you are thorough when reading my guide, I was quite throrough when I wrote it .
primaleph said:
Where exactly in the internal storage do the zip files for apps go if you have data2sd enabled?
---------- Post added at 05:06 PM ---------- Previous post was at 04:46 PM ----------
And has anyone else had an issue where the network tweaks cause your Wifi to be disabled? I had to stop using them because of this.
Click to expand...
Click to collapse
I havent had any network connection issues any my internet is terrible. I get a max download speed of 1.2 mb and only 50% signal strength in my bedroom. I have actually noticed wifi performance is better. Webpages open instantaneously, like apps do. Loading a new page in xda.com takes less than one sec, it basically happens instantly. Right now my signal is full strength, webpages are loading really fast, and streaming stuff is a pleasure. When I get my new phone I will definitely do up a video review on wifi performance and web browsing so you can see how fast web pages load.
ishamm said:
Great guide. Is there any way of making a flash able zip so we don't have to re do it all when we upgrade rom?
Sent from my Xperia S using XDA Premium HD app
Click to expand...
Click to collapse
I have had some issues creating a flashable .zip for PMR tweaks, the method I thought I could use doesn't work the way I anticipated. If I can figure this out I will post it, however, in the mean time it is really easy to apply the tweaks yourself. Now that I know which tweaks to apply it takes less than 5 min. Once youve done it twice you should have it memorized no problem
Some budding devs like me and some others have asked this question and got this answer!
Firstly I want to thanks all who supported me!
My Parents for buying me an Android Device and Supporting
-CALIBAN666- for his thread
franciscofranco for his definition on zRam
abhisahara
Sniper Killer
And all those whom I have forgotten to mention!
Originally posted by Wikipedia
Q: What is zRam?
A: zRam is a module of the Linux kernel, previously called "compcache". zRam increases performance by avoiding paging on disk and instead uses a compressed block device in RAM in which paging takes place until it is necessary to use the swap space on the hard disk drive. Since using RAM is faster than using disks, zRam allows Linux to make more use of RAM when swapping/paging is required, especially on older computers with less RAM installed.
Google has also said to enable zRam as default for Chrome OS Devices!
Click to expand...
Click to collapse
Originally posted by franciscofranco
The zram module creates RAM based block devices: /dev/ramX (X = 0, 1, ...).
Pages written to these disks are compressed and stored in memory itself.
These disks allow very fast I/O and compression provides good amounts of
memory savings.
Basically is for storing swapped pages into compressed memory ram.
Click to expand...
Click to collapse
-CALIBAN666- said:
I think its better to Post this here,when its not better,than sorry!!!
-----------------------------------------------------------------
Once a brief statement for those who are not traveling so long in the Android scene:
ZRAM = ramzswap = Compcache
In order to explain more precisely ZRAM first need other terms are more clearly defined:
Swap can be compared with the swap file on Windows. If the memory (RAM) to complete the PC the data that are being used not actively outsource (eg background applications) so as to re-evacuate RAM free. To this data is written to a hard disk. If required, this data is then read back from there easily. Even the fastest SSD is slower than the RAM. On Android, there is no swap!
In ZRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (ZRAM). So a kind of swap in memory.
This Ram is more free because the data then only about 1/4 of the former storage requirements have. However, the CPU has to work in more because they compress the data has (or unpack again when they are needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC.
In normal PC would look like this:
Swap = swap file (on disk) -> Slow
ZRAM (swap in RAM) -> Faster than swap
RAM -> Quick
With Android, there is no swap partition, and therefore brings ZRAM also no performance boost.
The only thing that brings ZRAM is "more" RAM. Compressed by the "enlarged" so to speak of the available memory. That's on devices with little RAM (<256MB) also pretty useful. The S2 has 1GB but the rich, and more than. There must not be artificially pushed up to 1.5 GB.
After you activate the ZRAM also has 2 disadvantages. The encoding and decoding using CPU time, which in turn has higher power consumption.
Roughly one can say (For devices with more than 512MB RAM):
Without ZRAM: + CPU Performance | + Battery | RAM
With ZRAM: CPU Performance |-Battery | + RAM
For devices with too little RAM so it makes perfect sense. But who shoots the S2 already be fully complete RAM and then still need more?
Check whether you can ZRAM runs in the terminal with
free or cat / proc / meminfo
I hope it helps to understand zRam!!!!
Click to expand...
Click to collapse
So basically zRam module in kernel increases and optimizes performance!
I didn't write all this information, I just compiled it together in one thread for ease :fingers-crossed:
But making it work is an headache.. you have to add LZO(Lempel–Ziv–Oberhumer) compression through menuconfig and then run zRam scripts through init.d and what not..
robowarrior1377 said:
But making it work is an headache.. you have to add LZO(Lempel–Ziv–Oberhumer) compression through menuconfig and then run zRam scripts through init.d and what not..
Click to expand...
Click to collapse
This thread is a information share thread
It is not a thread in how to enable it in your kernel -_-
Thanks for the info
Sent from my GT-N8000 using xda premium
Zram = extravagant battery
so it makes wasteful battery zram?
excuse me if my English is poorly
gj man thanks for info very helpful :good:
Change the first line of the thread.
I represent a test set of scripts for the automating kernel configuration.
Written and tested on version 3.4.33 [Kernel]FlashBeatsReloaded v3.4.33 OC 1,56Ghz AROMA.
"Having played enough" programs Trickster MOD, Faux123 Kernel Enhancement and similar, I has decided that it is necessary to simplify the process of installing the best, in my opinion, parameters for the kernel when the smartphone turns on. I love experimenting and having fun testing a majority of ROM and kernels. To reduce the "manual work" after reinstalling the ROM/kernels, I did this file.
The installation via TWRP, the presence of pre-installed support INIT.D necessary.
I express my sincere gratitude to users 4PDA.RU and XDA forums for a huge amount of background information and examples of various settings.
I thank all those whose work and experience has helped me to write the script.
Special thanks to the user Thestealth2, which is developing the project [Kernel] FlashBeatsReloaded.
Functions, performed by the script:
Performing FSTRIM for partitions /system, /data and /cache. Analogue "LagFix (fstrim)", but without the "unnecessary" actions and attitudes.
Disabling some "kernel sleepers"
Running the generator of entropy. Analogue - "Seeder"
If the kernel presence ZRAM support, activates the swap file on 200 MB.
Various tweaks related to EXT4 file system and database files format SQLite.
Setting the minimum and maximum CPU frequency
Installing the CPU governor to Ondemand and tuning the power save mode
Installing the I/O Scheduler to ROW and its setting
Installing the GPU governor to Ondemand and configure it
Setting the read ahead buffers to 2MB for internal and external memory
Other tweaks
PS: Criticism, suggestions, etc. welcome.
PPS: I'm not trying to impose someone my opinion, just show one way of the setting options.
Sounds good, will give it a try later on.
Thanks for your work!