Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
Introduction
I've been meaning to share this with the whole Android community. It seems unfair that only the i9000 folks have access to the vast research that I've done so far. Hence I'm sharing this in the general Android thread in hopes that it'll benefit everyone in the long run
A lot of people often asked about how Android really works and the optimizations can be made to their Android to make it perform better in terms of:
- battery life
- raw performance
- GUI smoothness
With Android based on Linux, and with the experience I have with Linux/Unix (I deal with Unix/Linux on a daily basis for my work) I managed to find some tweaks that we can do to optimize our phones.
I also hope that people will experiment with the tweaks posted here and feedback to me if there are certain ways that I'm doing incorrectly or there are better ways than what I've posted here.
Script tweaks
There are a lot of scripts in XDA that specifically uses the optimizations (Linux or Android based) that I will explain below to actually increase performance/battery life. However, you need to know what those scripts do before using it.
I've done some reviews of the script here:
Script Reviews by Pikachu01
There are good scripts that are properly tested and made sure that it works. It's a script by Zacharias maladroit, the kernel dev who makes the platypus kernel for CM7 and snail kernel for i9000. I modded it to be compatible with i9000 and it'll probably do more than some of the scripts I reviewed
From there, I've also taken the liberty of modifying it some more based on my knowledge and research I've done. It's called ThunderBolt!:
LINK
Now onwards to what actually goes on beneath the hood.
Android Governors
Some custom kernels provide customized governors for you to choose. These are currently known:
- Ondemand (CPU scales to the highest frequency immediately after a certain CPU threshold)
- Conservative (CPU scales to the highest or 1 scale lower than that after a certain threshold gradually and scales down if CPU is below a certain threshold
- OndemandX (Has sleep codes that scales down the CPU when device is asleep. Threshold is set to scale slower)
OndemandX
OndemandX has a suspend frequency that it maintains when the phone is sleeping. It does have a known issue of waking up too slowly when a call comes in.
Conservative
Conservative is used when you would like the CPU to scale to the maximum through each frequency slowly before reaching the maximum. It saves more battery at the expense of smoothness. There are a few tunables that can be configured in Conservative governor, namely the freq_step and both the up and down thresholds.
freq_step is a tunable that determines how much frequency (a percentage of the maximum frequency of your device) to increase at each sampling rate. e.g. you have 5 as freq_step and your maximum frequency is 1GHz. At each sampling rate, it'll increase by 50MHz. If your current frequency is 100MHz, it'll increase to 150MHz at the next sampling. What if your device doesn't support 150MHz? This is done by splitting time between 100MHz and 200MHz (assuming your next frequency is 200MHz) so that in average, your phone is performing at 150MHz.
The up_threshold is how much threshold to wait for before increasing the base frequency to the next freq_step. I.e. if it is 80, the CPU will wait until it is 80% loaded before increasing the frequency. The down threshold is the opposite of up_threshold, which is the threshold to wait until the CPU downscales the frequency to the next frequency step.
Ondemand
Ondemand is a governor that basically a simpler version of conservative. One difference is that it scales to the maximum frequency after load has exceeded a threshold. This is usually 80. After that, it looks at the load again when it's at the max frequency. If it's below 80 (example), it'll scale down one frequency step. The frequency step mentioned here is the available frequency step. I.e. if your device has frequencies of 100,200,400,800 to 1GHz then it'll scale down from 1GHZ to 800, 400 then 200 and 100.
One optimization I have for Ondemand for i9000 TalonDev is that I tuned it to be 80 rather than 65. I have not felt any slowdowns from using this setting and it saves a tiny bit more battery. You can experiment on this value however you want, but bear in mind that I'm not responsible for any slowdowns or damage that is caused by it. Read up a bit more on thresholds to know more (Google it).
I/O scheduler tweaks
Another tweak that can be done is the I/O scheduler tweak. Some kernels come with a few standard I/O schedulers while others have extra schedulers that you can choose from. I'll explain the few that I know and if you have more information on the schedulers, you can post it here for everyone to discuss/share
CFQ - Completely fair. Most will come with this, but this is not optimized for android. Some kernels do optimize it and use it.
Noop - Simple and least overhead of all I/O schedulers. Produces the best outcome for some cases and some do swear by it. It's downside is that it is easily bogged down by high I/O transactions.
Deadline - Optimized for mobile-like devices like Android. Also, some do swear by this. If its writes_starve sysfs is tweaked to be fair, it's the same as SIO.
SIO - It's a fair deadline scheduler. It's the best scheduler. Nuff said.
VR - A newer I/O scheduler that places penalty on reverse seeks. Not for flash drives, though the R penalty can be tweaked to be a multiplier of 1. Even if this is done, it has a high overhead.. Read more here: http://www.gelato.unsw.edu.au/IA64wiki/IOScheduling/VRscheduler
BFQ - Too high of an overhead, it is optimized for spindle disks.
You can pick and choose from Voltage Control or other UV/OC apps and apply it immediately to feel the difference.
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.
CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.
Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.
SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.
In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)
SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)
The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.
LowMemoryKiller
The LowMemoryKiller is a constant debate between more free RAM and more multitasking capabilities as free RAM (more than 60MB free) is actually wasted RAM. The fact is SGS only has a puny amount of RAM left after a few big chunks are allocated to the Graphics, Modem, Sound and Video (and some others that I do not know a lot about). With that knowledge, Samsung decided to give the SGS SL a bigger amount of RAM when they released it ( about ~650MB of RAM read that from somewhere, can't remember).
The LowMemoryKiller is actually a feature in the Android OS for better memory management.
You can read about it more here:
http://forum.xda-developers.com/showpost.php?p=5442369&postcount=1
This is an important feature due to the perennial problem of having low free memory causing lagginess and slowness in launching apps. When you have free memory lingering around the number of 40MB or less, the Android OS just lags like hell.
What this would mean is, you would want to tweak the LMK to not have the situation of it having less than 40MB (or even close to that).
The modern Linux machine in the Android ecosystem relies on a mechanism called Low Memory Killer (LMK) to consistently free up RAM. This is due to Android's internal mechanism of caching apps (and never fully exiting them) when you press the back button. This is to enable faster app switching and provide a seamless experience for apps usage model. Android also, by itself will also constantly look for often used apps to cache them for faster app opening. This will happen even before your system fully boots.
Now, when you mention LMK, the most obvious thoughts that come up are minfrees and Out Of Memory (OOM) groupings. Yes, those two are integral parts when it comes to LMK. The issue here is that no one actually mentioned that there are two LMK systems in Android, that being:
- Linux LMK
- Android Dalvik VM LMK
Both are separate entities that kills/removes app/dalvik cache from RAM when RAM reaches a certain level.
What confuses most people (including me) is that the OOM groupings of both mechanisms have the same names being (Android 2.3 based):
LMK App Categories
FOREGROUND_APP: Your apps in the foreground, being used currently, interfacing with the user.
VISIBLE_APP: Visible app that is still viewable by the user, but not interacting with the user, example could be apps that reside in the status bar, and giving live information i.e. Os monitor graphs.
PERCEPTIBLE_APP: App that the user can still perceive i.e. Music app that is playing music.
HEAVY_WEIGHT_APP: RAM heavy apps that are not being interacted with, but will be a pain to load if its information is cleared in the memory.
SECONDARY_SERVER: App that acts as a secondary server. Not sure what this really means, but client-server thingy but secondary? Could be something that syncs with an app, but is not syncing currently?
BACKUP_APP: App that is currently making a backup (like Titanium backup?)
HOME_APP: Your launcher.
HIDDEN_APP: An exited app that still significant residual memory in the RAM. Exited only some time ago, or is constantly used by the user.
EMPTY_APP: An exited app that only has small remnants of residual memory in RAM. App that is exited quite some time ago.
Take note that this is my understanding of the OOM groupings. If there are mistakes, please correct me
Tuning LMK
Both the LMK and Dalvik VM has this groupings and they can be tunable by using prop and lowmemorykiller/parameters/adj respectively.
One errata about this is that the Dalvik LMK has one extra tunable which is CONTENT_PROVIDER, which affects widgets that are not currently refreshing or displaying information. The ADJ (which I will explain later) is not available to be tuned though. And it is clearly missing from the Linux LMK.
The ADJ is the so-called priority of the app categories, with 0 being the highest (should not be killed) and 15 being the lowest (should be the first to be killed). I haven't seen values other than 0-15 but I have a feeling that the numbers are arbitrary, and can be extended up to 65535, but who would want to do that since they're only 9 app categories
LMK are specified by pages, with memory = 4 * pages.
e.g.
4096 pages represents 16MB RAM (16 *1.024)
From the Linux LMK source code, the parameters can be adjusted as such:
Code:
* For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill processes
* with a oom_adj value of 8 or higher when the free memory drops below 4096 pages
* and kill processes with a oom_adj value of 0 or higher when the free memory
* drops below 1024 pages.
Take note that the oom_adj so far takes only 6 values (although I am confident that it can take more than that). Haven't experimented enough to validate that, but I shouldn't need to as assigning different oom_adj should be a given for all the app categories. This is to make the LMK intelligent enough to determine which app to kill first rather than grouping different app categories into one priority, in which a lot of popular LMK settings that devs provide do that.
And for the Dalvik LMK, my understanding is that it will remove all dalvik caches of <INSERT_APP_CATEGORY_ADJ> or higher if free RAM/pages reaches the level specified.
Hence, two things are learned here:
- Linux LMK will kill an app category of that particular RAM level or higher if free RAM drops below a certain level e.g.
Hidden_APP has a minfree of 16384 pages. If pages fall below this level, Empty_App will be killed first, free pages is recalculated, then if RAM is still below that, Hidden_Apps will be killed next.
- Dalvik LMK will clear all dalvik caches in RAM of all the App category if free RAM reaches the level e.g.
SECONDARY_SERVER_MEM is 8192 pages. When RAM reaches 8192 pages, all SECONDARY_SERVER caches are cleared.
Best Practices
Now, how do we tweak both so that it is efficient in doing its job, i.e. LMK.
From my experiments I can safely say that:
- Below 60MB free RAM you will feel lag 5-10% of the time.
- Below 52MB free RAM you will feel lag 5-15% of the time.
- Below 46MB free RAM you will feel lag 15-20% of the time.
- Below 42MB free RAM you will feel lag 20-50% of the time.
- Below 36MB free RAM you will feel lag 100% of the time.
The experience of lag increases exponentially from 60 down to 36MB. Hence, the LMK should be tweaked against that.
Also, it is considered best practices to group oom_adj settings of Linux LMK with the Dalvik LMK as when free RAM drops to that level, both the Linux LMK and Dalvik LMK will work together to free up at both sides.
The 6 oom_adj that can be tuned for Linux minfree also need to be tuned correctly, failing this would make the LMK too aggressive/under aggressive in mid levels (even if your EMPTY_APP is aggressive, if your oom_adj is selected incorrectly, you'll get to a point where memory leak occurs).
Talon LMK - This is obsolete, TalonDev is using ThunderBolt! LMK from 0.5.x
Take for example, the Talon default LMK setting where:
LMK_ADJ is 0,1,2,3,7,15.
It's EMPTY_APP is 15
It's HIDDEN_APP is 5
It's HEAVYWEIGHT, SECONDARY and BACKUP is 3
Last three values of MINFREE is 4096, 9216, 12288.
Where's the issue here? If you noticed it congrats.
If you didn't, here's the issue:
The minfree 12288 is tied to EMPTY_APP which has a OOM_ADJ of 15.
The minfree 9216 is tied to nothing but has a OOM_ADJ of 7
The minfree 4096 is tied to HEAVYWEIGHT,SECONDARY and BACKUP with the OOM_ADJ of 3.
The LMK_ADJ is important as it represents the checkpoints where the Linux kernel will check for minfrees and kill them. Here's a situation:
Memory is below 12288 pages, OOM is triggered and Linux looks for EMPTY_APP to kill and kills all of them. Job done. Memory is back to >12288 pages.
After a few days, memory is below 12288 pages again, OOM kills all EMPTY_APP, but free memory is still lower than that. It sees if the next checkpoint is fulfilled, which is 9216 pages, and yes memory is still below 9216 pages. It looks for an OOM_ADJ of 7 and above to kill, but fails to find any as 7 and above OOM_ADJ only consists of EMPTY_APP.
Here comes the quandary. The next checkpoint is 4096. We're not ever going to reach that as you'll need memory to fall below 16MB, and at that time it'll be super sluggish to even support GUI. Hence BAM, memory leak or lag or something.
Supercharger LMK 512HP - Multitasking
Let me just paste this to avoid a lot of retyping
Code:
FOREGROUND_APP_ADJ=0
VISIBLE_APP_ADJ=4
PERCEPTIBLE_APP_ADJ=2
HEAVY_WEIGHT_APP_ADJ=5
SECONDARY_SERVER_ADJ=6
BACKUP_APP_ADJ=7
HOME_APP_ADJ=1
HIDDEN_APP_MIN_ADJ=8
EMPTY_APP_ADJ=15
FOREGROUND_APP_MEM=1536
VISIBLE_APP_MEM=3072
PERCEPTIBLE_APP_MEM=1024
HEAVY_WEIGHT_APP_MEM=10240
SECONDARY_SERVER_MEM=10240
BACKUP_APP_MEM=15360
HOME_APP_MEM=1024
HIDDEN_APP_MEM=15360
EMPTY_APP_MEM=25600
LMK_ADJ="0,4,6,8,14,15"
LMK_MINFREE="1536,3072,10240,15360,20480,25600"
A few things here:
It's EMPTY_APP and HIDDEN_APP is too large, 80 and 100MB respectively, but the 80MB is a false flag hence it doesn't really matter if you tweak that and you can get a very minor degree of multitasking because of this false flag. I'll get to that in a moment.
It's PERCEPTIBLE_APP has higher OOM_ADJ than VISIBLE_APP (odd selection, but RAM rarely goes below 40MB before it starts lagging like hell) People would reboot their phones when it gets to that, but it rarely gets to that for this configuration as LMK is pretty aggressive here.
Now, it's LMK_ADJ is "0,4,6,8,14,15"
15 is EMPTY_APP,
14 is nothing
8 is HIDDEN_APP - it looks like it'll only kill HIDDEN_APPs when it reaches 60MB, with HIDDEN_APPs being the heavy hitter of apps as most apps will end up in this category. Hence why multitasking is still doable (to an extent) but an aggressive LMK means taking a call or switching to a browser will kill your game (losing saves). Inconvenient, but it works for some people who haven't played a long game without saving and never took a call in between. Imagine the horror LOL!
Juwe's RAM Script
Code:
if [ -e /sys/module/lowmemorykiller/parameters/adj ]; then
echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj
fi
if [ -e /sys/module/lowmemorykiller/parameters/minfree ]; then
echo "2560,4096,5632,10240,11776,14848" > /sys/module/lowmemorykiller/parameters/minfree
fi
No OOM_ADJ are given, hence the stock ones are in effect here.
From init.rc, this is the stock 2.3.5 OOM_ADJ.
FOREGROUND 0
VISIBLE, PERCEPTIBLE 1
HEAVY_WEIGHT, SECONDARY_SERVER, BACKUP 2
HOME 4
HIDDEN_APP 7
EMPTY_APP 15
This one also suffers from the false flag of the 2nd last minfree not being used. It will start killing HIDDEN_APP at 40MB, which is usable (you'll only get lags 15-20% of the time, and most probably after long usage). Other than that, it's pretty stable.
Misc
There are a few known scripts that tweaks the LMK as well as the app priority (yes, the priority of the process categories can be changed too by using setprop.)
Supercharger is one of them:
http://forum.xda-developers.com/showthread.php?t=991276
Take note that Talon doesn't permit Supercharger to be used (it will override it when booting through boot scripts) as Talon itself uses its own LMK settings that are optimized for ZRAM/Swap.
Kickasskernel script is also included in Supercharger. The script will clash with Zach's script in ThunderBolt! too as both of them tries to set different values for the same settings.
Note that Zach's script doesn't tweak LMK settings as i9000 Talon doesn't permit it. With that, if you're using Zach's scripts, you would need to find other ways of tweaking the LMK. Using Auto Memory Manager is good. You can download Supercharger, look at the presets and apply it using Auto Memory Manager. The preset is the only thing important here
LMK App Category Priorities
Using setprop, there is a way to set the priorities of the category. Since, app categories are different, I can only offer one recommendation: The HOME_APP_ADJ.
This prop setting sets how high of a priority your launcher is. A 1 or 2 is sufficient to make sure your launcher doesn't get killed. However, do you really want it to be on 1 or 2. Based on the previous article (LMK/OOM), you would know that OOM priorities are comparatively based on one another. Setting it 1 or 2 in stock 2.3.5 values would basically override PERCEPTIBLE/VISIBLE app priorities. Do you want your launcher to be killed only after your keyboard/music player to be killed? You decide
Journaling/Barriers
This has been a touchy subject here in XDA for most people who debate about it. Most recently, the SAS/Acid tweaks included a way to disable journaling on these partitions:
/system (System is read only, it's safe to remove journaling. However, you will not see speed increase by removing it as you're not writing onto /system 99.99% of the time unless you're using Titanium backup to remove system apps or copying init.d scripts to it)
/cache (Cache can be rebuilt on the fly. Data corruption on it is not game breaking)
/data (All of your data on your phone is here. Removing journaling can risk data corruption. Read more below)
On whether we need journaling or not, I will pose this situation:
Journaling is required to maintain data consistency in events that could lead to data corruption. Data could get corrupted in a number of situations:
- Misbehaving app that constantly writes without syncing/committing data to the disk
- Power loss due to forced reboots or bootloops when data is partially written/committed into disk
Android will normally buffer its writes before committing to the disk. This way, data stays in the RAM before data would only get written into the disk after a period of time. Take note that we as Android enthusiasts seek ways to better our phone to get the most out of it through experimental and sometimes wacky ways. Take OC/UV for example. When we OCed or UVed too much, sometimes our phone will get deadsleep or constant reboots. This leads to corruption if journaling is not turned on. However, we can get corruption too even with journaling but the risk is smaller.
Mount options too, play a role in whether journaling can be safe/unsafe. Most lagfixes will place a "barrier=1" in the /data to make sure that journals are actually committed before an out-of-order write is done. With that, the risk is greatly reduced at the cost of performance. You could experiment by removing barriers and see if it works for you. No guarantees on data if you remove barriers! More info on ext4/barriers:
http://lwn.net/Articles/283161/
http://kernelnewbies.org/Ext4#head-25c0a1275a571f7332fa196d4437c38e79f39f63
If you do disable journaling, make sure to manually run an fsck on your disk. Make sure the fsck binaries are in your binary paths (echo $PATH to show your binary paths). Don't ask how to do this if you're unable to do fsck. It is your own risk that you are disabling journaling/barriers.
One experiencing I would like to relate is this:
I've personally disabled ext4 journaling on my device. After experiencing a sudden power loss (forced reboot), my apps started FCing left and right and device became unstable that it sometimes rebooted when the device is sleeping. In other words, it's a lost case. Reflashing was the only way to restore my phone. This happened 1 day after disabling my journals.
Also note that ext2 is basically an ext4 without journaling. However, ext4 is updated all the time while ext2 source is not updated for quite some time (2 or 3 years?). Most optimizations are already in ext4 while ext2 even without journaling is slower than ext4 without journaling. A comparison of performance:
No journal:
ext4 > ext2
With Journal:
ext2 (can't do journaling in ext2) > ext4 > ext3
Update: Attached is a JournalingOn.zip for i9000 only that you can flash to rejournal your partitions (Only for i9000 devices!). Also attached is Acid Tweaksv6 - Removed Useless Stuff that will disable journaling only for /system and /cache, if anyone is interested. You will need to rejournal first before unjournaling. To be sure that /system and /cache has no journaling and your mounts are applied correctly, type "mount" without the quotes.
You'll be able to see that /data will have:
Code:
barrier=1, data=ordered
/system and /cache will have:
Code:
barrier=0, data=writeback
To be really sure, you can check by using tune2fs included in both the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip.
Copy the tune2fs to /tmp and set rwxr-xr-x as its permissions using Root Explorer/File Expert
Code:
/tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You can substitute the /dev/block/mmcblk0p2 (which is /data) to /dev/block/stl10 (/dbdata) /dev/block/stl9 (/system) /dev/block/stl11 (/cache) to check each partition.
Continued in Post #2 - Lack of space
Still posting ...
Question
I guess this is safe too on a deodexed ROM, too freeze those bloatwares u listed?
Page 2
Undervolting/Overclocking
This is also another touchy subject, but more towards people complaining about phones that get forced reboots or bootloops. OCing is done to get better performance on your android. WARNING: Ocing will cause more wear and tear on your CPU and will reduce your CPU lifetime. How much it will reduce it? No one knows. It depends on how sturdy your CPU is, and that cannot be measured by any means. It could be reducing months out of year e.g. 6months out of 3 years? No one actually knows.
UVing on the other hand reduces battery drain especially when you UV your 100MHz as 90% of the time in normal usage, your CPU will idle at 100MHz. How much can it save? No one actually did a benchmark on it. Save to say, UVing does not harm your CPU, it will actually extend the life of it by reducing wear and tear Oh, bootloops do corrupt data if you're without journaling
Always remember to clear your UV/OC settings before flashing another kernel!
Take note that the ability to OC/UV depend on your phone. Some SGS can UV better or OC better and some might not.
On how to UV:
1. You can UV more on the lower frequencies than the higher frequencies.
2. Do a UV for
100MHz with (950-150=800) - Take note that 950 is the base value for the voltage. Some kernels might have changed this value to 925 or 900. This is why clearing your OC/UV settings is important as the OC/UV settings will only load the voltage difference, which in this case -150. If the base voltage is 900 and you do a -150 for it, you'll end up with 750 which might cause bootloops.
3. Limit the max frequency to 100MHz. WARNING: Doing this will significantly slow down your system to a crawl, but it is still running. This is done only to test the stability of your system. You can skip this if you want, but you would need to find a way to stress test your CPU at the 100MHz value (and other values as well by limiting the max frequency). Failing in testing this will result in deadsleeping (as your phone is in 100MHz when you sleep and if you undervolt too much, you deadsleep)
3. Test with RockPlayer (or MX Video Player) and play an RMVB file using software decoding for 10mins. If your settings is unstable, Android will freeze up and reboot. (this is just an example, but I find that this way stresses the CPU to the max. I fail to find another way of stressing it as even playing NFS is stable on some voltages but fails when I play rockplayer. Hence rockplayer is the best way so far)
4. After doing this, remove the limit and move on with the next few frequencies.
The rest of the voltages, just rinse and repeat.
200MHz with (950-100 = 850)
400MHz with (1050-75 = 975)
800MHz with (1200-25= 1175)
1000MHz with (no change)
You can experiment with lesser values than these if you get freezes/bootloops as this is by no means a one size fits all value. Some might think this UV is overly aggressive or some might think that this UV value is too underwhelming.
Mine if you're interested:
Code:
100MHz = -200 (950 base)
200MHz = -150 (950 base)
400MHz = -125 (1050 base)
800MHz = -75 (1200 base)
1000MHz = -50 (1275 base)
As for OCing, you would do the same to test the stability. Just that you will be enabling a higher clock for your L0 frequency (L0 is the highest frequency). Some kernels might add more frequency states i.e. from the 5 states above to 6. You can try using Tegrak OC app too. It all depends on your own experimentation.
Memory Leaks
If you found out that your Android is laggy after sometime and a reboot will make it faster, then you're experiencing memory leaks. "free" is a command to show your currently free memory. It will not necessarily be the same value as your phone's free memory (as it takes into account swaps and buffers)
1. Go to terminal emulator (or download the script at Post #3)
Code:
su <ENTER>
free <ENTER>
This will show your buffers and free memory.
My example:
Code:
total used free shared buffers
Mem: 348548 340280 8268 0 1320
Swap: 163836 47292 116544
Total: 512384 387572 124812
Then do this:
Code:
sync <ENTER>
echo 3 > /proc/sys/vm/drop_caches <ENTER>
Type:
Code:
free<ENTER>
And you'll realize that the buffers will reduce and free memory will increase, like this example:
Code:
total used free shared buffers
Mem: 348548 305212 43336 0 88
Swap: 163836 46804 117032
Total: 512384 352016 160368
That means it's done.
Click to expand...
Click to collapse
If this solves the laggginess problem, it's due to vfs_cache_pressure being too low and dirty_ratio being too high. However, in most cases, you don't have to do this as Linux will manage to clear the RAM in a timely manner as long as there are no apps that constantly hold on to the memory (not releasing it). Hence, only do this when necessary (lagginess and such).
With that, I've updated the system_tweak yet again, with this knowledge by making the VM settings more aggressive, which will trigger the memory leak faster. I made this so, as there's a workaround to clear the caches when it gets full.
Having a low vfs_cache_pressure and a high dirty_ratio will save battery and make your device perform faster at the cost of higher RAM usage.
You can actually automate it by using Script Manager by making a script, pasting the instructions and making a widget out of it. To learn more, read the android market description or the in-help guide in the app.
Some commonly asked questions about drop_caches that were answered by me from flolep:
http://forum.xda-developers.com/showpost.php?p=17727859&postcount=3428
http://forum.xda-developers.com/showpost.php?p=17731938&postcount=3446
http://forum.xda-developers.com/showpost.php?p=17736421&postcount=3450
Checking for Battery Drain/ Saving battery
Starting from Gingerbread, you can't really look for Partial wakelocks anymore to determine what is draining your battery at night. BetterBatteryStats is a way to check for that. It also can provide the process that drains your battery most of the time.
A high partial wakelock usually says that something is waking up your phone at night. With that, checking partial wakelock, you can see if these are the culprit:
-Network Location
-Location Manager Service
If so, disable Lattitude or any location check-in app that you're using. It's checking you in every few minutes that drains the battery.
Disabling Wifi/3G/HSDPA saves battery too. I find that Wifi/Edge drains the least amount of battery when idling. To switch to EDGE as opposed to HSDPA/3G.
Go to:
Code:
Settings > Wireless > Mobile Networks > Network Mode > GSM Only
Disabling "Use Wireless Networks" in location and security would save a little bit of battery too I guess. It's in:
Code:
Settings > Locations and Security > Use wireless networks
CSC
CSC is a folder that defines your APN settings and country/region specific configurations aside from Language/Time that is configured in build.prop(also for Samsung Apps).
Having to manually set your APN is annoying right?
Your product code being KOR by default is another annoying thing to deal with. How do I resolve this?
1. Get your CSC from your own country here: http://forum.xda-developers.com/showthread.php?t=948790
2. Extract from the zip file /system/csc/<folder> (where <folder> is your Country's CSC)
3. Use Root Explorer/File Expert to copy it to the phone's /system/csc/.
4. Use nitrality to change your product code. WARNING: This will wipe all your data.
Odexed vs Deodexed
I've been using Deodexed ROMs since I first flash my custom ROMs. One gripe I have is that I seem to have lost the stock smoothness/speed that I experience when I'm using a stock ROM. I found out that deodexing actually extracts the customization files back to the APK (using APK manager) and Odexed files are actually done to optimize the speed of those files itself.
The only reason ROM chefs are using deodexed files is that it is easier to theme. There is no need to decompile the odex files and make the changes as all the theme files are in the APK themselves.
Only other reason that I know of is the overscroll glow. Odexed files can't support it. However, that is a small price to pay for speed/smoothness that I am willing to sacrifice.
Busybox
Busybox is required to perform all of your superuser activities in your android phone. There are some problems associated with this when ROM developers decide to use a certain version of Busybox that are incompatible with the binaries that we use in our phones. When you found out that after changing your kernel/ROM:
- You still have superuser and Titanium Backup still works but,
- Root Explorer/File Expert can't copy files correctly to the /system after mounting rw
- Voltage Control/ Pimp My CPU/ Control Freak/ SetCPU cannot create the Svolt_scheduler file in /etc/init.d
You have a clashing busybox version issue. This can be remedied by:
- Installing the busybox installer from the market
- Installing busybox 1.17.x into /xbin
- Removing all other busybox binaries from your binary path. (This is optional if you found out that after installing busybox, everything works. Try it first before removing) To know your binary path, do an
Code:
echo $PATH
Nandroid Backup
Nandroid Backup is done in recovery (VolumeUp + Home + Power). In recovery, choose Backup And Restore. What it does is it backs up your:
- Boot
- System
- Data
- Cache
When you restore, you should preferably use Advanced restore and restore the /system and /data. All others can be built from scratch (except /boot). If you're converting from CM7 to Samsung Roms, it's best to start from scratch either ways. Restoring nandroid from any is considered dangerous and not supported by most cases. Best is to use Titanium Backup to backup as it can be restored both ways (only restore app though, restore data sometimes can lead to FCs)
Voodoo Color
Voodoo Color is also a point of contention among users. Some like it and some hate it with a passion. If your kernel does support it, here's a way to tweak it:
1. Tweak the color profiles. Can't see a difference, hence I would just pick Voodoo most of the time.
2. Tweak the gamma first to a comfortable value. I.e. drag the 3 sliders together to a comfortable gamma level. After that, try looking in the gradient (the gray slab below the slider) and try to find for neutral gray values. Adjust each slider until you find a neutral gray (i.e. left and right until you see that slab is truly gray)
3. Tweak the RGB multiplier until you have a comfortable level (3 sliders together). Then tweak it the same by referring to the gradient until you're comfortable.
4. Switch off your display for a while and look at your surroundings to reset your eyes. Then turn on your screen again and see if its too green/yellow/blue etc. Adjust the gamma/RGB multiplier until you're satisfied.
This might take a few rounds of testing, but in the end you'll be truly satisfied with it
i9000 Specific
i9000 Kernels - In Depth
You will need to have a stock odexed (why odexed? read a few passages below)ROM with root. You can easily do this by flashing stock XXJVS 2.3.5 and then flashing a custom kernel through Odin like:
- Dark Core - Uses Voodoo initramfs
- CF-root - Uses CF-root initramfs
- Semaphore - Uses CF-root initramfs
- Midnight - Uses Speedmod initramfs
- Galaxian - Uses CF-root initramfs
- Voodoo - Uses Voodoo initramfs
You can flash the custom kernel through Odin by placing the tar file into the PDA section and pressing Start. At this point, do not convert your partitions to ext4 (lagfix) unless you're using a Voodoo based initramfs as Voodoo based initramfs will convert your partitions to ext4 automatically at first boot.
After flashing a custom kernel through Odin, you will gain root. From there, you can choose to use any other custom kernels that use CWM to install or stick with the custom kernel that you've flashed through Odin like:
- TalonDev - Uses Voodoo initramfs
- TalonSH - Uses Voodoo initramfs
There are other kernels as well, but since I did not stress test them, I will not include them here. This thread lists the full repertoire of custom kernels that you can choose from:
http://forum.xda-developers.com/showthread.php?t=1196704
On which custom kernel to pick, you're advised to look at the individual threads original post as well as the last 5 pages of the thread to know about its stability and features. I pick TalonDev myself as it has compache as well as the latest upstream (kernel updates from the Linux OS as well as the official Android Open Source Project/AOSP and optimizations) patches.
At this point, you should decide if you would want to convert to ext4 (lagfix) or not. Your phone by default will reside in an RFS system. The RFS at this point in time is pretty stable and its performance can easily match ext4. Too bad Quadrant scores are bad for RFS, but who cares about Quadrant anyways. I myself choose to use ext4 as the TalonDev kernel has a lot of ext4 upstream patches that optimizes the usage of ext4 on Android.
If you're using Voodoo initramfs, you'll be converted to ext4 automatically.
If you're using CF-root initramfs, you will require the CF-root ext4 app to convert that can be found here:
http://forum.xda-developers.com/showpost.php?p=12651371&postcount=7
Note that on some kernels that use CF-root initramfs, the ext4 app will warn you that you're not on CF-root type kernels. Ignore this warning. You'll be able to convert to ext4 anyways unless you're on Galaxian. Certain Galaxian versions (since the kernels are not versioned, I can't tell which versions are not working) will bar you from converting to ext4 using the ext4 app. If that is the case, just flash CF-root, convert to ext4 and then flash back to Galaxian.
Also not that CF-root based initramfs kernels will remove your bootsounds on first boot. Don't be alarmed by this.
In terms of which lagfix is better (Voodoo vs CF-root lagfix), I can't tell at this point in time. Both are equally good. Since TalonDev uses the Voodoo initramfs, I am inclined to use the same when I am using the same kernel. That should be a good yardstick to follow.
BIGMEM/ Non-BIGMEM:
Some kernel developers released BIGMEM versions of their kernel:
-TalonDev BIGMEM
-TalonSH BIGMEM
-Semaphore bm version
The only difference a bigmem kernel can bring is more memory at the expense of 720p video recording. Playing a 720p video is still possible. Recording it is not on a bigmem kernel. Bigmem kernels normally have 13MB more than their non-bigmem counterparts. How this 13MB could affect you? It depends on the apps you use and how aggressive your LowMemoryKiller is.
XXJVT System apps
System apps can be frozen/removed to make your system faster/less battery draining.
In order to remove/freeze system apps, you would need Titanium Backup (Pro) or System Tuner.
The choice whether we want to remove or freeze the system apps should now be decided. Titanium Backup Pro and System Tuner uses a built in Android mechanism to freeze your system apps - PM disable. PM disable will actually disable the app from the system itself. It will not drain the battery or even launch itself. It is a safer way so to speak. Removing will physically delete the APK app from the system freeing up disk space. If you decide to remove, make sure to have a backup before proceeding. Even if you have a backup, restoring from Titanium Backup may sometime fail. Hence, do this only if you're sure you want to remove that certain app. Freezing an app will make it easier to defrost without any consequences.
Here are the apps that I disabled:
Code:
AngryGPS > Used to manually configure GPS. Not needed if GPS works OK.
BluetoothTest
Buddies Now
lcdtest
screencapture > Screen capture app
Daily Briefing
Days
EncryptApp
Factory Test
Gallery -> I use QuickPic as a replacement. It's faster than Gallery.
Google Partner Setup
Google Search > Google search widget
Home screen tips
HTML Viewer
Market Feedback Agent
Market Updater > I froze this to avoid being updated to Market 3.0. It currently sucks now
Mobile tracker > Mobile tracker, only if you use it, then keep it
Mobile tracker settings > Mobile tracker, only if you use it, then keep it
Perso
PhoneSetupWizard > Required if you're first booting/installing the ROM, not needed afterwards
PopupuiReceiver
Press Reader
Print via Bluetooth
RoseEuKor
Samsung Account
Samsung Keypad -> I use Swype beta instead
Self Test Mode
Service mode
SimDetachNotifier > Will notify you if you detached your sim card. Seems pointless
SNS > Only necessary to sync your contacts if you're using Social hub to do so or syncing calendar from Facebook
SNSAccount > Same as above
Social Hub
Software Update
Synchronise
TwLauncher -> Using Go Launcher Ex instead
wipeoutreceiver > Wipe if phone is stolen. Not needed if you don't use the Samsung service
WlanTest
wssyncmlnps
There are others that you can remove as well. I'm hoping to gather feedback on the other APKs that can be removed and what will be affected by its removal. Please post if you have more information
Disabling Lagfix
Most ROMs would advice you to disable lagfix before flashing a new ROM. Although this is not necessary in most cases (as all Gingerbread kernels support ext4 from the get-go) moving from one kernel to another might need it (to optimize the initramfs it is used on). Hence if you're swapping from one kernel (that has a different initramfs) to another. It is adviseable to undo the lagfix.
CF's lagfix can be undone by using the ext4 app.
Voodoo lagfix can be undone by using the Voodoo Control App.
Speedmod lagfix can be undone by using it's recovery.
Odexed ROM
You might say, hey if I'm using stock, I'll be missing extended power menu, battery percentage and all other theme mods that are not in the stock ROM. Fear not, you can get all these back including Gtalk2, CRT screen off etc here:
$omator's stock+
Gtalk2
There are odexed themes too, in which the developers would decompile the odex files into APKs, make the changes then compile the APKs into odex files again. It is more tedious than deodexed themes but odexing generally makes the phone smoother
You can find the themes here:
http://forum.xda-developers.com/forumdisplay.php?f=666
WIFI Issue on JVR/JVS/JVT
You might be facing some wifi connectivity issues on JVR/JVS/JVT ROMs i.e. it disconnects every few seconds.
This is due to some changes in the ROM that doesn't permit a "Forever" lease time from your modem. Change your lease time to an hour (or two) or if you don't have that option, remove your address reservation option from your modem (Yes, it's a modem only tweak, nothing you can do on your phone)
Memory Freak
Memory Freak is an app in TalonDev that tweaks the ZRAM/Swap and LMK settings. There's a golden rule to the ZRAM/Swap that is:
Swapping to and from the ZRAM will be slower if the amount of ZRAM is more than 50% of the total usable memory, . Hence, I set mine to 160MB (from the 340 total usable RAM). Swappiness in most Linux machines is 60. This means, the system will be inclined to swap in/out more than just using the RAM. I set mine to 50 as a personal preference so that there would be 50% chance that the system will use swap or RAM.
HiddenApp is the amount of free memory to be when LMK starts looking for hiddenapps to kill. I set mine to 52 for my multitasking preference. Experiment with it to see how much multitasking vs smoothness you're looking for. My preference will change in time. Check my signature for the most updated ones.
WIP:
This is obviously a work in progress article that will undergo changes as the Android scene improves. I will spend time to make edits and additions to the post whenever I see fit. Sometimes I will post changelogs at the end of the thread, sometimes I won't if I only make minor edits. Just be sure to check back often to see any new tips offered
Credits:
I claim no credit on these findings except for the ones that I've researched on my own. However, all of it is not of original work since I form my own opinions after reading a lot. I also don't claim that the settings I posted are the most optimal there is. It might not even work well for most of you guys. The key here is tweaking it to your own perfection as there is no setting that will cater to everyone's needs. Hence the real people who deserve credits are:
* All the devs' kernel/apps that I posted here
* XDA forum
* Google
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
GUIDE UPDATES
UPDATE 1/10/12
* Edited some sections with some new knowledge that I have. A few places, can't name them all Check them out and see if you can spot them.
UPDATE 10/19/11
* Moved around some guides and grouped them together
* Updated some guides to make them more Android centric (as opposed to i9000 centric)
UPDATE 10/18/2011 - Added an indepth article about LMK/OOM. CTRL-F for LMK.
UPDATE 10/12/2011
* Added some comments on the apps removed/frozen so that you can make an informed choice of why the apps can be removed/frozen.
* Added my analysis of most schedulers that I know of and why they are good/bad.
* Moved the scripts to ThunderBolt!: LINK
* Added a guide on the wifi issue for JVR/JVS/JVT
UPDATE 10/1/2011 - Moved the script reviews to this post LINK
UPDATE 9/23/2011:
* Removed the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip because people might use it for devices other than the i9000. This is because in other devices such as SGS4G, the /dev/block/stl10 is /data while in i9000 it's /dbdata. The JournalingOn.zip will not enable journaling on /dbdata without some editing. Hence, I removed it as I don't have a time to put up a warning or notice, and didn't have time to edit the script inside the zip file.
* Readded an edited JournalingOn.zip and readded the Acid Tweaksv6 - Removed Useless Stuff.zip (did not change) to the first post. Only for i9000 devices!!
* Added another way to check if you're journaled or unjournaled. Check the guide below.
* Added some more explanation on common scripts I found.
* Moved the guides around due to lack of space. I added some minor changes to most of the guides. See if you can detect them
Helpful!
pikachu01 said:
Yes it is safe to remove for a deodexed ROM too
My point of stating odexed is that my tweaks can be used from the stock odexed ROM itself
Click to expand...
Click to collapse
oh ok, now I understand, thanks for this thread, very helpful indeed .
Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!
thx dude!! awesomely useful!!
Great information thanks
Can you please include GPS tweaks as well?
awesomeandroid said:
oh ok, now I understand, thanks for this thread, very helpful indeed .
Click to expand...
Click to collapse
Thank you for reading it.
SkinBobUk said:
Awesome post thanks!
Not only for the tips but for teaching me a lot too!
Sent From My Android Shizzle!
Click to expand...
Click to collapse
It was my hope that it will give knowledge so that people could pass it on to more people
midikarma said:
thx dude!! awesomely useful!!
Click to expand...
Click to collapse
Thank you
ajazz said:
Great information thanks
Can you please include GPS tweaks as well?
Click to expand...
Click to collapse
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?
Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where
Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!
demonstone said:
Oh man... Thx for your work... This thread is very useful.
I take my hat off.
Sent from nobody knows where
Click to expand...
Click to collapse
Thank you
ZioGTS said:
Wonderful job, pikachu01! A new user will need weeks, maybe months to gather all the bits of info you put here, served on a silver platter! Thank you veeeery much.
Mods, this should be stickied!
Click to expand...
Click to collapse
Thank you Zio I forgot to add a few more posts to reserve. I guess I will add links if I do have any other things to add
Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?
haloimplant said:
Indeed lots of good info here for people just starting out, and some for people like me who've been around the block once or twice too!
I figured out how to do the CSC change myself, I just put the BMC folder from stock ROM into /system/csc and used one off the CSC selector apps from the market. Is this much different from the instructions here?
Since this has brought up the topic of freezing apps I will ask a question here if I may: Is there a way to keep apps from starting services, without getting rid of them? For example I use Skype and Facebook but I don't want their services running all of the time sucking up memory. Also I notice now that I game I installed recently (E Warriors) is running a service! WTF this is out of control. Any ideas?
Click to expand...
Click to collapse
Yes, the CSC instruction does the same thing. I'm just a bit thorough sometimes
You could use System Tuner or Titanium Backup Pro to freeze the app and then unfreeze it when you want to use it. Freezing is actually just doing a PM disable. PM disable basically makes Android think that the app is gone when it's actually still there. Unfreezing an app is basically just 1 click, hence its hassle free.
ZioGTS said:
Wonderful job, pikachu01!
Mods, this should be stickied!
Click to expand...
Click to collapse
Agreed +1
Excellent & informative
Awsome post pika.. Great work.. thx
Very nice tutorial. Should be pinned
Sticky please (with sgs chlorine).
Great work, much appreciated.
Sent from my Galaxy S using XDA Premium App
pikachu01 said:
Thank you for reading it.
It was my hope that it will give knowledge so that people could pass it on to more people
Thank you
Thank you for reading it What kind of GPS tweaks? There are a few notable ones. The most useful ones are disabling AGPS as well as updating the gps.conf. Do you mean that?
Click to expand...
Click to collapse
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.
ajazz said:
I have tried lot of Roms and none gave me satisfactory GPS performance except InnOvaTioN v2 by bezke,this Rom gave me almost instantaneous gps lock , when under partial cover it took a minute or so !
Then i moved on to v3 and was back to square one!
unfortunately v2 is no longer available for download.
I have tried Faster Fix, Gps Aids, tried changing setting through sgs tools but no go.
even tried different modems.
Click to expand...
Click to collapse
well, then open a thread on general, Q&A, etc.
and let someone upload it
hopefully there are still copys of it out there
so there's a way to analyze and understand what was done to get those great results
@pikachu01:
great work on collecting all of this information & putting it in a central place !
*subscribes*
+1 for sticky
Very nice guide. It'll be very helpful for begginers. +1 for the idea to stick it
Related
FlyKernel is an overclockable kernel for the Hero GSM, aimed to improve stability, battery life and performance (generally in that order).
The Hero GSM now also has a newer .35 kernel "Las Venturas" you should also check that one out. At the time of writing these lines, the newest version of Las Venturax is found on the second post of the above thread (my post ) - you should check which post is more up-to-date on that thread.
Download and instructions are on this post.
FAQ and advanced subjects are on the second post.
Change log and previous versions are on the third post.
WARNING: Please make sure to have an up-to-date backup before you flash this kernel!
FlyKernel-13 (#253)
FlyKernel 13 - Desean
FlyKernel 13 - Mediafire
FlyKernel 13 - Multiupload
This is a post-LasVenturas update for FlyKernel, after quite some time without any updates.
Although I currently have a bit of a personal preference for Las Venturas, I believe that it is even better to have two excellent kernels for the hero (internally totally different ), so that the users can choose whichever works best for them. Possibly, on some of the older ROMs this kernel might work better. This should also help isolate kernel issues vs. ROM issues.
SmartassV2 (informal description and comparison with the first smartass)
SmartassV2 is a governor (controls the frequency of the CPU at each give moment) which like the first smartass is generally based on the implementation of interactive with some major changes and the addition of a built in sleep profile (behaves a bit differently when screen is off vs. on).
The smartassV2 improves the very naive scheme which the first smartass had: The first smartass (with the values I set for the hero), would cap the max frequency at 352Mhz for sleep and when screen is on, would do the opposite and keep the frequency at 518Mhz or above. For sleep this was very effective but a bit crude and unclean, and there could be some cases where you would need processing power even when screen is off (something is updating and music is playing and etc.). For screen on, smartass1 was too quick to jump to the max available frequency and again would never go below the 518Mhz, so in a nutshell its was using "too high" frequencies.
SmartassV2, introduce (internally) an "ideal" frequency which is the frequency we are "aiming" for, in some sense. The way I see it is that the "ideal" frequency is a hint to the governor what is a good balance between performance and battery life. Now when screen is on, I set (on the hero) the ideal frequency to 518Mhz which will ensure nice responsiveness but limit unnecessary use of higher frequencies when they are not needed. When screen is off, I set the ideal frequency to 352Mhz (0 will disable the screen state tracking all together). From my testing this will "convince" the governor to spend most of the its time during sleep at the lowest available frequencies. Note, that both during sleep and when awake the entire frequency range (as defined by the "user" - i.e. selected with SetCPU) is used by smartassV2. For example, when the CPU is loaded heavily, the highest available frequency will be used regardless if screen is on or off.
Boot OC and optional tweaks
Optionally, you can rename the update file before you flash to change bootup frequencies and other options.
If you don't rename the file and flash "FlyKernel-13.zip" you will get the default tweaks and the min/max frequencies will remain as they where before.
For example, to set the max/min frequencies on boot to 614/176, rename "FlyKernel-13.zip" to "FlyKernel-13-M614-m176.zip".
Supported "flags" are:
Notice, all flags are case sensitive.
-MXXX - set max frequency to XXX
-mYYY - set min frequency to YYY
Supported max frequencies:
518 576 614 633 652 672 691 710 729 748
Supported min frequencies:
19 176 264 352 518 576 614 633 652 672 691 710 729 748
Default behavior, if these flags aren't given, is not to change your current settings.
For frequency recommendations and more info see FAQ #5.
Technical details: max/min frequencies are set in the kernel's ramdisk init.hero.rc file. Previous settings will be replaced. Furthermore, if one of your init.d script sets the max/min frequencies, these lines will be removed.
If you have SetCPU or other program changing the speed at boot, their change will take effect and overwrite this setting as soon as the ROM completes to boot.
-nologo - Don't show boot animation.
-logo - Show boot animation.
Default behaviour, if no flag is given, is not to change your current settings.
-noatime - Mount all partitions with -noatime to improve IO.
-atime - Mount no partition with -noatime.
Assuming, your ROM did not mount any partition with noatime, then the -atime option should undo the -noatime option perfectly. Unfortunately, it seems some ROMs (i.e. VR12) mount only some of the partitions with -noatime. It seems that in some cases, changing the noatime configuration causes boot problems.
Therefore, I highly recommend you make a backup before trying the -noatime flag - this is the only full proof way to go back if it messes something up.
Notice, this does not effect the ext partition as it is not mounted in the ramdisk init.rc. As far as I know, all ROMs mount the ext partition with noatime.
-notweak
By default, the updater will remove scheduler tweaks which exists in the ramdisk init.rc script, in order for the scheduler default compiled into the kernel to apply. This flag will disable this behavior.
More techinical information for developers about the smart update package has been updated in my github wiki.
Limitations and known bugs:
- This kernel will not make you coffee (I hope)!
Integrating kernel in a custom ROM (for ROM developers)
You can use my from above:
http://floyo.desean.net/FlyKernel-13-Floyo.zip
This file has a regular boot.img with a ramdisk compatible with Floyo 1.4, boots at 576/352 (smartassV2) and has all the kernel modules unpacked.
If you need to edit the ramdisk, you can either unpack the above boot.img as explained here. Or you can get the kernel binary file from my smart update package, under tmp/flykernel/kernel. The kernel modules are package in the smart update package under tmp/flykernel/syslibs.tar.
Kernel Sources
My sources with all my updates and changes are found on github:
http://github.com/erasmux/hero-2.6.29-flykernel
Use hero_defconfig for the regular version and hero-bfs_defconfig for the BFS version.
See the wiki for more information about building the kernel and more.
Please feel free to contact me regarding my sources and kernel development.
Using my Kernel Sources
Feel free to use my kernel sources, fully or partially in any (legal) way you see fit.
If you modify the sources, I urge you to share your changes with the community (as GPL obliges you to do), preferably using github. You can fork my sources on github, and this will make it easier for you to grab new changes from me and also allow you to fill pull requests so I can pull your changes back to my kernel.
GPL
Yes I am GPL complaint, all is included inside the sources, including the GPL license itself.
Thanks
Huge thanks to Desean for giving me file hosting that makes my life easier
Many thanks to all the Kernel/ROM developers here, especially those with open source kernels on github - LoxK, Cyanogen, Ninpo, Radu and especially Decad3nce.
Big thanks to all those who helped test the pre versions and reported bugs, specifically also to my long time testers (moonshield and floomat)
Donations are always welcome and accepted but are in no way required.
FAQ and Advanced Subjects
FAQ
0. When reporting a problem, do I need to include the ROM and exact kernel version I am using?
YES!
1. How do I flash the kernel update file?
You flash it from recovery, like any other custom ROM. If you are not familiar with recovery and/or haven't rooted your phone, start here.
2. Do I need to wipe anything when installing the kernel?
No you don't need to do any wipes. Just install the kernel through recovery and reboot
3. The update from recovery failed with errors/warning?
Please, in the same recovery session which you tried to apply the update and failed, select the "Move recovery.log to SD" from the "Other" menu and post in this thread with the recovery.log attached (for example in a .zip file).
4. After flashing the kernel my ROM does not boot
A logcat of the boot process might help me understand the problem. Using adb you can generate one with the following command and attach it to your report:
Code:
adb logcat > logcat.txt
You need to run this command relatively close to the start of the boot. Close the window after the phone is stuck for few minutes (say 2 mins with no change should do). You can start by running "adb logcat" and seeing if you get any output at all. If so, reboot once more and run the above command from the start of the boot (approximately).
Please also clearly state which ROM you are using and which kernel did work for you (which one did you use before).
To recover from such a scenario, boot into recovery and restore a backup of your working state. If you do not have a backup, and its the kernel fault, flashing your old kernel should solve the problem.
5. What min/max frequencies should I choose?
The short answer: min 176, max 614, if you have wake up issues up the min speed to 264 and then to 352.
To play with the speeds I suggest you install SetCPU (or similar app), so you can view and change your settings interactively. To change it permanently from the bootup see instructions on first post. You also use options like "Set on boot" in SetCPU if you prefer that.
The long answer:
The max frequency will effect the speed and responsiveness of your phone when screen is on. Note, that any speed above 528Mhz is above the specification of the manufacturer, hence is overclocking and could, in theory, shorten the life of your device. At high enough frequencies all devices will stop functioning, the exact threshold depends on your luck with your specific device. From my experience and knowledge, running at stable frequencies (or say one or two steps down to be on the safe side), should not harm your device - of course all overclocking is done at your sole responsibility.
As far as I know, almost all device can handle 652Mhz, most can reach the 691/710 area and some can even reach higher than the 748Mhz cap of this kernel. To find out which speed your phone supports, use SetCPU (or similar app), start from 614 for example and up the speed one tick a time. Don't select "Set on boot". At each step play with the phone a minute or two. If the phone gets stuck, reboot it (take out battery if necessary) and go one tick down.
Additionally, note the higher your max frequency the higher the battery drain will be when the screen is on. It is true that the display, data, wifi, gps, etc. should drain much more than the cpu. Still, I recommend staying in the sane frequencies range, no more than say 691Mhz (even if you phone can handle it).
Finally the min speed will effect standby battery life (when screen is off). From my experience there is a difference in battery life between 19Mhz and 352Mhz min frequencies but it is relatively small (much less than I expected). 19Mhz is not stable for me, almost stable, but over a period of weeks you will probably experience weird and possibly very rare instabilities. For me this was the when playing music with screen off the phone got stuck at 19Mhz (very hard to find this out), and became totally unresponsive until I rebooted it. Therefore, I recommend starting from 176Mhz, and if you have wakeup issues to bring it up. With 352Mhz you should have no wake up issues at all.
6. I am having wakeup issues (such as unresponsiveness to wakeup, weird coloring after wakeup, screen inversion, caller id not working on wakeup)
Up the min speed to 264 and then to 352. With a min frequency of 352 you should not have any wake issues.
See the FAQ #5 above for more information.
7. I am experiencing bad battery life with FlyKernel
First, please make sure to reboot the ROM at least one time after you flash the kernel. There have been reports that ROM/kernels behave badly on the first boot.
Personally, I do not do battery calibration, but if it makes you happy go for it. I do recommend at least charging the battery overnight, or a couple of hours after it has reached 100% to be sure it is full. Then use it, your regular usage for a few days and only then judge the battery life.
The battery percent indicator, over short periods of time seems extremely inaccurate and its very hard to reach any correct conclusions based on it.
If you do want to report bad battery life, please state your settings (kernel version, min/max speeds, governor, etc.), over which period you have been testing the battery, under what usage, what is the battery life you are used to having with which kernel and what is the battery life you are experiencing now.
Note, that roughly speaking, I lose less than 1%/hour when screen is off (wifi, data, gps, etc. also off), and about 10%/hours when just screen is on but phone does nothing at all (again wifi, gps, etc. off). About 20%+/hour when stressing my phone (although I have no data plan so can't test that). I am using the latest FlyKernel @ smartass 614/176.
8. What size should I give the swap partition?
short answer: 0.
long answer: I do not recommend using swap on the hero, hence 0. If you have a very fast SD card, and want to try it, give it say 64Mb. Note that I know of no ROM for the hero which activates swap automatically - you'll need to add a init.d script or something to activate it (see a bit more info here). Let me know if you find a scenario where the swap gives substantial improvement over no swap.
Finally note that FlyKernel versions before 12 do not support swap.
9. Should I use ext2, ext3 or ext4 for my ext partition?
Short answer: ext4. Note that FlyKernel versions before 12 did not support ext4, ext3 is supported since version 10.
Long answer:
Previously, I was under the impression that a journaling file system is a very bad idea for flashable storage. I still think its not ideal but better than the other alternative:
I have been using dual booting, placing an entire development ROM on an ext2/4 partition and using it for development. And when using ext2 it would get errors almost every boot and every couple of days get corrupted to the point I needed to manually restore damaged files to get it working....
It seems that if you only use it for app2sd, there are very infrequent changes to this volume (only when you install a new app), hence it does not get corrupted. But this also means that ext4, in this scenario, will not pay much overhead because there are very few changes. And in the case there are many changes, if I have to choose between a slightly shorter SD life with ext4 (and then I can finally get a faster one ) or risking my data getting corrupted on a daily basis with ext2 - I prefer the first (ext4).
Questions 10-13 are now obsolete with smartassV2 - see the first post for details about it
10. Do I need a SetCPU (or similar) screen off profile with smartass?
No, smartass automatically limits the screen on frequency to >= 518Mhz to ensure responsiveness, and screen off frequency to <= 352Mhz to keep standby battery life under control. Much like HTC's perfllock, it does this at the kernel level so it is much better than app level screen off profiles.
11. Using smartass the CPU frequency does not drop below 518Mhz (with screen on)
Intentional to ensure responsiveness. From my testing, when screen is on battery drain difference of speeds < 518Mhz is not significant relative to the drain by the screen itself.
12. Using smartass the CPU frequency does go above 352Mhz (with screen off)
Intentional to keep standby battery life under control.
13. Using smartass the CPU frequency is always at its max (or always at 352Mhz when screen is off)
See "Monitoring the CPU frequency" in the "Advanced subjects".
14. I am experiencing spontaneous reboots
Please post, in this thread, with as much detail as possible about the problem.
Please also attach the last_kmsg, which you can get from example using:
Code:
adb pull /proc/last_kmsg
15. What happend to the BFS version?
With the FlyKernel-12 scheduler tweaks (CFS scheduler), it surpasses the BFS version in every way. I tried to compile a BFS from the FlyKernel-12 code but even in neocore, in which the BFS was always much better, the new tweaked CFS leaves the BFS in the dust. Hence, I see no reason to continue and build/support a BFS version. The hero-bfs_defconfig is still up to date in my sources if anyone wants to build it themselves.
*. I am experiencing an issue not covered in the FAQ which I believe is kernel related
Please post, in this thread, with as much detail as possible about the problem.
Please also detail why you believe this kernel related. The best "proof" that it is the kernel's fault, is to flash back your old kernel and verify the problem is solved, then reflash the new kernel and verify the problem reappears. In any case please detail the kernel and version(s) on which your are experiencing the problem and those on which you do not.
Advanced Subjects
* Monitoring the CPU frequency
Will rewrite this more clearly. In the meantime:
http://forum.xda-developers.com/showpost.php?p=9925116&postcount=903
http://forum.xda-developers.com/showpost.php?p=9929325&postcount=919 <-- Mainly this one!!!
http://forum.xda-developers.com/showpost.php?p=9989996&postcount=970
http://forum.xda-developers.com/showpost.php?p=10010110&postcount=990
Change log and previous versions
FlyKernel-13
- Scheduler tweaks: use the scheduler settings that worked well on flykernel-11c and 12pre6 (tweaked them very very little), responsiveness should now be better than on the FlyKernel-12 release
- Backported the new smartassV2 - now the default
- Added interactiveX governor also
- A few config changes and compiler optimizations
FlyKernel 12a (mediafire)
- Fix wake up issues with new scheduler tweaks
- Smart update script: make noatime tweak option to (hopefully) solve boot problems
FlyKernel 12
- Smart update script
- Optimized scheduler parameters
- Fix Usb mass storage after usb tethering (at least on CM ROMs)
FlyKernel-12pre6
- Align ext2/3/4 config options
- Merge small fixes to lowmemorykiller module.
FlyKernel-12pre5
- Backport of smd rpcrouter to avs333 request.
FlyKernel-12pre4
- Partial fix for the lockscreen flickering when locked/unlocked rapidly (with smartass).
- Very small tweak to other smartass parameters.
FlyKernel-12pre3
- Fixed frequency table according to Radu's comments. Frequencies which are not on PLL2 have been removed!
- Tweaked smartass to spend more time at the lower frequencies to improve battery life. Also smartass's allergy to 19Mhz has been cured!
- Some configuration tweaks, mostly sleep related.
- 528Mhz frequency does not work well with OC, so it has been replaced with 518Mhz which does work fine.
FlyKernel-12pre2
FlyKernel-12pre2 optimized for CM based ROMs (default speed 576/352)
- Added compcache support
- Added 19Mhz and 264Mhz frequencies
FlyKernel-12pre1
- Lower voltages of high frequencies (>= 528Mhz)
- Added ext4 support (I currently use it for dual booting)
- Interactive updated (does anyone find it better than smartass? in what scenario?)
- Smartass fixes and optimizations - should be more responsive now and battery life should (hopefully) still be excellent.
- Camera backport from .32 (12pre1-cam32)
FlyKernel-11c
FlyKernel-11c #66 (Generic)
FlyKernel-11c-BFS #67 (Generic)
- Smartass: now wakeups up from sleep first at 528Mhz (no OC), to hopefully help with wake up issues.
- Bunch of fixes/optimization from CM espresso kernel and from Decad3nce (see github)
- BFS version
"Optimized Kernel Packages" (only for CM6 based ROMs: Floyo, Elelinux, Froyd):
Find the appropriate kernel for you by its name in the FlyKernel-11c directory
The naming conversion is:
flykernel-11c-CM-<min>-<max>.zip (with boot animation)
flykernel-11c-CM-<min>-<max>-nologo.zip (no boot animation)
flykernel-11c-BFS-... (BFS version)
FlyKernel-11
- New smartass governor (see technical detail below). Previous governors still supported.
- Added IPv6 (only for Google Googles?!)
- Fixes camera freezing CM6-based ROMs (thanks Ninpo for a "code cleanup" which fixed this )
- Fixes detection of USB connection during boot on CM6-based ROMs.
- Various squash-sets imported (see github)
- NORMALIZED_SLEEPER disabled.
FlyKernel-10a (rapidshare megaupload)
- Optimize some sleep/idle code (thanks to ninpo)
- Add module for IP header compression - hopefully this helps google apps (inspired by ninpo).
FlyKernel-10a-BFS (rapidshare megaupload)
- BFS version of 10a.
- Whats is BFS? see wikipedia and more details here.
FlyKernel-10
- Fixes for Froyo ROMs (FroydVillain and Elelinux)
- Added some more modules inside the kernel (notably using VPN should now work). I am now more aligned with the modules included in other kernels (well mainly ninpo's kernels), so hopefully you should not run into any missing modules.
I even added support for ext3.
- Generic update for all ROMs.
Flykernel-09:
FlyKernel-09 for VR12,RCMix,ChoclateEclair,Modaco and SuperHero
FlyKernel-09 for Kimera and Sensehero
FlyKernel-09 for MMod 1.2.3
FlyKernel-09 for FroydVillain and elelinux - Beware there are problems with 09 and Froyo ROMs.
FlyKernel-09 for CM6
- Added the excellent minmax governor.
- Removed interactive as it does not behave well at all - just use minmax
- added version which supports the 288M data partition - removed now since MAX appears to be fading out - just use dalvik2SD instead.
FlyKernel-08
FlyKernel-08 for Froyo and ASOP
Added Mike Chan's interactive governor, adaptation to Hero by Nadlabak and Ninpo. Added some tweaks of my own - now works well also with big frequency table.
Tweaked conservative governor for better performance.
Fixed/cleaned kernel co/nfig and modules - among other things iptables should work fine now.
Bigger frequency table.
FlyKernel-05 (BFS)
BFS version of the FlyKernel-04
FlyKernel-04
Based on HTC 2.6.29 official kernel source.
Includes patchset 2.6.29.6 and various fixes
Boot OC - Only for Sense based ROMs (The smart update script added in FlyKernel-12 provides a cleaner and better solution for all ROMs)
Boots very quickly by setting the OC speed right from the start. Also sets the original HTC boot animation which is quicker for most ROMs. Finally, replaces the 09zipalign with 09betterzipalign (again thanks ninpo).
Please have a backup before you try this, as there is no other easy way to undo this.
Select the update file according to the speed your phone can handle:
boot @ 653/160: http://www.multiupload.com/5RAXNJ7AWY (rapidshare megaupload)
boot @ 672/160: http://www.multiupload.com/RRQ0HYI8O8 (rapidshare megaupload)
boot @ 691/160: http://www.multiupload.com/20AJV7FLQI (rapidshare megaupload)
boot @ 710/160: http://www.multiupload.com/WHROUYNGQ6 (rapidshare megaupload)
Theoretically, this should now work on any ROM and any OC kernel. I have tested the 691 update on VR12 and Froyd 1.4 with my kernel and it works fine. Above files (now with "_" at end of name) updated to also work on ChocolateEclair and hopefully other ROMs on 31/8.
Note that in my recent kernel versions the lowest frequency is 176, so it will boot with a min frequency of 176.
cool.. will try. like the idea of overclocking before boot
can you post a diff file of what you modified?
diffs of which change?
there are a lot of changes and fixes, which range from fixes by me in the source code, to just copying/applying files from others.
I think it would be better to keep this thread open for issues and questions about the usage of these fixes. Still I will be more than happy to share anything I have done - please contact me with the exact change you are interested, either by PM or open a new thread if you think it is of general interest for developers.
There are literaly dozens of different kernels floating arround, all of which are always "brand new super fast ultra optimized". From a user perspective it's hard to tell which one is the best. I think this community needs more openness in the developpement. I think it would be a good habit if developpers posted their diff files (of everything) instead of just saying that they made "optimizations".
thanks for your work
zorxd said:
There are literaly dozens of different kernels floating arround, all of which are always "brand new super fast ultra optimized". From a user perspective it's hard to tell which one is the best. I think this community needs more openness in the developpement. I think it would be a good habit if developpers posted their diff files (of everything) instead of just saying that they made "optimizations".
thanks for your work
Click to expand...
Click to collapse
Trying it out might help in deciding which is the best for you. There is no such thing as an absolute best, sorry. To each his needs and his preferences. I also included a convenient undo update script which restores the original kernel.
Personally, I am not aware of any other kernels for the VillainROM (except the original one by ninpo) and for me my kernel works better. Additionally, I have gotten very good feedbacks for my kernel and fixes on iandroid (using HebVillain which is very tightly based on VR12). So I thought others here might want to try it and maybe would also like it. Please also feel free to bash it, but please try it first and then reply with comments which I can relate too.
Finally, I am all for complete openness: If you are really interested in the kernel sources, you can find them along with all my changes here which could be of great to help to you especially if you want to compile the hero kernel yourself. In such a case I would recommend starting from here. The biggest other change is the RTL fix, for which you find the diffs here (it is verses the eclair branch of the android source code). As for the other files & changes I did, I have tried to detail as much as possible in my original post.
Feel free to contact me (also by PM) if you want more info or help.
I just installed your Kernel and the Boot Optimization and brother my phone is flying!!!! GREAT JOB!!!
100% recommended flash for your VR12
THANKS!!!
yep!
all great! you are the MAN =)
good work erasmux, does it work with Arabic language with Arabic fonts installed ? I mean connected letters
Thanks a lot
I hope it does. I don't use Arabic, but if there are problems, report them and I'll do my best to fix them.
Good job erasmux!
Problems for me.....
Installed Kernel & Optimization and Boot time optimization
Made all my icons go to pot,
"problem loading gadget" on powerbar,
"problem loading gadget" on Battery Meter Widget
Game Icons, CoPilot live, System Widget all showing default app icon.
Lost a WHOLE LOAD of installed apps, simply not there listed any longer. So many gone I can't recall what I have lost.
Tried the undo file Original VR12 Kernel:
Got my apps back but still probs with some widgets, boot screen remained the HTC one (didn't revert to the villian screen)
First, I have fixed the kernel restore file in the original post to also restore the original villain boot animation, note that the new file is called: V12-RestoreKernel_.zip (with additional _ at end)
Thanks, for the remark.
Regarding the apps, that is very weird. Did you get these "problem loading gadget" on the screen or where? A logcat from the start of the boot would be very helpful (although I can understand if you don't want to flash it again just to help me debug...).
Regarding the widgets (when the apps do appear) ,try clearing the HTC Sense data (unfortunately this will reset your desktop but it should restore your widgets and its better than having to reinstall everything).
I'll have to have a go later.. tied up at the mo..
Prob loading gadget appeared on the screen (still does).
Will try clearing sense and post back later.
EDIT: Clearing Sense worked. Thanks.
made battery callibration (http://www.villainrom.co.uk/viewtopic.php?f=97&t=1789&start=20#p19769).. full charge (~17:15).. after 5 hours using phone.. 5-7 calls (1-5min each), 30 min wifi and playing =) and now ( 22:40) 99% battery!!! blja, im very happy!!!!!!!!!!
cpu always 245-576mhz
only like with original VR12 kernel after few hours of use at 576mhz linpack score down from 2.5 to 1.8 , but after installed autokiller ( preset 60mb) it's always 2.45-2.57
now i think VR12 the best!
Thank you one more time! will write back tomorrow eve =)
is this included stuff really usefull or it can be disabled?
ipv6 (lot of different options)
LZO and ARC4 crypto stuff
extra PPP stuff (MPPE, PPPOLAC, PPOPNS)
DSCP and TCPOPTSTRIP
INET_TUNNEL
XFRM_IPCOMP
CPU_FREQ_GOV_CONSERVATIVE
the /proc/config.gz (kernel .config support)
Also, I noticed that the device boot with mem=64M. Does it mean that the rest of the RAM isn't used?
AFAIK the only way to change this is to recompile the kernel.
Many of what you said I saw requests here on XDA that kernel developers add (there applications which use it). Please note that many of those modules do not automatically load and need to be manually loaded so they should not have any effect.
Others stuff, mainly the IPv6 stuff i doubt anyone uses - must have "inherited" it from the config i used as a base. I will look into it for future release if I can remove that stuff.
About the mem=64 I am not sure what that is, my phone is definitively using the full memory. I will also try to understand and possibly adjust that for future releases.
Thanks for the input.
An other question, is a kernel really tied to a specific ROM? I have VR12 right now so I could try it, but I was also thinking of upgrading to a 2.2 ROM.
About the modules, I think that most of the stuff that I noticed was compiled in (=y) and not as modules (=m). If they are only used by 1% of the users, I think it would be better to have them as modules and make sure that they don't load automatically at boot.
Also, do you know if it is better to have a small frequency table (with, let say, only 3 choices) to avoid excessive frequency switching?
Is the dalvik to SD trick included worth it for those of us with the original 2GB SD card?
[ROM][08-06-2012] ~×~ EliteMod & Kernel CM7 ~×~ [sd-ext/swap] (ics has own thread)
EliteMod 120316 + EliteKernel 120319
Turbo just got a new meaning.
This mod is a custom ROM based on CyanogenMod7 nightly and modified CM7 Kernel.
The primary aim is to dramatically increase device speed without requiring frequencies above 1GHz in daily use.
The secondary aim is to improve battery consumption where possible by fine-tuning system settings.
The bonus is getting rid of some annoying post-flash steps and settings.
To achieve this required highly experimental steps outside of the scope of Android's security system and direct intervention in userspace.
Be aware that I made this mod primarily for myself, I went to extremes to squeeze the last bit of performance out of my device. Expect no flashy stuff, just raw power and great base for your customization. I guarantee no support whatsoever and any modifications you make to your device are solely your responsibility. It's a good idea to nandroid backup first!
Warnings - must read:
1) Do a nandroid backup, this ROM is not for everyone.
2) Full /data /cache wipe is mandatory before moving to EliteMod, even from CM7! Not kidding!
3) This ROM relies heavily on the bundled EliteKernel. Flashing any other kernel unless I explicitly put a link in download area is probably a bad idea.
4) Flashing gApps or any performance-boosting packages is not recommended. Latest gApps are already included and tweak scripts may in some extreme cases break sd-ext support.
The ROM requires a manual reboot after account setup, you will see REBOOT REQUIRED on screen. Tap it and reboot the device as usual to apply additional tweaks. Any settings done before this reboot may be lost.
6) If you want to do a "Factory Reset" of this ROM, wiping /data /cache /sd-ext wipe is not enough. You must re-flash the zip to really start clean.
The usual: Do not use TitaniumBackup to restore System components unless you know what you're doing. Restoring LauncherPro user data will forfeit fine-tuned launcher settings. Wipe deletes battery stats and recalibration is necessary to see real battery usage. You can backup your battery stats first before wiping - just use my tool - EliteMod will automatically restore the backup and save you the need to recalibrate. If you really want LWP or ADW, mv them yourself from /data/local/ as well as live walpapers and other useless garbage.
Some screenshots of the default launcher + my customized homescreen:
{
"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"
}
Changes from stock CM7 nightly:
- moarrr speeeed (optimized for lower frequency range to save power)
- kernel tweaks for better snappiness/battery balance
- more battery 100% guaranteed
- replaced ADW with LP (it crashes once after boot but still the damn fastest out there) and Go Ex
- replaced gallery with QuickPic
- Opera with performance tweaks
- added some MIUI stuff
- extra sounds and bootanim for my convenience
- removed LWP
- more in changelogs
Credits:
Big thanks to all the amazing devs who made this compilation possible.
Cyanogen and crew for his amazing ROM base
Federico Carnales for the smoothest launcher
Nanling Zheng for the best gallery app
SparksCo for the original sd-ext mounting script
JaeKar99 for the boot anim
Sybregunne for his OC daemon
nhnt11 for the gorgeous NTSense themes
MIUI team
Virtuous team
And many others I'm sure I forgot to mention - thank you and keep it up.
Download Link
Download from my high speed server:
High speed download:
http://elite-force.eu/elitemod/EliteMod120316.zip (see THIS for sd-ext and ext4 migration)
Mirror (slower):
http://www.mediafire.com/?3k5bvbk5uinn4no (see THIS for sd-ext and ext4 migration)
Standalone CM7 Kernel:
http://elite-force.eu/elitemod/MOD_EliteKernel_120319.zip (for any CM7 nightly based ROM, including EliteMod specifics)
Standalone ICS Kernel:
http://elite-force.eu/elitemod/MOD_EliteKernelICS_120608-79.zip (for any CM9 or AOKP based ROM = do not use with CM7 based EliteMod)
(SEE THIS if you have sd-ext or swap partition on your SD card)
Old versions:
Old versions:
I will be trimming old versions soon, here are most mirrors http://www.mediafire.com/?613ufmrzd2ovt
Click to expand...
Click to collapse
Undervolting tools (Windows only):
http://elite-force.eu/elitemod/UV_TOOLS.zip
Click to expand...
Click to collapse
Mods, fixes and tools:
http://elite-force.eu/elitemod/TOOL_BackupBattStats.zip (flash to save battery stats to SD)
http://elite-force.eu/elitemod/MOD_OldVending2.zip (flashable/default)
http://elite-force.eu/elitemod/MOD_NewVending3.zip (flashable)
http://elite-force.eu/elitemod/MOD_GTalk2.zip (flashable)
http://elite-force.eu/elitemod/MOD_OriginalDockIcons.zip (flashable, restores LauncherPro dock icons to EM default)
http://elite-force.eu/elitemod/MOD_GPS_Stock.zip (flashable/default)
http://elite-force.eu/elitemod/MOD_GPS_CM7.zip (flashable)
Click to expand...
Click to collapse
Old mods only up to #244:
http://elite-force.eu/elitemod/MOD_UmaroKernel_106.zip (flashable/default)
http://elite-force.eu/elitemod/MOD_TiamatKernel_114.zip (flashable)
Click to expand...
Click to collapse
Kernel source:
http://elite-force.eu/elitemod/elite_kernel_vision_source_120122.rar
Click to expand...
Click to collapse
Frequently Answered Questions:
- if the phone is not smooth, make sure you only have ONE app that controls CPU active at a time. Daemon OR SetCPU OR System Tuner etc. You can disable other apps by not giving them superuser access.
- changing your locale to english-us fixes the new market issue if you have problems but don't want to flash the old market.
- to save even more battery, undervolt your CPU by following the guide below and my easy to use UV TOOLS package. Alternatively use this program to modify your voltages https://market.android.com/details?id=com.incredicontrol .
- please include your ROM and kernel name if you ask an undervolting question in this thread and you are not running EliteMod
Click to expand...
Click to collapse
Recommended SetCPU settings (daily driver - EliteKernel only):
P7 (Temp > 46C) @ 122-768 smartassV2
P6 (Charging) @ 768-1248 smartassV2 (do not set too high, it can get hot if you use navigation in a car)
P5 (Screen Off) @ 122-768 smartassV2
P4 (B < 15%) @ 122-864 smartassV2
P3 (B < 30%) @ 122-902 smartassV2
P2 (B < 50%) @ 122-940 smartassV2
P1 (B < 101%) @ 122-1036 smartassV2
Click to expand...
Click to collapse
These settings implement my own "Final Fortress"(tm) philosphy of battery management. The speed will decrease progressively with battery discharge - basically this will make your battery last longer the longer you are not charging. The goal is to save that precious last drop of power you might need in a tight situation at the end of a long day. All that without sacrificing speed when you have plenty of charge left. You should not notice significant speed decrease until you hit the reserve @ 15%.
UV hint: If you've built your own stable undervolting table, you can maximize speed with no impact on battery by aligning the max frequencies to your specific voltage peaks. (example: if there are 3 different frequencies stable on the same voltage, always use only the fastest of the group)
~CHANGELOG:
(changes with ! require full wipe)
120319 (kernel only)
+ allowed undervolting all the way down to 700mV
120316
+ updated to latest kang
+ updated apks
+ much more resilient sd-ext mounting
+ verbose mounting script (see logcat for debugging)
+ tiny sd-ext performance increase
120315
+ latest kang
+ updated apks
+ new performance tweaks
+ optional sd-ext and/or swap support
+ relaxed swap priorities compared to experimental build
+ tweaked sd-ext I/O speed (ext4 only)
+ tweaked internal storage I/O speed (need ext4 on /data and /cache)
+ fixed Opera settings transfer
+ new set of Opera tweaks for sick performance
+ removed ROM Manager, recommend using 4EXT recovery from now on to take advantage of ext4 I/O tweaks
+ forcing dalvik-cache to internal memory for performance reasons
120310
+ latest kang
+ updated all apks
+ Scary not used by default (screen-off is now @ smartassV2 /w 768MHz max)
+ OC Daemon disabled by default, use control app to enable
+ default UV not applied by script (it is built into the kernel anyway)
+ new boot anim
+ different default theme
+ speedy postsetup script on update (second boot no longer takes eternity)
+ enabled swap support in kernel
+ improved kernel performance
120122
+ 22-01-2012 Kang build
+ added freqs below 245MHz with heavier UV
+ switched to andrev_oc and daemon
+ changed default wake frequency settings to 122-1036, SmartassV2
+ reverted ondemand gov to CM7 defaults
+ updated all apks
+ greatly improved ROM update speed (second boot)
!+ lockscreen clock not centered by default (weird in landscape)
+ changed default data mode to auto instead of preferred
+ updated default UV table in userinit.sh to match kernel internals
+ updated UV_TOOLS package to match EliteKernel
+ added tweaked Go Launcher Ex + most widgets + Sense theme
+ added 2 Sense themes to CM7 theme manager
120107
+ Updated to 05-01-2012 kang
+ Fixed garbage collection bug
+ Tweaked garbage collection and hardcoded defaults to standalone
+ Tweaked SmartassV2 for better scaling (EM + standalone)
+ Tweaked Scary for better battery to do better what it's supposed to do (EM + standalone)
+ Tweaked SIO scheduler for better I/O speed and battery (EM + standalone)
+ raised default frequency from 940MHz to 1GHz
+ lowered default frequency from 768MHz to 245MHz (raise back for more smoothness if you don't care about battery)
+ Tweaked storage subsystems for better I/O performance (EM + standalone)
+ moved hard-coded kernel settings from ROM to Kernel config (better maintainability)
+ updated all bundled APKs
+ updated SU
+ if you're using SetCPU, I recommend to update your profiles
111227
+ improved kernel performance
+ fixed undervolting support
+ released a standalone kernel
+ Important: Use the 111224 to 111227 patch instead of standalone kernel to improve stability above 1200MHz
111224
+ changed versioning to a date string until nightlies resume
+ updated all apks
+ updated to latest kang build 111222
+ faster new market as default
- dropped support for Umaro and Tiamat Kernel
+ EliteKernel 111224
+ major performance improvements
+ SmartassV2 governor
244
!+ new Opera tweaks
!+ wifi sleep fix
!+ updated settings template for 2.3.7
+ new GPS driver
+ camera fixes
+ performance and battery tweaks
+ updated all bundled apks
+ fixed goggles and youtube
+ new superuser + binary
227
+ loads more speed
+ dramatically reduced stuttering under heavy load
+ highly optimized Opera for butter-smooth browsing (tweaks for full wipe only)
+ QuickPic is now default gallery
+ set K9 mail as default email app
+ re-based on latest nightly, obviously
+ more
209
+ fixed camera effects
+ updated DSP speaker profile
+ some performance tweaks
+ support for Virtuous OC daemon (install SetCPU to disable it, uninstall to enable)
+ default undervolting profile (for people who don't care, the tailored real deal is far better)
+ default market is now the old one to prevent problems on non-us locales
186
+ first public release (CM7 nightly #186 + Umaro 1.0.6)
Click to expand...
Click to collapse
Changelog
NIKER's UnderVolting Tools Manual
Friendly warning: If you use this guide with any ROM or Kernel other than EliteMod and need to ask a question here - mention your ROM and Kernel in your post or I can't help you.
Be aware: This guide and the default voltage file assume you are using EliteKernel, other kernels will require different starting point voltage table.
Introduction:
By undervolting I mean decreasing voltages at which your CPU operates on specific frequencies.
If done properly, this can lead to dramatic increase of battery life with no performance loss, it also decreases CPU temperatures.
If done wrong, this can lead to freezes, graphic stuttering under heavy load or unability to boot without reflashing. Do a nandroid backup NOW!
I take no responsibility for your modifications, burned CPUs due to too high voltage and/or frequency, data loss, nuclear explosions, your girlfriend breaking up with you etc. You know the drill.
You should know this takes time - a lot of time. I spent 3 long evenings optimizing my table but I didn't have these tools to help.
You should also know this has to be done just once and you can reap the benefits of insane battery life with any ROM or kernel that supports undervolting - forever.
Essentials:
I am assuming you have a Windows PC at hand. SetCPU installed (disable profiles and on boot for safety), YouTube installed and Angry Birds or similar graphically intensive game of your liking for stability testing.
Next download the UV_TOOLS package I provided above, extract it somewhere and let me explain what each file does:
tools folder just contains ADB essentials and a simple free unix-capable text editor
voltages.txt - this is THE file you are going to edit and consequently THE file you never want to lose after you are done.
voltages.default.txt - this is a copy of the starting point for your convenience
start_edit.bat - this will open the voltages.txt file in an improved text editor capable of unix line endings, we are going to use this editor to make modifications to the voltage table within voltages.txt. Windows notepad is not sufficient for this task!
undervolt_temp.bat, undervolt_temp_periodic.bat - these two files are your best friends, they will push the voltages.txt to your device and apply it temporarily. It's effects will be lost after reboot. Periodic variation will push the file every 10 seconds, allowing you to always have the latest saved version of your voltage table on your device. Some may prefer the normal variant that will only re-push on a keystroke.
undervolt_persistent.bat - be careful with this baby, it does the same job as undervolt_temp.bat, but permanently so, simple reboot will no longer save your ass after you use this. You don't need to wait until you have all 4548648 frequencies optimized but do not use this unless you are pretty sure you have a stable voltage table.
remove_screwup.bat - did you just use undervolt_persistent.bat and your vision threw it back in your face and wouldn't boot? This will save you - 100% guaranteed.
Step by step guide:
First send your girlfriend to sleep, get a huge cup of tea, kick back, run a movie and connect your device, this is gonna be a long night and a lot of reboots.
Do a nandroid backup. Copy it to your PC, **** happens and we don't want that.
Run start_edit.bat - voltages.txt will open, this is not the stock voltage table, it is my own table with +25 overvolt added to every entry. Let's take a look:
Code:
echo '245760 900' > ./vdd_levels
...this says that for frequency of 245MHz the voltage will be 900mV. Valid voltages for vision are ranging from 750 to 1525.
Our objective is to find the LOWEST stable voltage for each frequency (yes - I know there's a lot of them). If you set it too low, your device will freeze and you will need to pull the battery and reboot (suggest removing your battery cover now). Too high frequency should not freeze your device but they will increase operational temperatures slightly and of course battery drain.
As I said the provided voltages.txt is specific for my device with slight overvolt, so let's see if your device can handle it or not - run undervolt_temp.bat to push and activate the default table. SetCPU to 122-1036 ondemand. Now if by now the device haven't froze, it's a good sign.
Next step we will test stability - connect to wifi and disconnect charger. Run youtube app, run a demanding test video with high quality - in high quality mode. The video should not stutter weirdly and the device should not freeze. Actually everyting should be pretty much normal. After 30s try to run your game instead for a half minute. After that hit the power button, let the device sleep for 30s and then try to wake it from standby. Should any of these steps fail, edit the voltages.txt, increase all the voltages by 25, push the changes and try the stabily test again.
Everything went smoothly? Well congratulation, you have taken the first step towards awesomeness. These settings should already improve your battery life compared to stock.
But we want moar battery! There's never enough when it comes to battery life. Well here it comes.
Take frequency 122880, it is the lowest ever used by your device out of standby. We currently have it set to 825, so let's try 800. Save the file and push the voltages to the device if you're not using periodic updater. Now SetCPU to 122-192 ondemand- it will be slow and tedious, frequencies below 768 can't run videos well so just play with your device a bit and watch for a total freeze. Short freezes that fix themselves are to be expected at those speeds. The good thing is, if your device starts suffering from sleep of death - the culprit is most likely one of these two frequencies - remember that.
Everything went well? Set all frequencies below 122880 to 800 as well. If not, leave them all at 825. Going any lower than 775 is asking for a sleep of death - just don't
Don't forget to always save voltages (floppy button) and then push them using the bat or use the periodic update - otherwise your changes have no effect, obviously.
Now move to the next frequency 192000 and set it -25 to 850. Leave SetCPU at 122-192 ondemand- we always want two adjacent frequencies switching while testing - it is during this frequency change when the device is most likely to freeze. It also triangulates the problem to these two frequencies, making it easy to fix a problem. Test stability by whatever means - no videos yet. If everything works you can try for 825.
Do this for every frequency up to 768.
Undervolt 122-192 then 245-368 then 768-806.
By now you have the sleep frequencies covered and your device should last incredibly long on standby.
Now optimize each and every frequency up to the maximum you want to use on daily basis. For 768MHz and more use additional video stress test.
Hints:
Never lower voltage more than 25 at a time between tests.
Always test with ondemand between previous and current frequency to ensure stability.
Consequently never lower more than two adjacent frequencies in one step - and even that is unsafe (but twice as fast, obviously), missing one unstable frequency means long and tedious testing process to find the culprit - you have been warned so don't try to cheat
Best tests for stability are streaming movies, they stress every component to the limits much more than any synthetic test. Even when SetCPU stability tests succeed, video streams tend to have much lower tolerance for low voltages - the video will stutter before it's even low enough to freeze whole device, do not underestimate this. Also do not mistake buffer stuttering for a CPU problem, the device would eventually freeze if it's CPU, stay close to your wifi AP.
Secondary test could be a game that doesn't stress the device as much - that will test frequency switching. Angry birds worked well for me and its fun
SetCPU profiles:
when you've finally built your own stable undervolting table up to your maximum desired frequency, you can maximize the impact of your hard work on battery by aligning the max frequencies to your specific voltage peaks. (example: if there are 3 different frequencies stable on the same voltage, always use only the fastest of the group)
Does your table look like this?
Code:
echo '368640 875' > ./vdd_levels
echo '768000 875' > ./vdd_levels
In this case always use 768 instead of 368 in setCPU where possible!
Higher frequency will do same work much faster
and in turn the CPU can sleep longer - saving battery.
kewl thanks bud
Isn't umaro an older kernel? Why not use a newer kernel. Just curious
Sent from my HTC Vision using XDA Premium App
A month old kernel is not enough to justify one that is not tried and tested unless it offers something extraordinary. Besides it offers all features one could ever dream of. Smartass, greaselightning, undervolting, very granular OC steps and mainly great stability. If you have a better candidate I will gladly take a look
I've used tiamat kernel it's pretty good and should have vipermod now so you can control voltage
Sent from my HTC Vision using XDA Premium App
If we can't flash the Gapps over the ROM, then how are we supposed to use it properly? Are they included in the ROM itself?
Mardenator said:
If we can't flash the Gapps over the ROM, then how are we supposed to use it properly? Are they included in the ROM itself?
Click to expand...
Click to collapse
Probably prepacked already
Sent from my HTC Vision using XDA Premium App
Any type of screenshots?
nik3r said:
A month old kernel is not enough to justify one that is not tried and tested unless it offers something extraordinary. Besides it offers all features one could ever dream of. Smartass, greaselightning, undervolting, very granular OC steps and mainly great stability. If you have a better candidate I will gladly take a look
Click to expand...
Click to collapse
**** the haters. Bleeding edge is not always the best edge to have.
I'll check into this in the next day or two.
This is really fast, so far no problems except market. I had to replace the new market with old one because it was force closing within 15 seconds whenever I opened it. Anyone else having similar issue with new market? I seem to have it on ILWT cm7 too.
Other than that, I think I'll keep this rom for awhile. Will see about battery life..
Sent from my HTC Vision using xda premium
miksa666 said:
This is really fast, so far no problems except market. I had to replace the new market with old one because it was force closing within 15 seconds whenever I opened it. Anyone else having similar issue with new market? I seem to have it on ILWT cm7 too.
Other than that, I think I'll keep this rom for awhile. Will see about battery life..
Sent from my HTC Vision using xda premium
Click to expand...
Click to collapse
same market issue here, anyway the new market has never worked for me on cm7.
the rest is quite flawless, ill see how my battery does later and report back.
That is an old issue and it had an easy fix. If I remember correctly all you had to do was change the language of the system to "English US" in Settings->Language&Keyboard. It happened to some people on CM based roms, not sure about other roms.
tsubus said:
That is an old issue and it had an easy fix. If I remember correctly all you had to do was change the language of the system to "English US" in Settings->Language&Keyboard. It happened to some people on CM based roms, not sure about other roms.
Click to expand...
Click to collapse
go it working right away. thanks for the tip!
Does any body have a quadrant score for this rom yet? just curious.
Quadrant is not the best way to determine anything else than gaming performance but just fyi I reached 3000 points at 1440MHz @ performance, didn't bother to try more.
EDIT: Curiosity got the better of me - 3591 points at 1.9GHz.
The market issue is weird, I am not EN-us myself and it never acted up. I can provide old Vending.apk in flashable form if you want.
As for the screenshots argument - its your regular CM7, nothing special visually except LP.
AWESOME!
This is by far the SMOOTHEST, FASTEST, SEXIEST rom i have ever flashed and i have been lurking for a really long time. Thank you so much for this ROM.
Will try your rom.
would quake3 (kwaak3) timedemo benchmark be a decent way to test gains? I know it's mostly video but still, how to tell between roms?
Sometimes I want to be able to see an actual speed difference from the roms than just placebo effect but it seems hard to find the right benchmark..
Thanks
eagerly waiting for the next CM7 nightly to play some more with it but looks like the automatic compiler has some problems.
kaijura:
Graphic benchmarks will not tell you much about day to day performance.
You need to take storage and sdcard r/w speeds, governor's ability to scale the CPU properly and garbage collecting efficiency into account to tell the difference - they have all been tweaked for better experience in this ROM. Synthetic benchmarks just can't test all of that.
This is a simple STARTER GUIDE to kernel features/parameters and everything you need to know about custom kernel goodies before you consider flashing them. I’d be glad if you could help me complete this guide. Thanks to @Shan89 for his fantastic guide which inspired me to collect this.
First of all I’d like to thank all kernel guys who put countless hours into this to bring us the features which I am going to explain soon. Especially: XMister, n3ocort3x, Kozmikkick, Maxwen, Showp1984, faux123, TripNRaVeR, Alex-V.
Overview:
Post 1:
A.: What you want to know about the CPU/GPU of your device
B.: Custom Kernel Features
Post 2:
C.: Built in kernel features with no user control
D.: FAQs (Frequently Asked Questions)
More coming Soon!!!
Post 3:
E. Repacking
F. Useful Tools and Guides out there
More coming Soon!!!
A: What you may want to know about the CPU/GPU of your device:
HOX is powered by nVidia Tegra 3 which is a Quad Core CPU and it is said that have a Core Frequency of 1.5GHz. Also nVidia Tegra 3 comes with ULP Geforce GPU which is at 520MHz in all custom kernels available. You may want to know that your HOX can go up to 1.5GHz of single core and 1.4GHz of 4cores active with Stock kernel (The kernel that comes with your device out of the box). However custom kernels can perform 1.5GHz for all 4 cores.
nVidia Tegra 3 is in fact a 5 core chipset. The Advertising hype was about its 4+1 cores. So what is that one extra core? That core is called LP (Low Power) core. When the phone is in idle (sleep) this core is used. It is a weak core with 475MHz of processing power. It is there to save battery life as when we are in idle we do not need a whole 1.5GHz core to be active.
B.1: CPU/GPU/IO Features which come with Custom Kernels:
•NOTE: Enabling/Disabling these features are explained in the kernel forums. Here is a very simple example to get you up and running so that you don’t feel lost.
In the kernel forum it is said:
To enable S2W:
echo ‘1’ > /sys/android_touch/sweep2wake
So what on the earth does that mean?! It means install a terminal emulator program on your device (Here’s one). And then run it. First type “su” without the quotation marks and hit enter. It will ask for Superuser privileges. Grant it. Now type in the line above echo blah blah blah and hit enter. And bam! There you go, S2W is enabled. Always be advised that ‘1’ means enable and ‘0’ means disable.
Click to expand...
Click to collapse
OC/UC (As for OverClock/UnderClock):
As you may know, CPU or any other processing unit features a clock frequency. Over/Under Clock simply means raising/decreasing the clock frequency of CPU.
Reason: Why would one need to overclock? Because one needs more processing power. For example if you want to experience smoother graphic when playing high-graphic games.
Why would we need underclock? Higher processing power demands more battery. So underclocking helps us, reserve more battery. As for HOX, searching internet and texting don’t need much of processing power. So we can limit the processing power and save battery during low use of our device.
•Note1: OC/UC is not limited to CPU. GPU is also capable of OC/UC. And the interface for that is also available in the custom kernels of HOX.
•Note2: Gamers may not use GPU UC. Limiting GPU processing power impact significantly on your gaming experience.
UV (As for Undervolt):
Every frequency of a processing unit, demands a certain amount of power to be supplied. Undervolting to put it simple means decreasing the voltage of a certain frequency (or all of them).
Reason: The more voltage CPU/GPU gets, more heat will be generated. So mainly we UV to decrease the generated heat of CPU/GPU.
•Note1: One Frequency needs a certain minimum amount of voltage to perform correctly and the system be stable. Undervolting more than a certain amount of voltage will cause system instability.
•Note2: HOX is known for getting hot soon. So UV is a great workaround for your device to be cooler.
•Note3: UV does not impact battery life (or it is not noticeable).
•Note4: For ULTIMATE guide about Undervolting and safe values visit Shan89’s great guide here.
Separate X/Y OC interface:
This probably means that the kernel has separate OC interface (interface to control OC) for operation X and operation Y. To be more exact it means you can OC different values for X and Y.
Audio Min. Freq.:
This specify the minimum frequency of the CPU when Audio is being processed. Default min in custom kernels is normally 51MHz. But Audio needs some more processing power. Anyhow, with this you can change that value.
LP Core OC:
The name explains everything. OC for LP core of T3 chipset.
Reason: LP core uses very little battery. So as long as the phone stays at LP core, more battery will be saved. If LP is OCed, it means it can handle more complex processing tasks and can hold more before letting the device to wake main cores. So battery will be preserved!
•Note: These are work in progress features and mostly in beta releases of Kernels. So using may cause system instability and other issues. So use them if you know what you are doing.
Hotplug Control - NEW:
Hotplugging dynamically activates second CPU core ON on load conditions and turns second core OFF on low load conditions. (From here).
Click to expand...
Click to collapse
- first_level: The number here specifies the amount of load on the cpu for it to turn on all the available cores (4 cores online).
- cores_on_touch: This number specifies the number of cores to come online when you touch the screen. (2 is efficient, 4 for extra smoothness on touch, and so more battery drain.)
- suspend_frequency: When screen is off, you don't expect your device to be smooth (!!!) and snappy! Because mainly nothing important is happening when screen is off. The number here specifies the maximum frequency of the CPU when the screen is off. Screen Off Max CPU can be really a very low number.
CPU Governors:
Frequency scaling is the means by which the Linux kernel dynamically adjusts the CPU frequency based on usage of the device. Governors refer to schemes which dictate to the kernel how it should do these adjustments. (From rootzwiki)
To put it simple, Governors are the way that CPU frequency is adjusted according to the demand of operating system.
Selecting a proper governor for your CPU is crucial to the performance and battery preserving of your device. For example if you are low using your device you may use a more battery friendly governor and if you want to play games you may use a more power consuming performance governor.
•Note: See Shan89’s Great Guide about Governors to be familiar with each one of them and the ones that you should use in different situations here.
I/O Schedulers (As for Input/Output):
Input/output (I/O) scheduling is the method that computer operating systems use to decide which order block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'. (From Wikipedia)
To put it simple, Schedulers are the way reading and writing to the SD card is managed.
The same things that is said in the Governors part is applied here, too.
•Note: See Shan89’s Great Guide about Schedulers here.
ReadAhead buffer size:
In terms of reading data from SD card, there is a cache which is used as a buffer. The size of that cache is readAhead buffer size. The size has a direct impact on your reading speed of your SD. So giving it a right amount is crucial.
•Note: Kernel guys believe that 128 is the right amount for that and it is the default in most of the kernels.
File System “X” R/W (As for Read/Write):
Android by default doesn’t support all the File Systems (What are file systems?! See here). So some kernels may add certain file system R/W. The most popular unsupported file system is NTFS.
B.2 Features of Custom Kernels (AKA Goodies!!!):
S2W (Sweep2Wake):
With S2W enabled you can wake/lock your device by sweeping your finger from left to right (or right to left) on the hardware keys of your device (Pretty Cool, hah?).
Reason: Some people just don’t like the hardware power button! Or after some time it will become less responsive. And some will use S2W because it is cool!!!???
•Note1: S2W doesn’t affect battery life that much. It almost does not use even a little bit. But be aware this stands corrected as long as you don’t touch your device. Touching the device would cause in waking the device from deep sleep.
DT2W (Double Tap 2 Wake):
It is something like S2W to wake the device. Double tap on the screen to wake the device.
•Note: The note for S2W applies here, too.
BLN (BackLight button Notification):
With BLN enabled your hardware buttons will blink when you have notifications. It is an/a alternative/support for led notification.
FastCharge:
This feature makes it possible for the phone to ask for more current from USB host. So your device would be charged faster connecting to a USB host (Or USB Battery) Be aware that enabling FastCharge would block the USB access to your Phone Storage.
UMS (USB Mass Storage):
After ICS, google only allows MTP connection to the PC. Back at ICS there was a UMS which make available your Phone Storage as a Mass Storage device in PC. The Mass Storage advantage is that you can manipulate data on it but it cannot be done using MTP. UMS feature returns that feature to your device. A system interface is also needed which is available in ViperX ROM or Lyapota’s mod.
•Note: MTP vs UMS (From here):
MTP:
1. Can copy files over (like APKs) and then access on them on the device without mounting/unmounting.
2. File transfer is available immediately when plugged in without having to mount.
Mass storage:
1. Better security since you have to get past the lock screen to mount.
2. Is actually a real drive in Windows, so you can do all operations normally.
MHL (Mobile HighDefenition Link):
It provides the feature for the miniUSB to HDMI cables to work. To output the device screen using HDMI.
SmartDimmer:
SmartDimmer can intelligently vary the backlight brightness of your device screen to help maximize battery life.
•Note: Haven’t really tried this. You may try it yourself and see how it is.
MultiCore PowerSaving:
This feature try to group up tasks in the least cores possible. To put it simple, it will focus in using least cores for your tasks to be done. This means less cores are active and so more battery life. Also this will decrease performance.
•Note: To enable use TricksterMod app. 0 for disable and 2 for the most aggressive.
Core Control/Max Active CPU Cores:
As the name suggests, this feature allows the user to set the maximum active cores of the CPU. In other words, you can completely shut down some cores. The default value is 4 as we have 4 max active cores. you can reduce this to 3, 2 or 1. But 1 is not really recommended.
Note: Core Control is the feature of ViperX ROM.
B.3 Other Features:
Pocket Protection - NEW:
Using features like S2W and/or D2TW when the phone is in your pocket (with no specific cover) occasionally causes the screen to turn on. (as a result of being close to your skin and almost touching it). This feature is there to prevent such wake ups. It uses proximity sensor to determine if the phone is in a closed position to something. If that is true, the screen won't turn on. :victory:
Swap:
Swap is a space which provides help to RAM in situation of low memory. When you are low in RAM some data will be stored in Swap space (Mostly cache). Swap is a space on Internal (and/or External Memory) so swap is not fast in comparison to RAM, but it helps multitasking, because you could cache more app data to your memory. So the results are less Force closes because of low RAM and faster switching between apps.
Swap is not really used by default, or it is used with very low space. You can boost your Swap, and also know more about this. there's a very nice MOD called Turbo Boost which allows you to add more Swap using your unused space. See this.
zRAM:
In zRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (zRAM). So in other words, zRAM is a kind of swap in memory (see swap above). As the data is compressed not much memory needs to be preserved as zRAM. However, the CPU has to work more because compressed data has to be unpacked again when it is 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. (From here with some editing.)
Click to expand...
Click to collapse
What we need to know essentially lies here:
zRAM off = Low use data will be stored the way they are in the memory. This will cause no extra load on CPU, yet need more RAM.
zRAM on = Low use data will be stored compressed in the memory. This will cause extra load in CPU as to store or restore data, yet preserve more Free RAM.
The main use of zRAM is when you are using a heavy ROM that eats up all your RAM. This will allow multitasking to be more functional. On light ROMs, or for those who don't multitask much, this is not necessary.
Init.d Support:
There are some scripts that run every time your device boot up which are located in /etc/init.d Those are called init.d scripts. One of the most popular init.d scirpts that is available for Note 10.1 is this.
DriveDroid Support:
Gives the phone the ability to use DriveDroid.
DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go... without the need to burn different CDs or USB pendrives.
Click to expand...
Click to collapse
Take a look here for more information.
TCP Congestion Control:
The choices in this section, address how the operating system kernel manages flows of information in and out of the kernel, which is at some level the "switchboard operator" of your handset. More info here.
Better to leave this options as is. Cubic as the default of your kernel.
Dynamic FSync:
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data. (From here).
Dynamic FSync, makes it possible for fsync operation to be asynchronous when the screen is on, and synchronous when the screen is off. And what does asynchronous mean? Means OS issues fsync call, but not necessarily immediately at commit time for each transaction. It delays the FSync call for a certain amount of time. In case of a crash, the transactions not yet sync'ed in the last delay time before the crash may be rolled back, but the state of the data is always consistent. (From here).
Work in progress, will add more info soon.
C. Some built in features with no user control:
Tegra 4 Drivers - NEW:
First you may want to know what a driver is:
A driver is a small piece of software that tells the operating system and other software how to communicate with a piece of hardware.
For example, all printers come accompanied with drivers to install that tell the operating system exactly how to print information on the page. (From here).
Click to expand...
Click to collapse
So kernel guys (Trip to be exact) made it possibe to use some Tegra 4 drivers on Tegra 3 Chip of HOX so that we can enjoy the advantages of new drivers.
MPDecision:
Mpdecision decides when the second core shall be active and sets the idle and screen off freq while the governor decides when the freq should be increased / lowered.
More info at this thread.
CPU Quiet:
It's a dynamic CPU core management. More info here.
D. FAQs (Frequently Asked Questions)
MUST KNOW FACTS:
The modifications and changing values of kernel parameters will stick until the next reboot. They will be set to default when you reboot your device. So if you want them to stick, you have to do one of the following:
1. Init.d Scripts: Here is a complete guide, how to make one. Also you can use 'CS' app. Which is explained in Useful tools part of this guide (Post 3).
2. Set on Boot: The programs like Trickster Mod, have an option named 'Set on Boot'. If you want the settings you have in Trickster to stick, you have to check that option.
---------------
And a quote from the elite developer that everyone know:
However, if you put any trust in Quadrant scores you could use them to prove that dancing naked for 5 minutes in your garden affects device performance. - Chainfire
Click to expand...
Click to collapse
Q. I'm on Stock. How can I flash a custom kernel?
A. See this complete Tutorial, here.
Q. Is it dangerous to flash a custom kernel?
A. As long as you follow the instructions step by step there shouldn't be any problems. However flashing is always at your own risk.
Q. Why would I need to flash a custom kernel?
A. Because of the goodies I described in post 1.
Q. Which Kernel is more suited for me?
A. That really depends on you. You have to try the kernels and see which one is more suited for you. In Post 3 A little description about the kernels will be provided.
Q. AOSP or Sense???!!!
A. Sense Roms can be identified by their description. Just visit the page of your desired ROM and see what is its base. If it has 'stock' as the base it's sense ROM. If it has AOSP, AOKP, CM or other things then it is an AOSP rom. So identify your base before flashing kernel.
Q. I don't like this fastboot stuff. Why HOX can't flash boot via recovery?
A. That is because something called S-ON (Security-On) by HTC which prevent flashing boot.img via recovery.
Q. Repack?! What on earth is that?
A. Repack will be elaborated in detail in Post 3.
Q. Is repack needed for Kernel X and ROM Y?
A. See Repacking in post 3.
Q. Is there a kernel with OC interface up to 1.6 or 1.7?
A. Yes. Search!
Q. I just want S2W or UMS with Stock kernel, nothing more. Is there a kernel to provide that?
A. Yes, Alex-V Kernel v.0.3 is there for you. See Post 3 when it's ready for more info.
Q. After installing custom kernel I am experiencing battery drain issues. Why is that?
A. The current custom kernels do not have drain issues. Install Better Battery Stats and/or GSam Battery Monitor to figure out what is causing the battery drains.
More Info will be added soon.
E. Repacking:
All Android roms require a boot image to work (normally named boot.img). These files contain the ramdisk necessary to run the rom, as well as the kernel. Occasionally you may want to replace the kernel to add new features or fix bugs, but you must tweak the image to be compatible with your rom (And also as the ramdisk may contain some tweaks, to preserve those tweaks and add them to the kernel of your choice). (From Here).
Click to expand...
Click to collapse
The very main question "Is it really needed?"
Well, you don't really need to repack kernels for Sense/AOSP Roms anymore (Those days are gone!) as they already contain the tweaks and ramdisk to get almost all the ROMs up and running. But sometimes you may encounter some problems like Weak signal/Wifi or such issues. In that case, it is advised to repack your kernel.
How to Repack?
Before you start repacking you need these 2:
1. Ramdisk (boot.img) of the ROM you are using (Or you wish to use). It is usually in the zip file of The ROM which you flashed (or going to flash) via recovery. Just open the zip file and extract boot.img. Some ROMs put the boot.img in their OP (First posts of the respective thread). So if the ramdisk wasn't in the zip file of the ROM, take look at the thread of the ROM.
For preventing the confusion rename the boot.img to the ROM name + ROM version for example Renovate_F4.img
2. Kernel image (boot.img) of the Kernel you wish to use. Some kernels put it for download in their thread. Sometimes modules and image is both in one archive. In that case open the zip file if the kernel and extract boot.img. Make sure you don't replace the other boot.img from step 1. For preventing the confusion rename the boot.img to the kernel name + kernel version + the kernel base(Sense/AOSP) for example XM_305_Sense.img
Click to expand...
Click to collapse
a. Using online repacker:
1. Visit this site: http://nibble.cc/repack/index.php
2. In source kernel image, choose the ramdisk of the ROM. (ex. Renovate_F4.img)
3. In New kernel image, choose the kernel image. (ex. XM_305_Sense.img)
4. Hit 'upload and repack'.
5. Download the repacked kernel.
b. Using One Click Tool:
1. Copy the ramdisk and the kernel image to "kernels" folder which is in the folder of the tool.
2. Connect your device and run the tool.
3. Select "Kernel repack".
4. Select the kernel image in "kernel" section.
5. Select the ramdisk in the "ramdisk" section.
6. Hit "perform action".
7. The repacked kernel is in the "repacked" folder which is the folder of the tool. It's name is a combination of The kernel name and the ramdisk name so that it can be identified easily.
Note: You can also choose to flash the kernel. Just check "Flash repacked kernel". The tool automatically reboots into fastboot and flashes the kernel.
Note: You can choose to repack via PC in the tool. It is much more faster. And also you can repack without connecting your phone if you choose repack via PC (This feature works from version 2.1 or 2.0 I think. Check the thread for more info).
F. Useful Tools and Guides out there:
F.1. Tools:
Trickster Mod:
A little yet powerful program. It is almost the best tool that you can have on your HOX to change certain kernel parameters like UC/OC/Voltage Control of both CPU and GPU. Schedulers, ReadAhead BufferSize, Advanced Governor control. You can change features like S2W and SmartDimmer, too. Also you can set this changes to take effect on boot. Which automatically sets the parameters on device startup (preventing the defaults values to be set, again).
Trickster Mod - Google Play
CS - Custom Settings:
This app is exclusively made for HOX, so it supports most of the features of custom kernels. This app manages to set the values you desire by generating init.d scripts. So there is no set on boot operation by the app but by the scripts.
Custom Settings - XDA
One Click Tool:
This tool is created for One X, and you use it to repack and flash kernels. And by flashing I mean no CMD and other scripting stuff. This tool automates flashing (Though the flashing process via fastboot is not that much of a hard work!).
One Click Tool - XDA
F.2. Guides:
- Battery Life and Gaming Guide + UV/UC and everything explained! by Shan89
- Boosting gaming experience and maximizing performance for gaming by hamdir
More info will be added soon.
Reserved for later reading
Sent from my HTC One X using XDA Premium App
Desaf said:
Reserved for later reading
Sent from my HTC One X using XDA Premium App
Click to expand...
Click to collapse
Yeah, sure!
Sent from my HTC One X using Tapatalk 2
Added recently to the guide:
Post 1:
- ReadAhead buffer size
- Init.d
- TCP CC
Post 2:
- FAQs.
realy helpful
thanks mate for the information.
mandrive said:
thanks mate for the information.
Click to expand...
Click to collapse
Glad to be of help!
Sent from my HTC One X using Tapatalk 2
Recent added to the OP:
- Swap (In appearance of the nice Mod TurboBoost)
- Dynamic FSync (Tricky feature)
Will be added soon:
- Repacking
Nice tut
Sent from my HTC One X using xda app-developers app
Alex-V said:
Nice tut
Sent from my HTC One X using xda app-developers app
Click to expand...
Click to collapse
Thanks, man.
Sent from my GT-N8000 using Tapatalk HD
csec said:
Thanks, man.
Sent from my GT-N8000 using Tapatalk HD
Click to expand...
Click to collapse
Added with credits to my kernel thread..thx again
Sent from my HTC One X using xda app-developers app
Recently added:
Post 2:
- TEGRA 4
Post 3:
- Repacking
Will be added soon:
- Kernels reviews
Huuuuge guide
matt95 said:
Huuuuge guide
Click to expand...
Click to collapse
Just wanted to be a complete guide. Explaining everything.
Sent from my GT-N8000 using Tapatalk HD
csec said:
Just wanted to be a complete guide. Explaining everything.
Sent from my GT-N8000 using Tapatalk HD
Click to expand...
Click to collapse
You succeeded in it
matt95 said:
You succeeded in it
Click to expand...
Click to collapse
Thanks. Glad I could contribute to the community. :good:
Sent from my GT-N8000 using Tapatalk HD
csec said:
Audio Min. Freq.:
This specify the minimum frequency of the CPU when Audio is being processed. Default min in custom kernels is normally 51MHz. But Audio needs some more processing power. Anyhow, with this you can change that value.
Click to expand...
Click to collapse
Thanks for the guide.
I'm using CyanogenMod right now and I'm having problems with Audio over Bluetooth with the low power core of my endeavoru. I think increasing this frequency might help.
How is this called in kernel-land a.k.a. how do I find instructions regarding this? Asking Master Google was of no help, as I only found custom variants of the CyanogenMod kernel.
lordtillt said:
Thanks for the guide.
I'm using CyanogenMod right now and I'm having problems with Audio over Bluetooth with the low power core of my endeavoru. I think increasing this frequency might help.
How is this called in kernel-land a.k.a. how do I find instructions regarding this? Asking Master Google was of no help, as I only found custom variants of the CyanogenMod kernel.
Click to expand...
Click to collapse
What is your kernel and version?
What governor, what frequency?
What kind of problem are you having with your audio?
csec said:
What is your kernel and version?
What governor, what frequency?
What kind of problem are you having with your audio?
Click to expand...
Click to collapse
I'm running CyanogenMod 10.1 RC2 with the default kernel, which is the 3.1.10-cyanogenmod+inky-ghost kernel, according to About Phone.
Governor is ondemand, and the frequency is untouched - meaning, CyanogenMods defaults (51<f<1500).
The audio sometimes stutters, when I'm using my bluetooth headphones and the screen is locked - I assume, that's due to the low power kernel of the tegra chipset.
Can you help finding that setting, or recommend a good replacement kernel?
Left for posterity, but no further development will occur (see 4/30/2020 post)...
Here's a script that I helped some good guys out with developing "back in the day" (Franco's Dev Team - you can look them up!). Actually, it is a trimmed, consolidated version of the set-of-scripts we came up with. If you search, you can find osm0sis still hosts the original files, and those that I have been maintaining since the Galaxy Nexus went extinct (through L, M, N, and now O), I believe. Note that those scripts will no longer on Android 10 - and probably not even on 9 - so I don't recommend actually using them.
This script has all of the original tuning scripts put into a single file, having stripped out anything that stopped working between Kit-Kat and Android 10 (which was substantial), and some very small improvements I've found over the years. I also added a few things more to my personal usage preference for this Pixel-2/XL version. It has also been trimmed to work on the Pixel 2 / Pixel 2 XL stock kernel whilst outputting no errors, on all android versions through Android 10, and now on Magisk 19.4+.
Notes:
- This script is lean and mean, but it's not rocket science.
- I didn't invent anything here. Feel free to use (or not), distribute, alter, whatever; to your satisfaction, giving credit for redistribution only to "Franco's Dev Team", and maybe me if you're feeling generous.
- Again, I have verified it works on my personal Pixel 2 XL, and is compatible with all Android versions, Kernels, and Magisk versions.
- It actually improves many benchmark scores (you know the usual culprits) without lowering any on my device. But, you know what that's worth (one device, only a few items likely significant on a statistical basis).
- It won't make your phone run any worse. It might even feel a bit "snappier", but YMMV.
- If you feel this script is good, bad, or does nothing, feel free to thank me - or hang me in effigy, as appropriate.
- I do not plan to do heavy maintenance on this, but I will keep it up to date so it at least safely runs on the Pixel 2 / 2XL as long as I own one. I will post updates with a minimal change log (it's a script, you can read it!).
Disclaimer:
I can't see how this could possibly cause irreparable harm to any android device on which it is run.
However, I suppose untested configurations may (rarely) have slow-downs, reboots, or other effects.
REGARDLESS, it is offered as-is with no warranty, and you choose to run this at your own risk.
Requirements:
Root
BusyBox installation (I recommend the Magisk module by osm0sis)
Knowledge of how to execute a linux script and/or where to place it / allow permissions to run on boot
Usage:
Download attachment to your device
Place file in /data/adb/service.d (for Magisk-rooted devices, using Magisk 18.0+)
remove ".txt" extension (leaving the .sh extension)
Ensure permissions are right (0755)
Reboot and wait 2 minutes
Credits:
Franco's Dev Team, esp. osm0sis
Google
Others as noted in the script file header
Change Log:
Version 34 (98pks34.sh):
Version added with no disabling of zram.
V33 is still active for those who don't need / want zram.
V33 generic is still active as well (V34 generic would be the same as generic version does not alter zram).
Version 33 (98pks33.sh):
- Updated with Franco Dev-Team tuned Deadline scheduler (still the fastest). Script uses this if Deadline is available in your scheduler, else it defaults to using Noop.
- Other very minor tweaks based on testing, and some code cleanup
Version 32 (98pks32.sh):
- Updated for Magisk 19.4 (primarily eliminated mounting calls on / and /system to prevent root interference or verity problems due to SAR implementation now standard)
- Backed off the schedutil governor performance tweaks just a bit, still more performance oriented then v30 and prior, just not as extreme
- Removed wakelock blocking (for now) for evaluation. Most kernels already block safe wakelocks anyway. If I find none of the benefits I'm looking for, I may add them back in the next release.
- Released corresponding device-generic version due to important Magisk / SAR compatibility updates
Version 31 (98pks31.sh):
- Simplified some VM settings / reverted to stock where no difference was noted
- Simplified some block IO parameters / reverted to stock where no difference was noted
- Increased transmission queue buffer based on latest testing (still lower than stock)
- Tuned Schedutil governor settings to bias for more performance, reduce lag
- Increase GPU min frequency to 342 MHz step (2nd from bottom) based on testing to reduce lag
- Note that these changes did not appreciably affect battery life in testing
- Simplified output file write-out
- Released official "generic device" companion script of this version for those asking
Version 30 (98pks30.sh):
! GOOD TO GO FOR Q-FINAL / A-10 !
- Re-enabled stock zram - was causing freezes after about 24-36 hours of uptime
- Re-enabled vm tweaks for increased battery life (disabled pdflush periodic writebacks, lowered potential for large data writes causing hang-ups as a result in dirty ratios, adjusted cache pressure to not favor dentry/inodes quite so hugely over pagecache)
- Blocked a few more known and safe-to-block wakelocks
Version 29 (98pks29.sh):
Reverted some changes that were causing some serious jank / freezes:
- Went back to noop
- Reintroduced periodic pdflush writeback (although less frequent than stock)
Version 28 (94pks28.sh):
Biggest changes in a while!
- Increased run delay to 2 minutes to stay out of kernel apps' way
- Reverted tcp_ecn to 2 (stock) for slight decrease in network latency
- Substantial vm tweaks for increased battery life (disabled pdflush periodic writebacks, lowered potential for large data writes causing hang-ups as a result in dirty ratios, adjusted cache pressure to not favor dentry/inodes quite so hugely over pagecache)
- Right-sized nr_requests for any scheduler (not just noop) relative to built-in Android queue-depth
- Changed scheduler to deadline* with Franco Dev Team's tuning tweaks (still fastest i/o I can manage in testing)
* Device-generic version (94pks28generic.sh) was left unchanged with noop scheduler
Version 27 (94pks27.sh):
- Fixed for Android Q while keeping backward compatibility with prior Android versions.
- Increased run delay to 90 seconds to stay out of magisk module or kernel apps' way.
Version 26 (94pks26.sh):
- Updated one minor (but hard to find), error in mount option filesystem tweaks that had been causing data connectivity issues on custom ROM's using this script or BlackenedMod.
- SPECIAL THANKS to @sublimaze for testing iterations until we found the root cause of this issue!
Version 25 - skipped, test versions for @sublimaze to help me figure out data connection issues.
Version 24 (94pks24.sh):
- Updated ext4 filesystem tweaks for even better battery life and performance
- Small reduction of entropy pool size based on other user feedback
Version 23 (94pks23.sh):
- Change header to list new Magisk 18.0+ late-start boot service folder location
- SEE ALSO OP FOR THIS LOCATION
Version 22 (94pks22.sh):
- Force read_ahead_kb to 1024 for faster I/O performance on all realistic file sizes
Version 21 (94pks21.sh):
- Increased load delay at boot back to 60s.
Version 20 (94pks20.sh):
- Added .sh extension to file to allow more flexibility for future tuning (now just delete .txt, but leave .sh in the file name before copying to run location)
- Slightly increased load time at boot to 40s to ensure script runs even for users with many magisk modules
- Reduced foreground app schedtune boost to 5% (was 10%) for battery saving when multiple apps are open with no perceived detriment to performance or app switching
- Increase dirty_expire and dirty_writeback timings for less overhead, reduced battery, and improved performance with no ill effects noted
- Reverted GPU min clock increase due to my testing finding the speed benefit was not noticeable but battery life was negatively affected
Version 19 (94pks19):
- Reduced load time at boot (enabled by re-ordering of script) to 30s
- tcp_ecn set to 1 for across-the-board network speed enhancement when handshake allows
- reduced txqueuelen to 128 for network speed enhancement on 4g/wifi (less bufferbloat)
- added wakelock blocker courtesy of @xFirefly93, but only for blocking wakelocks I have actually seen in BBS for Pixel 2 / XL.
Version 18 (94pks18):
- Increase cpu governor up-rate-time; VERY significant battery help with no performance degradation noticed.
- Reduce vm dirty ratio and dirty expires slightly to reduce potential (although unlikely) excess caching and latency from memory write-out.
- Slight code re-ordering for potential quicker boot delay in the future
Version 17 (94pks17):
- Schedtune code cleanup
- GPU min frequency set to 342 (performance boost with no adverse battery drain per @xFirefly93 testing)
- Increase cpu governor down rate limit by 25% for better performance with minimal battery life impact.
Version 16 (94pks16):
- Revert dir-notify-disable
- Fix a minor dirty-expire vm derp I made many, many releases ago
- Adjust dev/stune/schedtune parameters to ensure users won't have frequency scaling issues on any kernel, allowing cpu's to actually settle and sleep. This wasn't likely before, but is now virtually impossible, while performance improvement during app switching is still present!
Version 15 (94pks15):
- Fs dir-notify disable.
- Schedtune parameter tweaks for performance increase.
Credit: Both of the above were initiated by @xFirefly93, I only slightly modified the Schedtune parameters.
Version 14 (94pks14):
- Revert disabling service_locator, otg_wakelock, and debug kernel modules - no real battery save noted in testing; and I had some issues with apps hanging that required location services that were resolved by getting rid of this code.
- Change rq_affinity from 2 to 1 - I verified with I/O benchmark testing that this provides a slight increase in I/O performance, especially reads and sqlite operations. No battery life impact noted during days of testing.
Version 13 (94pks13): Internal test build - not released (probably would have been unlucky anyway )
Version 12 (94pks12):
- Turn off iostats - by popular request (slight battery save)
- Increase vm stat_interval to 60 - Thx to xFirefly93 (slight battery save)
- Disable service_locator, otg_wakelock, and debug kernel modules - Thx to xFirefly93 (slight battery save)
Version 11 (94pks11):
- Delay script start by 30 seconds for users with multiple late-start scripts or other Magisk modules
- Increase timer for vm dirty writeback (saves battery from less wake-ups, cache integrity still reasonably protected by low dirty background ratio)
- Slight kernel entropy increase
Version 10 (94pks10):
- Increase min_free_kbytes - better performance based on testing
- Reduce entropy read_wakeup_threshold - to prevent blocking apps or commands if entropy drops
- Thrift ipv4 / network settings that were ineffectual - cleanup with better or same performance based on testing
- Reduce scheduler nr_requests - less overhead, subjective latency reduction
- Revert to default read_ahead_kb - better performance based on testing
Version 9 (94pks9):
- Slight change-up on kernel entropy settings to keep pool about half-full.
- tcp_max_syn_backlog and tcp_ecn parameters added (thanks @Juzman for getting me to look at these!) that seem to help network throughput slightly - they certainly don't hurt.
- Added fstrim for data, cache, and system partitions at end of script - because why not do this on every boot?
Version 8 (94pks8):
New file location noted in header: /sbin/.core/img/.core/service.d
- Need to place script in this directory for Magisk 16.3 onward
- Backward compatible for previous versions back to 14.5
Script now executes 70% faster after boot
- Only sleeps for 30 seconds; verified to still run through Magisk late start service
Added file system optimizations for /system partition
Adjusted min_free_kbytes to 7 GB from 7.5
- Should slightly raise available RAM for each node, no oom increase or other ill-effects verified through dmesg / kmesg logs
Reverted vm.vfs_cache_pressure to 20
- Less subjective latency based on testing
Script success / fail write-out file now time stamped for users local time rather than UTC/GMT
Version 7 (94pks7):
- Removed LMK (yay!) based on multiple requests, advice from @Scott, and my verifying that nothing I tried improved over stock.
- Added back in some block-level scheduler queue tweaks that are not consistent (and not optimized) on all blocks in the stock configuration as I thought they were
- Cleaned up and re-organized the code - inspiration from @Juzman
- Re-evaluated vm settings @Scott) and network tweaks @Juzman); I don't believe this resulted in any changes (except I'm trialing cache_pressure at 60 vice 20), but thanks for their advice, research, testing, and participation (which is also now credited in the script).
Version 6 (94pks6):
- Added feature: script now writes out a file "pks_script_result" to the /storage/emulated/0 (root of internal storage) directory when executed.
- If the file is present after attempting to run (or after a reboot if you have it in su.d, init.d, or service.d folders) then this indicates the script executed.
- If when you open the file in a text viewer it has a time/date stamp and the phrase "94pks6 successfully executed!", then it ran without errors.
- If when you open the file it says instead "94pks failed." then it threw some error code upon execution... but it was probably minor enough that the changes were applied (or the file wouldn't have been written ).
All the above is at least in theory. It seems to be working that way on my device. Thanks to @Scott for the suggestion!
Version 5 (94pks5):
- Lowered last lmk slot (empty apps) much further - no appreciable loss of available RAM during my testing, less redraws in chrome tabs and reloading of recent apps.
Version 4 (94pks4):
- Fixed aggressive Lowmemorykiller / memory over-commit interaction issue (only last LMK slot now much more aggressive than stock, vm.overcommit_memory reverted to "1" (stock). The interaction with previous settings could cause an issue where no additional apps could be opened (they were immediately killed).
- Very minor tweaks to some vm caching parameters
Version 3 (94pks3):
Corrected swap off command to not throw error flag on execution
Altered tx_queue_len replacement command to skip non-linked file and not flag error on execution
Thanks @Lessaj and @veetoe for helping
Version 2 (94pks2):
1). Increased LMK levels
---- I tested for weeks, we have gobs of RAM, it should really only affect empty apps
2). Turned off swap and de-allocated zram space
---- With 4GB of RAM, do we need zram? I don't think so. I found benchmarks and day-to-day performance to be slightly better without it, plus this is further enabled by increased LMK levels (in theory).
3). Reduced the vm dirty expire / writeback by a factor of 10 (still far more aggressive than stock)
---- No real effect here, just walking back to stock since I see no real effect with these parameters on Pixel 2.
4). Enabled Schedutil governor IO_wait_boost flag for both little and big clusters.
---- Should boost performance / reduce latency during high I/O events, found it to marginally increase some benchmarks and subjective performance feel without affecting battery (YMMV).
What if one doesn't have service.d in magisk?
Sent from my Pixel 2 XL using Tapatalk
I might give this a go in the morning. Add it and reboot in a full charge before I go to work. Using Flash kernel with my 2 XL, but hey, I'm always down for tweaking and tuning. I'll report back.
bryantjopplin said:
What if one doesn't have service.d in magisk?
Click to expand...
Click to collapse
You won't see it in the app. Use a root browser of some kind.
Root Partition/Magisk/.core/service.d
That would be the file path.
It wasn't there, just added it. Picture confirmed it was a folder
Sent from my Pixel 2 XL using Tapatalk
TheGeekyNimrod said:
I might give this a go in the morning. Add it and reboot in a full charge before I go to work. Using Flash kernel with my 2 XL, but hey, I'm always down for tweaking and tuning. I'll report back.
Click to expand...
Click to collapse
Should work fine with custom kernels... I'm just not sure if any of the tweaks might not already be in Flash - I know a couple aren't. Thanks for giving it a try and reporting back.
TheGeekyNimrod said:
You won't see it in the app. Use a root browser of some kind.
Root Partition/Magisk/.core/service.d
That would be the file path.
Click to expand...
Click to collapse
Thanks for helping others out while I was away!
bryantjopplin said:
It wasn't there, just added it. Picture confirmed it was a folder
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
That's truly odd - I've had 3 different devices with Magisk and they always had that folder. Could be that it was hidden to your file explorer of choice, especially since some of the folder names start with, or have "." in them? I dunno. Hopefully adding the folder manually like you did just works.
pkgnex said:
Should work fine with custom kernels... I'm just not sure if any of the tweaks might not already be in Flash - I know a couple aren't. Thanks for giving it a try and reporting back.
Thanks for helping others out while I was away!
That's truly odd - I've had 3 different devices with Magisk and they always had that folder. Could be that it was hidden to your file explorer of choice, especially since some of the folder names start with, or have "." in them? I dunno. Hopefully adding the folder manually like you did just works.
Click to expand...
Click to collapse
Using root explorer since OG Droid. Others are inferior imo. Thanks for checking up.
Sent from my Pixel 2 XL using Tapatalk
I had to show hidden files in Solid Explorer to see that folder! Thanks for the script!
Sent from my Pixel 2 XL using Tapatalk
bryantjopplin said:
Using root explorer since OG Droid. Others are inferior imo. Thanks for checking up.
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
Same one I use!
henderjr said:
I had to show hidden files in Solid Explorer to see that folder! Thanks for the script!
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
You're welcome.
Easy way to tell if the script is working? Or pretty much seeing this here is enough?
henderjr said:
Easy way to tell if the script is working? Or pretty much seeing this here is enough?
Click to expand...
Click to collapse
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
pkgnex said:
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
Click to expand...
Click to collapse
I'm stock 8.1 right now besides Magisk with Adaway.
The script is is in both places though I only remember putting it in one. Wonder if one is a copy of the other.
Anyway I see it in the logs so we should be good. Thanks again!
henderjr said:
I'm stock 8.1 right now besides Magisk with Adaway.
The script is is in both places though I only remember putting it in one. Wonder if one is a copy of the other.
Anyway I see it in the logs so we should be good. Thanks again!
Click to expand...
Click to collapse
One location is probably a sym-link to the other, then. Good to know!
I'm still running 8.0, so at least I now know it works on 8.1 as well.
On 8.1.0....
Seems??? To work. Little snappier
imaverik said:
On 8.1.0....
Seems??? To work. Little snappier
Click to expand...
Click to collapse
Thanks for the feedback! That's my experience as well.
These tunes/mods don't have as much of an effect as they used to, but I think they still offer a little improvement.
Any impact on battery,good or bad?
skinza said:
Any impact on battery,good or bad?
Click to expand...
Click to collapse
Should not affect battery at all, either way.
I guess in theory the faster network settings and io should mean you won't need your screen on as much, but any effect would not be noticeable.
So I've used the script alongside Flash Kernel beta and a few tweaks of my own. Can't really say I've noticed a battery difference as I also use Disable service and others. But I do feel there is a slight increase in response time whether it's touch, transition, fingerprint, etc.
pkgnex said:
Which kernel are you running? If it's stock, the easiest way to tell for sure is to install a kernel editor (EX by FLAR2 is a good one, but there are others if you have to pay for that one, I forget) and see if some of the parameters in the script "took" like low memory killer values, vm parameters, entropy values, read-ahead kb, io-scheduler being noop instead of CFQ, etc. I know Flash uses cfq as the default sceduler, so if you're returning noop, that would indicate the script ran. I'm not sure what the default scheduler is on Despair's Snoke.
One thing - I don't think the folder you have it in is right. I think the path should be (root)/Magisk/.core/service.d NOT (root)/DEV/Magisk/IMG/.core/service.d
Just remembered, another way to see if it ran is to open Magisk manager, go into settings, click "log" and select the "Magisk" tab. You should see a bunch of stuff, but near the bottom you should see:
: ** late_start service mode running
: * Running service.d scripts
service.d: exec [94pks]
Click to expand...
Click to collapse
Followed the above instructions
Ran no problem
I have a rooted moto g6 play and I read that using kernel adiutor to overclock this phone will make it a lot faster. The problem is, I have no idea what to set the settings to. If any of you have a moto g6 play, could you tell me which settings would be best or the settings you have? Thanks
Here's the settings I use. I was actually planning on making a guide that would cover this very subject -- however, I've been inundated with "life". As my friend told me, "Sometimes Life -- Lifes you." Right?
Anyways. This setup I'm about to describe works absolutely perfectly for me... With that said, it *may* not be the best for everyone. I'm not a multi-tasker, and I run an extremely lean operation for maximum power availability. So, if you're an avid multi-takser, you'll probably want to stay away from this. However, if you do one thing at a time and want maximum battery life mixed with moderate speed boost -- you'll love this.
I use Kernel Aduitor primarily because I like the interface better than Ex Kernel Manager. With that in mind, I'll just go down the list using Kernel Auditor's app... I do run Ex-KM as well, but only for 1 particular setting which I'll cover when I get there.
Lets begin!!
Prereq Software: L-Speed by Paget, Kernel Auditor, and ExKernel Manager.
Using Kernel Auditor:
1) --CPU--
a)Max 1401, Min 960.
b)Conservative Governor (w/ 50 down, 3 freq step, 1 ignore nice load, 1 sampling down factor, 66666 for both sampling rates, 95 up threshold)
c)Schedule workloads on awake cpus (ON!)
2) --GPU--
a)Max Freq 650 (If gaming, or graphically intense use -- otherwise I go to 484, and even 400)
b)Min Freq 270
c)Governor (I typically run Simple On Demand for daily use, powersave for battery, and bump up performance and a higher frequency of 650mhz if I need it)
3) --I/O--
a)NOOP Scheduler
b)Not tunable.
c)read ahead -- honestly, I've tried every single setting using different benchmarks, and it appears to make a little difference. I simply use 512kb as my default. Feel free to adjust accordingly if you use your phone in a way that benefits from it.
d)I keep all three settings turned off -- rotational, stats, and add random. IO Stats is on by default I think, by turning it off it will give a very minimal boost in performance. But I'll take every inch I can get out of it... ya know?
e)RQ Affinity is 1 by default, I use 2.
4)LMK
25, 50, 100, 175, 275, 400 (Again, this is purely because I run a lean operation with minimal multitasking. Feel free to adjust to your needs)
5)Virtual Memory (This is a nice performance boosting tuneable screen)
Dirty: 90
DirRat: 50
Expire: 10000
Writeback: 25000
Min Free: 15000kb
oom killing: 1
Overcommit: 100
Swappiness: ZERO!!
VFS Cache: 200
Laptop: ZERO
Extra Free: 10000
And the best thing I've done for my phone, I do believe: ZRAM ----> ZERO! Zram is a waste of resources and sucks life out of your phone with its constant encryption and decryption routine. With 3gb of ram, and a properly tuned LMK --- you'll get a noticeable boost in smooth performance here. I hate Zram!
6) Entropy
I use light settings here 64/192.
--------------------------------------
Now, EX-Kernel Manager... I only use it for one setting. By default, when the GPU is at idle -- it hums along at 400mhz. You can adjust this in ExKM down to a true idle of 270mhz. You'll not sacrifice any performance, but may get a small bump in battery life.
-------------------------------------
L-Speed is one of my favorite apps I've ever used. Tons of useful scripts that really make a difference.
Upon initial setup, just kinda breeze through the opening screens. Don't use one of the preprogram'd tunes. Here's what I use specifically (If its not listed on this list, that means its either disabled or default and thats where I want to keep it. :
Main Tweaks:
Disable Debugging - ON
Panic - OFF
Sleeper Optimize: ON
Flag Tuner: OFF (I used to run ON, but it developed lagginess, and turning it back off appeared to correct this. Feel free to try either for your personal use)
Improved Scrolling: ON
Liquid Smooth UI: ON
Animations: ZERO across the board.
Battery:
Battery Improvement - ON
Doze Optimize - ON
Aggresive Doze - ON
CPU:
Gov Tuner - DISABLED (or else it will cause you to lose your settings in Kernel Auditor)
CPU Optimizer - ON
LNET:
Net Buffers - BIG
RIL Tweaks - ON
TCP Tweaks - ON
Net Speed+ - ON
Wifi Scanning OFF
DNS Optimizer - ON (uses google DNS, or maybe cloudfare now.. but its super smooth)
IO Tweaks:
Tuner - OFF
Boost - ON
Extended Queue - ON
Part Remount - ON
Disable IO stats - ON
RAM:
MAnager - Default (for me, you may need another setup if you multitask)
Don't Keep Activities - ON
Dynamic VM: OFF
Skip the next 4 or 5 options, leave disabled or default.
Heap Optimize: ON
OOM Killer: ON
Dump Tasks: OFF
ZRAM OPTimizer: OFF
Ftrim
DO IT. Then set to run on boost, and schedule it for every 6 hours or so to keep it running effecient and smooth.
Last thing... I go to the developer menu under settings within the operating system, and turn on "Force GPU to run 2d operations".
-------------
I get incredible battery life at these settings. A super snappy phone with minimal lag. And if I need a quick jolt of power, I just crack up the CPU and GPU to max settings.. and I'm good to go!
Enjoy.
Thanks for reading. Sorry so long.
bubbyj said:
Here's the settings I use. I was actually planning on making a guide that would cover this very subject -- however, I've been inundated with "life". As my friend told me, "Sometimes Life -- Lifes you." Right?
Anyways. This setup I'm about to describe works absolutely perfectly for me... With that said, it *may* not be the best for everyone. I'm not a multi-tasker, and I run an extremely lean operation for maximum power availability. So, if you're an avid multi-takser, you'll probably want to stay away from this. However, if you do one thing at a time and want maximum battery life mixed with moderate speed boost -- you'll love this.
I use Kernel Aduitor primarily because I like the interface better than Ex Kernel Manager. With that in mind, I'll just go down the list using Kernel Auditor's app... I do run Ex-KM as well, but only for 1 particular setting which I'll cover when I get there.
Lets begin!!
Prereq Software: L-Speed by Paget, Kernel Auditor, and ExKernel Manager.
Using Kernel Auditor:
1) --CPU--
a)Max 1401, Min 960.
b)Conservative Governor (w/ 50 down, 3 freq step, 1 ignore nice load, 1 sampling down factor, 66666 for both sampling rates, 95 up threshold)
c)Schedule workloads on awake cpus (ON!)
2) --GPU--
a)Max Freq 650 (If gaming, or graphically intense use -- otherwise I go to 484, and even 400)
b)Min Freq 270
c)Governor (I typically run Simple On Demand for daily use, powersave for battery, and bump up performance and a higher frequency of 650mhz if I need it)
3) --I/O--
a)NOOP Scheduler
b)Not tunable.
c)read ahead -- honestly, I've tried every single setting using different benchmarks, and it appears to make a little difference. I simply use 512kb as my default. Feel free to adjust accordingly if you use your phone in a way that benefits from it.
d)I keep all three settings turned off -- rotational, stats, and add random. IO Stats is on by default I think, by turning it off it will give a very minimal boost in performance. But I'll take every inch I can get out of it... ya know?
e)RQ Affinity is 1 by default, I use 2.
4)LMK
25, 50, 100, 175, 275, 400 (Again, this is purely because I run a lean operation with minimal multitasking. Feel free to adjust to your needs)
5)Virtual Memory (This is a nice performance boosting tuneable screen)
Dirty: 90
DirRat: 50
Expire: 10000
Writeback: 25000
Min Free: 15000kb
oom killing: 1
Overcommit: 100
Swappiness: ZERO!!
VFS Cache: 200
Laptop: ZERO
Extra Free: 10000
And the best thing I've done for my phone, I do believe: ZRAM ----> ZERO! Zram is a waste of resources and sucks life out of your phone with its constant encryption and decryption routine. With 3gb of ram, and a properly tuned LMK --- you'll get a noticeable boost in smooth performance here. I hate Zram!
6) Entropy
I use light settings here 64/192.
--------------------------------------
Now, EX-Kernel Manager... I only use it for one setting. By default, when the GPU is at idle -- it hums along at 400mhz. You can adjust this in ExKM down to a true idle of 270mhz. You'll not sacrifice any performance, but may get a small bump in battery life.
-------------------------------------
L-Speed is one of my favorite apps I've ever used. Tons of useful scripts that really make a difference.
Upon initial setup, just kinda breeze through the opening screens. Don't use one of the preprogram'd tunes. Here's what I use specifically (If its not listed on this list, that means its either disabled or default and thats where I want to keep it. :
Main Tweaks:
Disable Debugging - ON
Panic - OFF
Sleeper Optimize: ON
Flag Tuner: OFF (I used to run ON, but it developed lagginess, and turning it back off appeared to correct this. Feel free to try either for your personal use)
Improved Scrolling: ON
Liquid Smooth UI: ON
Animations: ZERO across the board.
Battery:
Battery Improvement - ON
Doze Optimize - ON
Aggresive Doze - ON
CPU:
Gov Tuner - DISABLED (or else it will cause you to lose your settings in Kernel Auditor)
CPU Optimizer - ON
LNET:
Net Buffers - BIG
RIL Tweaks - ON
TCP Tweaks - ON
Net Speed+ - ON
Wifi Scanning OFF
DNS Optimizer - ON (uses google DNS, or maybe cloudfare now.. but its super smooth)
IO Tweaks:
Tuner - OFF
Boost - ON
Extended Queue - ON
Part Remount - ON
Disable IO stats - ON
RAM:
MAnager - Default (for me, you may need another setup if you multitask)
Don't Keep Activities - ON
Dynamic VM: OFF
Skip the next 4 or 5 options, leave disabled or default.
Heap Optimize: ON
OOM Killer: ON
Dump Tasks: OFF
ZRAM OPTimizer: OFF
Ftrim
DO IT. Then set to run on boost, and schedule it for every 6 hours or so to keep it running effecient and smooth.
Last thing... I go to the developer menu under settings within the operating system, and turn on "Force GPU to run 2d operations".
-------------
I get incredible battery life at these settings. A super snappy phone with minimal lag. And if I need a quick jolt of power, I just crack up the CPU and GPU to max settings.. and I'm good to go!
Enjoy.
Thanks for reading. Sorry so long.
Click to expand...
Click to collapse
Thank you for taking your time to write that out! I really appreciate the help! Once again, thank you!
@buddyj excellent piece of information there! Keep up the good work!
Sent from my Moto G6 Plus using Tapatalk