Develop Bugs

[REF][SCRIPTS] Android Optimization Tips - i9000 (UPDATED 1/10/12)

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

Battery/RAM/Speed Optimization Tips for Android Phones

I AM NOT RESPONSIBLE FOR ANY NEGATIVE IMPACTS OR CONSEQUENCES ON YOUR PHONE IF YOU SO CHOOSE TO USE THESE TIPS.
I've created a couple threads on the ZTE U950 and LG G2, and one problem is the battery life. The battery cannot come out of these devices and thus we cannot combat this with a bulkier, beefier replacement for heavy usage. Charging constantly is something I try to avoid, so these are a few simple tips that can help optimize your battery life (and that APPLY to ANY PHONE):
TIPS
BATTERY
1a) Buy and download CPU Sleeper (root required). There are two versions, one for dual-cores, and the other for quad-cores. Essentially, when a phone is "sleeping", it is actually still running all its cores, helping drain battery faster. This app turns off all but one core when it is "sleeping" so that your battery is not drained nearly as fast.
BATTERY
1b) To take this step a bit further you can download a free app called Multicore CPU Control. In this app you can control your other cores. You can setup profiles to turn on or off cores, and setup each core with different governors. On my LG G2, I setup a profile to only have one core running at 960MHz (2.2GHz originally) after using the steps from below. If you plan to only run one core, then you do not need to buy CPU Sleeper.
NOTES ON 1b: Multicore CPU Control is the name when installed, it is called CPU Performance Control Free on the Google Play Store (either name will work on Google Play). The program needs to be turned on after each boot. When first setting up a profile save it and edit it in order to manipulate the other cores available. The app does not always apply a profile even if it has already been selected. To turn on a profile, click on the profile desired and go to the CPU Monitor tab to check if it has been applied. If not, repeat the process until it does (it usually takes me about 3 times at most).
BATTERY/RAM
2) Download Greenify (root required), a great free app! Sometimes a user does not have a ROM with a kill all button, so pesky apps just stay on without consent. This app allows a user to turn off any app that may want to run in your background, and even shows you which apps are currently running. Apps like Facebook, Talkatone, etc. can all be stopped even if your "task killer" supposedly took care of them.
BATTERY
3a) Wakelock Detector-Save Battery is a free app that checks for apps that continue to work while the phone is "asleep". While Greenify will display the most troublesome apps, this app will help discover any other apps that are running without consent.
BATTERY/RAM
3b) If Greenify does not show the apps discovered in Wakelock Detector-Save Battery, then download Disable Services (root required). This free app allows a user to disable an entire service, or just parts of a service that are bothersome. Click on a service/app to find out what other services accompany it. Read the accompanying services and discern whether or not the service is needed. A good place to start in this app is to check any service/app that has a blue number next to it.
EXAMPLE 3b: I use the Outlook app a lot, but sometimes it gets annoying with updates for insignificant email. I can open Wakelock Detector-Save Battery and click the Outlook app. I turn off "AppWidgetUpdateService" to disable Outlook email updates. Not all services have obvious names, so be careful on system apps if performing trial-and-error.
BATTERY/RAM
3) Buy and download BetterBatteryStats (CPU Spy Reborn/Plus is FREE and only shows CPU states). This app tells me what CPU States are used the most often and is what I download first before my next step. A user can also determine battery-draining apps and turn those off. If turning off those apps is not possible through Settings>Apps just Greenify them!
BATTERY
4) Underclocking. This is an amazing step for saving battery! If you have ran BetterBatteryStats for at least a day, this will come in handy and is highly recommended. You can use numerous programs like SetCPU or Voltage Control to set the clock of the CPU. The key is to find a point that will still be responsive, yet lower than the maximum.
EXAMPLE 4: For this example I will be using my ZTE U950 and Voltage Control. According to BetterBatteryStats, my most used clock was at 1.2GHz and 860MHz. I left my minimum clock at the lowest possible setting, while my maximum clock I changed to 860MHz. I ran this for a few days and saw a noticeable difference in battery life. Another important part to this if choosing the right I/O Scheduler and CPU Governor. I found the default I/O Schedule ("cfq") to perform the best, despite "noop" being good for sluggish memory. "Powersave" is a good Governor at stock CPU speeds, but it will not get a user the savings of power that a step like this will. I tested with this Governor with this step and got horrible reaction times and would often need to restart the phone. The best results I have are with "ondemand" and "interactive". I am currently using "interactive" with a maximum clock of 475MHz! I arrived at that number after checking my BetterBatteryStats while running at 860MHz and found that to be the next most used clock. Now my battery is lasting about twice as long as it normally did! My phone's response time is a bit slower at this low clock speed, but that can combated...
BATTERY/RAM/SPEED
4b) (IF YOU HAVE INIT.D SKIP TO STEP 4c) My LG G2 is underclocked to 960MHz, as noted in step 1b. I am saving quite a bit of battery, but the UI response can lag a lot at times. The use of boot scripts can be helpful to compensate for this. However, my LG G2 does not have init.d support. There are numerous threads that explain how to get init.d support for a lacking Android phone. The simplest method is to install an app from Google Play. I use one called Init.d-Installer just because it forces the phone to reboot once it has installed; others do not seem to do anything to inform a user if they have received init.d support
BATTERY/RAM/SPEED
4c) Download a script called V6 SuperCharger. The thread may seem daunting, but it is fairly easy to install. Download the newest PDF and change it to TXT. Ensure you have init.d support, BusyBox installed (also in the thread if needed), and SuperSU. Run the script in a free app like SManager with SU permissions and follow the instructions. This script gives the ability to enhance speed and power. I install this in order to ensure my UI stays responsive, and LG G2 runs almost at stock speeds (alongside all my other enhancements)!
BATTERY
5) Undervolting (root required/custom kernel required). This is also a great way to save battery. I decrease the voltage in steps of 25 and test from there. If I find no quirks, I leave it. If I find sluggishness or have random phone reboots, I increase by increments of 25 (or 12.5) until I find something stable.
Most phones will not allow undervolting without a custom kernel. To see whether a phone can undervolt or not download, Sytem Tuner. There is a free and paid (Pro) version of this app, but the free one should be sufficient for what we want to do. After installing, open the app and click on the Voltage settings tile on the left-lower side of the screen. All the phone's CPU MHz steps and the amount of voltage applied to each step can be viewed. At the bottom of the screen are buttons to increase or decrease voltage in 12.5 increments (which will apply to all steps). If the -12.5 button is clicked and the values of all the steps drop, then a phone can undervolt. Additionally, System Tuner allows a phone to manually apply undervolting to each step if wanted.
To test undervolting, just push the decrease button until the phone freezes up. There is no harm to your phone or CPU as neither are being overpowered (just the opposite), and a reboot after freezing will reset the phone to default voltage settings. A - 75MHz drop is normal for a phone while remaining stable; and in a lot of cases -100MHz is achievable.
NOTE: Tips #4 & #5 also can be applied to GPUs.
NOTE 2: One thing that should be mentioned is to be careful about putting more than one app that controls CPU clocks. They can read differently and trump the other when used in combination. Instead, install and use one at a time to get more accurate readings. The same should apply to undervolting apps.
BATTERY/RAM
6) A user can change the Dalvik cache a bit to see if that helps optimize RAM, and possibly battery. I did quite a few tests for these to see how they performed. I think the only reason I noticed any changes immediately is because of how far underclocked my CPU is. Anyways, the best results I was able to get with my ZTE U950 was as follows:
124m - dalvik.vm.heapsize (2nd one, not 1st)
8m - dalvik.vm.heapstartsize
For other phones, these are the items to trial-and-error with:
davilk.vm.heapsize (may be more than one at different values)
davilk.vm.heapstartsize
davilk.vm.heapgrowthlimit (may be more than one at different values)
A user can change these settings by downloading an app like Build.Prop from Google Play. I did notice my battery seemed to drain slower with these changed. The RAM was the best optimized for the self-made tests I performed and was nearly the best in all the tests I had ran. A user may or may not notice any differences unless they multitask a lot.
BATTERY/RAM/SPEED
7) All other well-known methods apply as well:
A. Battery Saver apps/settings
B. Battery Calibration apps
C. Refrain from the use of widgets
D. Automatic Brightness apps/settings
E. Small Screen Times before Screen Sleep
F. Turn Off WiFi and/or Data when not needed
G. Task Killers apps/settings

[PnP&Thermals tweak] Custom profiles for battery saving and/or better performance-v24

Addon was originally only available on Venom HUB but i decided to release it for everyone to use.Here is copy paste of description and changelogs from the HUB.I will update thread as i update it on HUB.
Also big thanks to @hamdir for testing my performance profile on various games, he will also post later hes review, pictures and comparisons to stock.
This addon is designed to save some extra battery, and reduce heat.Magic is done in 2 files:
1:Thermal-engine is tweaked in order to provide much better sustained performance and cooler phone, without big impact on performance.
2np file is another key component, its HTCs CPU/GPU/EMMC/MODEM and many more control engine.Here many tweaks where done, but gonna quickly list some of the important ones:
-Per app control, automatically suspends 2 BIG cores, and runs on 2 low power ones, it also limits the GPU speed to lowest.This will do only for some most commonly used apps, like Sense Prism, Nova launcher, Apex, other HTC apps, various chat programs(hangouts, facebook, messanger, whatsap etc), YouTube and some more.. as those apps dont require a lot power.
-Screen off is set to 2 low power cores for nice standby times
-Power saver is tweaked to actually save some power and not just lower screen brightness
-Extreme powersaver is also tweaked down to save even more power
-Input boost frequencies are also lowered (CPU ramps up moment you touch screen)
-And alot of other minor tweakups..
Also its recommended not to change anything CPU/GPU related in any other apps, like EX and just let this files do the job for you.
If for some reason you dont like this mod or have any problems with it, installer includes revert to stock option
Click to expand...
Click to collapse
Read more info in changelogs below.
List of battery optimised apps (feel free to post your suggestions):
Code:
com.ninefolders.hd3
com.applisto.appcloner
com.livae.apphunt.app
com.fillobotto.mp3tagger
org.polaric.cluttr
com.rgiskard.fairnote
com.glextor.appmanager.free
com.catchingnow.undo
kik.android
de.onyxbits.listmyapps
org.zloy.android.downloader
com.slaughter.look.of.disapproval
gaurav.lookup
cn.wq.myandroidtoolspro
com.embermitre.pixolor.app
de.toastcode.screener
de.munichsdorfer.screenittrial
com.glitch.stitchandshare
com.stumbleupon.android.app
org.de_studio.recentappswitcher.pro
com.happening.studios.swipeforfacebookfree
com.laurencedawson.reddit_sync
com.fifthelement.trimmer
com.camel.corp.universalcopy
com.google.android.apps.inbox
com.riversoft.android.mysword
com.taxis99
com.tbig.playerpro
com.tomtom.gplay.navapp
com.xda.labs.play
com.google.android.apps.translate
com.safeincloud
com.mobisystems.msdict.embedded.wireless.collins.p ortuguese.full
com.mobisystems.msdict.embedded.wireless.oxford.es sentialportuguese
com.accuweather.paid.android
com.mobilesrepublic.appy
com.pandora.android
com.slingmedia.slingPlayer
com.bumble.app
com.tinder
com.klinker.android.twitter_l
com.nam.fbwrapper.pro
com.timehop
jp.naver.line.android
com.linkbubble.playstore
kr.co.vcnc.android.couple
com.joshua.jptt
com.noinnion.android.greader.reader
com.netbiscuits.kicker
com.redictandcgdstudios.projectslenderonline
com.teotlstudios.slenderrisingfree
com.dvloper.slendermanriseagainfree
com.RexetStudio.SlenderTheRoad
air.com.sticksports.sticktennis
com.sticksports.sticktennistour
com.bauermedia.tvmovie
de.wetteronline.wetterapppro
com.redictstudios.projectslender
se.feomedia.quizkampen.de.premium
com.quoord.tapatalkHD
com.droid27.transparentclockweather
com.speedsoftware.rootexplorer
pl.solidexplorer2
com.appseleration.android.selfcare
com.google.android.apps.chromecast.app
rpkandrodev.yaata
com.andrewshu.android.reddit
com.xodo.pdf.reader
com.microsoft.office.word
com.microsoft.office.excel
com.kmobile.cb
com.nianticlabs.pokemongo
com.google.android.apps.maps
com.htc.laputa
com.papago
com.mapbar.android.mapbarmap
com.autonavi.cmccmap
com.baidu.BaiduMap
com.pdager
com.kingwaytek.naviking
com.htc.lockscreen
com.htc.fingerprint
com.xda.labs
org.mozilla.firefox
org.mozilla.firefox_beta
com.emoji.keyboard.touchpal.oem
com.nitrodesk.honey.nitroid
com.android.calculator2
com.estrongs.android.pop
com.tbig.playerpro
org.telegram.messenger
com.instagram.android
org.wordpress.android
com.touchtype.swiftkey.beta
com.gsamlabs.bbm
com.htc.android.worldclock
com.quoord.tapatalkpro.activity
com.anddoes.launcher
com.google.android.gms
android.uid.systemui
com.android.systemui
com.chrome.beta
com.android.chrome
com.chrome.dev
com.teslacoilsw.launcher
com.spotify.music
com.quoord.tapatalkxdapre.activity
com.google.android.apps.plus
com.twitter.android
com.htc.AutoMotive
com.google.android.talk
com.viber.voip
com.ninegag.android.app
com.android.settings
com.devhd.feedly
com.htc.weather
com.google.android.phone
com.htc.sense.mms
com.htc.contacts
com.htc.htcdialer
com.htc.music
com.maxmpz.audioplayer
com.google.android.apps.photos
com.htc.launcher
com.htc.sense.news
com.whatsapp
com.facebook.katana
com.facebook.orca
com.m0narx.hub
com.ice.tweaks
com.m0narx.tweaks
com.google.android.youtube
com.google.android.videos
Compatibility:
All 1,8x, 1.9x and 2.x based roms bases and kernels(even stock roms/kernel's).
Not compatible with 1.5 or below bases (will cause random crashes), use Version v8 for older 1.5x and 1.2x bases.
Download:
Version v24
Download link flashable ZIP - AFH
Older versions:
Version v23
Download link flashable ZIP - AFH
Version v22
Download link flashable ZIP - AFH
Download:
Version v21
Download link flashable ZIP - AFH
Version v19
Download link flashable ZIP - AFH
Version v18
Download link flashable ZIP - AFH
Version v17
Download link flashable ZIP - AFH
Version v16
Download link flashable ZIP - AFH
Version v15
Download link flashable ZIP - AFH
Version v14
Download link flashable ZIP - AFH
Version v13
Download link flashable ZIP - AFH
Version v12
Download link flashable ZIP - AFH
Version v11
Download link flashable ZIP - AFH
Version v10
Download link flashable ZIP - AFH
Version v9 TEST
Download link flashable ZIP - AFH
Version v8
Download link flashable ZIP - AFH
Version v8 for older 1.5x and 1.2x bases
Download link flashable ZIP - AFH
Changelog:
Code:
24.04.2017
v24:Fixed remove 50 -> 60 fps boost on touch on performance profile(60fps locked now)
- MaxPowerSaving profile optimizations to get even more battery life.
27.03.2017
v23:Added more user requested apps(30) for battery optimised profiles
- Attempt to smoothen Facebook app scrolling (App still lags while loading items on any phone)
- Increased touch input boost speed for MaxPowerSaving profile(smoother scrolling)
16.01.2017
v22:Viper Magisk compatible
- Merged with 2.41 base changes
- Added a lot more apps for battery optimised profiles
- Added new MaxPowerSaving profile:
Limits CPU to 1.3/1.78GHz(LC/BC), GPU 510MHz
Launching apps bypasses above limit for fast app starting/switching
Still uses balanced mode per app profiles which saves even more power
- Cleaned installer from unnecessary files (smaller zip size)
9.12.2016
v21:Lowered input boost, touch boost, long duration touch boost, app launch and per app frequencies for even more battery savings(N is still very smooth)
-Cleaning of code and some other fine tuning
24.11.2016
v20:Merged with Android 7.0.0 changes
-Also backwards compatible with 1.5x + bases
26.09.2016
v19:Fixed CPU doesnt drop to lowest speed for some users/kernels
- Merged v18 balanced changes into performance profile
22.09.2016
v18:(Balanced changes only)
- Adjusted CPU scheduler load distributions and frequencies in order to fix some stutters,
but also to save power while phone is idle with screen ON (drops to lower frequencies faster)
- Fixed weird HTC bug where task migration gets stuck in loop and cause phone to heat up for no reason
- (thermal file)Make it a bit cooler on higher loads
- Minor fine tuning here and there..
29.08.2016
v17:Prevent cores going offline if running Android auto (fixes lag on screen off)
- (Balanced)Tweaked 15+ various governor and boost settings for even more power savings
- (Balanced)Added more appps for CPU limiting profiles
- Allow 4 threads for oat proces if PlayStore in focus(faster app install)
23.08.2016
v16:Merged latest HTCs changes realted to PokemonGo thermals
- Removed 50 -> 60 fps boost on touch on performance profile(60fps locked now)
- Forced 60 fps for YouTube and Google videos on balanced profile
- Tweaked thermal file on balanced profile for better performance
07.08.2016
v15:Balanced and Performance profile update
- Fine tuned values
- Big cores go offline during screen off for Performance profile
- Tweaked low memory killer values on both profiles,
prevents often app reloading, which is waste of time and battery.
04.08.2016
v14:Balanced and Performance profile update
- Implemented dynamic swappiness
- Default swappiness reduced from 60 to 30 (less writes to nand)
- During app launch or touching screen event swappiness is reduced to 0
- During screen off swappiness is set to default 60 so it can do its job when we are not using phone
- Increased dirty_ratio to reduce even more writing to nand
- Overall goal is to reduce I/O on NAND while using phone and in that way improve performance,
but also improve battery by better utilizing the 4gb RAM that this device has.
- Added more apps for CPU limiting profiles(balanced only)
v13:
-Merged with changes from 1.9x base
(Mostly fine tuning battery saving for various video chat programs)
v12:Balanced profile changes
- Added more commonly used apps for lower power CPU profiles
- More fine tuning
v11:
- Fine tuned balanced profile to prefer a bit more battery life
- Cleaned up aroma installer (wont create unnecessary Venom folders for non-Venom users)
v10:Balanced profile rebuild
- Merged and fine tuned/adjusted thermal configuration from performance profile
- Should improve responsiveness and fix stuttering on some apps that happend before
- changed around 100+ lines of code, lazy to write full changelog :p
v9:TEST balanced profile update
- Big cores will now go fully offline during screen off and while in Extreme powersaver
- Lowered screen refresh rate while in Extreme powersaver(even more saving)
- Max GPU speed limited to 214MHZ while in Extreme powersaver
- Max GPU speed limited to 510MHZ while in powersaver
- Reduced app launch boost MIN frequencies speeds to 1.3gz for all cores.
v8: complete rebuild of performance profile
- Added extra 560mhz frequency step between 630 and 510 for GPU throttling
- Added 5 additional throttling steps for each CPU cluster per temperature
- Prevent big cores dropping to 1.3ghz too soon which drops FPS in games.
- Prevent killing one big CPU core too soon, instead 2 will run at half migration performance.
- Everything fine tuned and balanced, 10+ FPS boost in most games compared to stock
v7
- 1.8x base compatibility update
v6
-Removed battery saving profile as balanced does such good job, both smoothness and performance! :)
v5
-Many changes to balanced profile
-Lowered app launch Max CPU speed locking to more reasonable levels(Still ramps up to max if load demands)
-Reduced input boost duration a bit
-Governor will now drop CPU to lower speeds faster
-Added more apps to lower CPU speed profiles.
v4
-Aroma installer fixes
-BatterySaving profile fine tuning
v3:
-2 new more options
*MaxPerfomance
*BatterySaving
-Tweaked is now called Balanced
v2:
-fixed YouTube 2k+ videos lag
This is example of battery life i get with Balanced profile
{
"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"
}
XDA:DevDB Information
PnP&Thermals tweak, Tool/Utility for the HTC 10
Contributors
ivicask, hamdir
Version Information
Status: Stable
Current Stable Version: v24
Stable Release Date: 2016-06-23
Current Beta Version: v9
Created 2016-07-06
Last Updated 2017-04-24

Performance Profile
I've worked with @ivicask on optimizing gaming performance for the 1.80 base via the performance profile for this mod, in this post i will explain the gaming problem on stock HTC 10 and how this mod/performance profile solves it
by default HTC aggressively cripples the Snapdragon 820, not for the sake of thermals but for the sake of extending battery life, what happens is the following:
Stock CPU behavior on HTC ten (up to 1.80 base):
Starting with 33c battery temp CPU tasks will gradually migrate out of the big cluster, around 38c one of the two big Kryo cores (which enjoy higher clocks and bigger hardware cache) will be completely disabled, HTC smartly hides it in task migration rather than physically shutting down a big core
This means in CPU intensives games like Dead Effect 2 you will notice a sharp drop in performance/smoothness once the fourth core is killed, the game will drop from the 60fps range to 30fps, this behavior is noticeable in many games, if you are on complete stock you can only game at the full s820 speed if you are starting from a cool idle battery temp like 30c but then in about 5 minutes things will go downhill, considering that the HTC 10 idle state in average use is around 35c anyway you can see how most people probably start gaming on the 10 within the crippled state
Previously the only way to fix was to flash EX kernel with CPU migration hacked and already set by default to 60% limit, meaning EX kernel will refuse to let HTC 10 migrate tasks out of the fourth core under 40%, this is a good solution but you are forced to use EX kernel and not the stock kernel plus wait for the kernel source so that EX is updated whenever an OTA is rolled out, this mod will allow you to fix gaming on HTC 10 without touching the kernel plus it's thermally safe as its not a hack and will still gradually slow down the 10 to cool down, but it does so in a sane way
The performance profile in this mod was thoughtfully optimized by profiling the CPU usage in Dead Effect 2 (currently one of the heaviest games on the playstore) from 30c up to 45c, giving you enough time to actually enjoy this game at its full speed up to 30 minutes
The following tests will show you how the HTC 10 behaves in gaming when warm vs the performance profile, profiled using @ivicask tools and game benched in short sessions, the exact same level played from the same starting point to the same end at the same length of time, this level called "return to space gardens" is one of the heaviest sections in Dead Effect 2, at the end of this test you can see how performance drops to the ground because it meets a very dense and tough section in the game.
Stock kernel / PNP / thermals, Dead Effect 2 at 39c
The fourth big core is completely killed, GPU goes to 510mhz, small cluster drops to 1.3ghz, big cluster drops to 1.5ghz
As you can see on pure stock 1.80 base by 39c the games loses one of the big s820 cores and performance drops from 45fps range in this level to 30fps (which happens way too fast) also as seen in the yellow graph how performance stability is terrible, after 40c it will get even worse
here are the results from the same level using the performance profile of this mod
Performance Profile, Dead Effect 2 at 34c to 38c
full tasks are still running on all cores, GPU at 624mhz, small cluster still at 1.5ghz, big cluster drops to 1.5ghz
Performance Profile, Dead Effect 2 at 39c to 41c
both big cores drops to 80% task migration, GPU drops to 560mhz, small cluster still at 1.5ghz, big cluster still at 1.5ghz
Performance Profile, Dead Effect 2 at 42c to 43c
one big core sticks to 80% task migration the other big core drops further to 60%, GPU drops to 510mhz, small cluster still at 1.5ghz, big cluster still at 1.5ghz
Once the device gets warmer after 43c CPU migration will drop to 60% on both big cores with further reduction in GPU speed etc, but at this stage the HTC 10 will no longer heat up as fast and as you can see up to this point it was maintaining almost the same performance in this game; while keeping fairly high GPU clocks too; this is a much more subtle well thought performance degradation than HTC's stock blind brute crippling of the s820 which happens way too fast on low temps
This profile is so good actually HTC should probably copy it and imitate how it deals with default CPU migration, otherwise why are we buying an s820?

ivicask said:
Addon was originally only available on Venom HUB but i decided to release it for everyone to use.Here is copy paste of description and changelogs from the HUB.I will update thread as i update it on HUB.
Also big thanks to @hamdir for testing my performance profile on various games, he will also post later hes review, pictures and comparisons to stock.
Click to expand...
Click to collapse
@ivicask
does it work differently from butterfly v11?
or say does it conflict with butterflyv11 if you have already loaded that profile and flash this zip?
thanks for another tweak made possible for Perfume devices

SacredDeviL666 said:
does it work differently from butterfly v11?
Click to expand...
Click to collapse
Completely different, it uses HTCs native engines to control everything, u can basically flash this on stock un-rooted phone
And doesn't require custom kernel, it should work immediately as new bases come out etc..

ivicask said:
Completely different, it uses HTCs native engines to control everything, u can basically flash this on stock un-rooted phone
And doesn't require custom kernel, it should work immediately as new bases come out etc..
Click to expand...
Click to collapse
aah okay cool...does it conflict if i have already enabled butterflyv11 which disables pnq or its safe to flash while using that script

SacredDeviL666 said:
aah okay cool...does it conflict if i have already enabled butterflyv11 which disables pnq or its safe to flash while using that script
Click to expand...
Click to collapse
Half of this mod runs in PnP, if you disable it, your making this mod almost pointless.
Also, as i stated, this mod runs best standalone, its best not to use any other mods, or apps which change anything CPU /GPU related.
You can still flash EX kernel for example, i just dont recommend messing with any CPU/GPU related settings in it.

ivicask said:
Half of this mod runs in PnP, if you disable it, your making this mod almost pointless.
Also, as i stated, this mod runs best standalone, its best not to use any other mods, or apps which change anything CPU /GPU related.
You can still flash EX kernel for example, i just dont recommend messing with any CPU/GPU related settings in it.
Click to expand...
Click to collapse
cool so this would conflict as butterflyv11 disables the pnp
would try this and see :highfive:

hey
great to see you released this for all on xda!
I have a question. since you wrote on the ex kernel thread that pnp config file is encrypted how come you can edit it?
or can you englighten me how i can just disable all Input and touch boosts from pnpmgr while keeping pnpmgr?
i think that would be the best for my script but i wasn´t able to do so.
i found no other way to stop the touchboost other than disabling pnpmgr completely.
maybe we can integrate my interactive values with your mod? if you are okay with this of course!
thanks

Freak07 said:
hey
great to see you released this for all on xda!
I have a question. since you wrote on the ex kernel thread that pnp config file is encrypted how come you can edit it?
or can you englighten me how i can just disable all Input and touch boosts from pnpmgr while keeping pnpmgr?
i think that would be the best for my script but i wasn´t able to do so.
i found no other way to stop the touchboost other than disabling pnpmgr completely.
maybe we can integrate my interactive values with your mod? if you are okay with this of course!
thanks
Click to expand...
Click to collapse
I cant give you much details on how i edit them, theres reason HTC encrypted them, if we spill it out, HTC would change encryption and everything very soon i suspect, so hope you understand why i wont share that part.
I can disable input boost for you, but im still not sure how your mod works along with PnP, as PnP constantly changes values dynamically, if you chmod values, than PnP constantly tries to change freqs and fails(may cause some problems).
What i can also do, is incorporate your changes directly into my mod, and make "ghostpeper" profile which would work directly in PnP, and people can choose and test which one works better for them and their daily usage.
EDIT:You could simple disable input boost by echoing 0(maybe chmod remove write permission after that so it cant change it) to
/sys/power/pnpmgr/touch_boost
/sys/power/pnpmgr/long_duration_touch_boost

ivicask said:
I cant give you much details on how i edit them, theres reason HTC encrypted them, if we spill it out, HTC would change encryption and everything very soon i suspect, so hope you understand why i wont share that part.
I can disable input boost for you, but im still not sure how your mod works along with PnP, as PnP constantly changes values dynamically, if you chmod values, than PnP constantly tries to change freqs and fails(may cause some problems).
What i can also do, is incorporate your changes directly into my mod, and make "ghostpeper" profile which would work directly in PnP, and people can choose and test which one works better for them and their daily usage.
EDIT:You could simple disable input boost by echoing 0(maybe chmod remove write permission after that so it cant change it) to
/sys/power/pnpmgr/touch_boost
/sys/power/pnpmgr/long_duration_touch_boost
Click to expand...
Click to collapse
yep i totally understand this. it would be however great if you could disable Input boost for me directly in the pnp binary.
i already tried to edit the files you mentioned in sys/power/pnpmgr. when i did this I got heavy lags. really heavy. i think something is conflicting there.
yeah the chmod trick worked before base 1.80. i would simply chmod the min freqs for big and Little Cluster and touchboost from pnpmgr disappeared magically. this trick is no longer working with the new base. that´s why i was forced to disable pnpmgr.
if you want to you can incorporate the Butterfly values for the interactive governor in your mod. I think Butterfly works far better on our 10, that´s why i just updated Butterfly for base 1.80.
does pnpmgr also edit the values for the interactive gov dynamically?
if you could make a pnpmgr config where touch/Input boost, Setting min/max freqs is disabled i´d be quite happy.
---------- Post added at 11:17 AM ---------- Previous post was at 11:10 AM ----------
SacredDeviL666 said:
cool so this would conflict as butterflyv11 disables the pnp
would try this and see :highfive:
Click to expand...
Click to collapse
you may also just edit my script and comment out with a # or delete the line "stop pnpmgr" then the pnpmgr conflicting part will at least be removed.

Noice. Thanks for sharing

Freak07 said:
yep i totally understand this. it would be however great if you could disable Input boost for me directly in the pnp binary.
i already tried to edit the files you mentioned in sys/power/pnpmgr. when i did this I got heavy lags. really heavy. i think something is conflicting there.
yeah the chmod trick worked before base 1.80. i would simply chmod the min freqs for big and Little Cluster and touchboost from pnpmgr disappeared magically. this trick is no longer working with the new base. that´s why i was forced to disable pnpmgr.
if you want to you can incorporate the Butterfly values for the interactive governor in your mod. I think Butterfly works far better on our 10, that´s why i just updated Butterfly for base 1.80.
does pnpmgr also edit the values for the interactive gov dynamically?
if you could make a pnpmgr config where touch/Input boost, Setting min/max freqs is disabled i´d be quite happy.
---------- Post added at 11:17 AM ---------- Previous post was at 11:10 AM ----------
you may also just edit my script and comment out with a # or delete the line "stop pnpmgr" then the pnpmgr conflicting part will at least be removed.
Click to expand...
Click to collapse
PnP controls everything u mentioned, all your butterfly/ghost scripts has, and about 10x times even more
I checked your script, you just echo to disable input boost, try chmod it after you disable it with denial permission so it cant be changed..
Should work, if not i can mode PnP for you, but above would be better solution for you..

Maybe others might ask too, sometimes I'm using it too for a systemless mod: do you plan to add it in as a systemless mod, if it is possible?

tbalden said:
Maybe others might ask too, sometimes I'm using it too for a systemless mod: do you plan to add it in as a systemless mod, if it is possible?
Click to expand...
Click to collapse
There is no need for that, it wont affect android pay or similar, why exactly you ask?

ivicask said:
There is no need for that, it wont affect android pay or similar, why exactly you ask?
Click to expand...
Click to collapse
well, just related to OTAs, but that might be unimportant as you can flash back to original files, or restore no-RW mounted system image backups.
Or am i lagging behind, it's working to have a RW mounted system and do OTA updates? I don't follow that part much, my bad

tbalden said:
well, just related to OTAs, but that might be unimportant as you can flash back to original files, or restore no-RW mounted system image backups.
Or am i lagging behind, it's working to have a RW mounted system and do OTA updates? I don't follow that part much, my bad
Click to expand...
Click to collapse
Its so much easier just to restore original image, i think wont do it systemless, as they are key system parts, dont want some weird things to happen..

ivicask said:
Its so much easier just to restore original image, i think wont do it systemless, as they are key system parts, dont want some weird things to happen..
Click to expand...
Click to collapse
OK.
I'm testing balanced option at the moment.
Also, i know I'm off topic, but in the end what's the recipe: what does and what doesn't affect androidPay. (I'm lagging behind again in this topic, just avoid modifying system partition in my kernel as it seemed to affect it at that time... as i don't use androidPay I didn't follow what exactly makes it unworking).

ivicask said:
PnP controls everything u mentioned, all your butterfly/ghost scripts has, and about 10x times even more
I checked your script, you just echo to disable input boost, try chmod it after you disable it with denial permission so it cant be changed..
Should work, if not i can mode PnP for you, but above would be better solution for you..
Click to expand...
Click to collapse
Thanks I will try this and come back at you

tbalden said:
OK.
I'm testing balanced option at the moment.
Also, i know I'm off topic, but in the end what's the recipe: what does and what doesn't affect androidPay. (I'm lagging behind again in this topic, just avoid modifying system partition in my kernel as it seemed to affect it at that time... as i don't use androidPay I didn't follow what exactly makes it unworking).
Click to expand...
Click to collapse
It checks alot of things, and its constantly updated, its simple must be done for security reasons..

Okay so I tried it with 444 permissions and it still lags. Should I try 000?
Would be great if you could make me a file with touchboost disabled and frequency changing disabled.

what's is smart cpu efficiency explain in details please?

recently miui add a new feature called smart cpu efficiency but I wanna know more about this feature and how it's works and after are the pro and cons in full details please and is it really a good feature please answer as soon as possible....

Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...

its just the fancy name

Zola III said:
Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...
Click to expand...
Click to collapse
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q

BG. said:
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q
Click to expand...
Click to collapse
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.

So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.

Zola III said:
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.
Click to expand...
Click to collapse
thanks for helping out

Well I hope you are satisfied with explanation.
See you later alligator.

Zola III said:
So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.
Click to expand...
Click to collapse
could you please give me few simple examples regarding this issue so I can post and point out on the form

BG. said:
could you please give me few simple examples regarding this issue so I can post and point out on the form
Click to expand...
Click to collapse
Their is no simpler explanation.
The numbers I presented are extrapolated from numerous analysis published as scientific works all available floating around the net.
A) hot plug is relatively slow (not because of it self but) as awakening from deep retention states on all ARM CPU's up to date takes time (to init & test/flush queues and RAM subsystem integrity)
B) HPM scheduler is designed to place the work on first available ready CPU core that best meets the demand (dependant on given idle/packing parameters assigned to HPM)
C) hotplug will never be able to awake any core in deep retention state on time for a HPM decision timing
D) all transitions from one to another core (no matter which one) is costly.
So in short what could & needs to be done;
A) Ensure that at least one CPU is always active per cluster
B) Ensure that HPM is properly configured & running as intended (migration load, packing & idle conditions)
C) Minimise transition times (by providing optimal setup) and minimise their number.
How to achieve this?
Well;
A) properly configure hotplug disabling it to power down control core's that are needed to stay online all the time (this excludes the device sleep), example (of a 2+2 always on configuration on a octa core dual cluster SoC [S652]);
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
B) there are two approaches with HPM super packing (Sony) & absolute idle load (Xiaomi on MiUI 8) both tied to min CPU's active and all CPU's active how ever the both approaches are wrong, high enough init with limited packaging & giving idling cores advantage is really the best way to go along with providing ideal conditions of available core's (which is 2+2)
C) this two already implied hire together make the ideal possible setup for a task placement & minimising the up/down migration times plus if set as shown (when possible) ensures the usage of all L2 cache available along with exclusive access, it also provides faster awakening of other core's when they are needed from deep retention state. The power drive cost is the same as the performance gain (5~6%) so for given job the power consumption is exactly the same while other positive effects remain. Additionally it's good to prevent up migration of the tasks that are lower priority & flagged as background tasks.
Notes:
1. If enabling the described hotplug configuration on the A53 cluster make sure that it's enabled only on the V2 revision of the core's & that the tool chain (compiler) is set to the strict ID-ing of the core revision along with no A53 erratums forced.
2. The given 2+2 configuration covers all possible scenarios of the thread migrations including SMP one's & it's considered as optimal one by me.
3. In order for this to work properly (& anything else for that matter) the general scheduler patching is required which is available in nijel8 Github kernel repository (mainline port fixes and mostly from Petr).
4. Alternative setup is all four A53 cores active with one A72 core's active all the time, it provides some power saving (in idle and low load states mostly) compared to 2+2 (with A72 core's which falls close to none with A73 core's) but it doesn't cover SMP up migration case along with minor performance degradation. The rest part remains the same.
Feel free to quote me.
As I believe in good old healthy logic which this is I don't find it particularly "smart" one either.
Best regards.

@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.

nijel8 said:
@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.
Click to expand...
Click to collapse
Well it's pretty much not anything new nor something we didn't try already together & most of the stuff you already implemented.
Cheers!

thank you guy thank a lot for all your help

Red Magic 5G MOD Kernel GPUOC 900/940mhz +battery 1.4 STABLE!

{
"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"
}
*** NOTE THAT 3.16 NA OR 4.13 Red Magic 5G SPECIFIC ROMS SHOULD BE USED WITH THIS KERNEL! THE COMBINED ROM (WITH RM5S) HAS UPDATED KERNEL CODE THAT IS NOT FULLY COMPATIBLE AND NUBIA HAS NOT UPDATED THEIR SOURCE CODE ***
*** Please click Thanks (Thumbs up icon) on my post here if you like my kernel and rate the thread 5 stars, then just use it and enjoy - if you want to send me a beer or two feel free - you don't have to use PayPal - Revolut and Amazon.com (USA) gift cards avoid fees. I like to hear from happy users I hope you are glad that you have the fastest phone in the world currently. The active cooling in this device is utilized to the extreme with MOD kernel, meanwhile your battery usage will be much improved at the same time. How? Well, that's all in the source code, free for all to fork it on GitHub and modify to your liking. Just don't forget to credit me and the many great devs that made the improvements possible... without them, there would be no MOD kernel. This is just a hobby of mine and I like to produce a nice product that all can enjoy. I'm also quite friendly and although I may tell you no I won't add that feature (such as network hacking tools), I won't hold anything against you for asking. I have not been compensated other than by some generous folks on my Telegram channel, so this whole project is basically self funded. Red Magic will not support it, unfortunately, but you can if you feel the improvements are worth it. I believe they are, but I come from a biased point of view as the sole developer for RM5G ***
********************************************************************************************************************************************************************************************************************************
NOTICE: YOU ASSUME FULL LIABILITY FOR ANYTHING THAT MAY HAPPEN TO YOUR PHONE USING THIS KERNEL. ALTHOUGH IT WORKS 100% ON MY PHONE, IT MAY NOT WORK THE SAME ON YOURS. THE PROCESS OF ROOTING A PHONE AND INSTALLING A CUSTOM KERNEL ALWAYS HAS RISKS, SO IF YOU ARE NOT COMFORTABLE ASSUMING THOSE RISKS, DON'T INSTALL THE KERNEL! THIS IS A TYPICAL DISCLAIMER FOR CUSTOM KERNELS I HAVE FOUND NO BUGS WITH IT AT ALL. USERS ON CN, GLOBAL, AND NA ALSO HAVE NOT FOUND ANY PERFORMANCE ISSUES OR BUGS (DO NOT USE V7.14 or V8.11) IF YOU DON'T KNOW WHAT YOU ARE DOING, IT'S BEST TO REMAIN STOCK. OR JOIN THE TELEGRAM GROUP, AND GET SOME REAL HELP.
********************************************************************************************************************************************************************************************************************************
Easy root method: https://forum.xda-developers.com/nu...nner-tutorial-unlock-bootloader-t4131585/amp/ although I suggest still using Magisk 20.4 for root.
Note: if you've already rooted and want to upgrade, people have had success saving the kernel as boot.img and TWRP as recovery.img in SmartPack, vbmeta skip as vbmeta.img and placing into the ROM update.zip using MT Manager (a root browser) and saving the updated file. Then do a Settings / System Update / click the 3 dots / local update and select your modified file. In fact I upgraded from 3.13 to 3.16 NA ROM without losing anything this way. Now for normal installation:
Custom kernels require root and Magisk to be installed. This is due to the signature not being signed by Red Magic (the company) itself. Following the above method you will still pass SafetyNet and most apps will work without trouble. If you have a specific app that detects root, well, Magisk Hide the app from Magisk Manager and see if that fixes it. You should also Hide Magisk Manager from various forms of detection (under Settings). Last case is to move the installation of Magisk under a random directory (which I have not had to do and all my banking apps still work), only if the root detection methods used by your app providers are more picky.
MOD KERNEL 1.4 STABLE:
RELEASE NOTES:
Block mode I/O has been changed to Multi-Queue from Single-Queue so your default scheduler is now MQ-deadline (credits to PappaSmurf, excellent kernel dev). You can choose between mq-deadline, kyber, and none in a kernel manager under I/O scheduler. From my benching with Androbench, it doesn't make much difference which one you use. Some have parameters you can tweak. None literally means no scheduler which is fine on an SSD, and has no overhead if you want to select it in a kernel manager. I always recommend SmartPack. To get settings to stick you Toggle "Apply on Boot" and it will go to what you've selected after 5-10 seconds on the next boot.
All debugging has been turned off completely on BBRv2 - thanks to PappaSmurf (I missed a few spots), and debug can't be turned back on from the userspace now. BBRv2 is selected as the default TCP algorithm which users have explained as a "no-lag" algorithm while gaming. It's just generally a fast algorithm all around. For me it works great, but you can still choose from many different algorithms in a kernel manager if you want to.
In SmartPack / Misc / TCP Congestion Algorithm, you have many choices: reno / bbr / bbr2 / bic / cdg / cubic / dctcp / westwood / highspeed / hybla / htcp / vegas / veno / scalable / lp / yeah / illinois. A SmartPack script is included below you can add in SmartPack to show the true TCP algorithm as it will always show Reno (a bug also shared by FK kernel manager). Below it's called Check_TCP.sh just go to SmartPack / Script Manager / Import / Check_TCP.sh. Afterwards, click Execute to see the active algorithm. If you set it on boot, this is the algorithm that will run, despite what the field says in Misc.
Battery is running very well on normal usage I'm getting around 7.5% active screen on drain over 7 hours and <0.7% screen off drain over 13 hours at 90hz screen setting. This is with actively using the phone for multiple "normal" purposes, reading emails, browsing websites with Chrome, reading news, streaming videos, etc. various shopping (Amazon/eBay) and tracking, Reddit feeds and live video, and other random "daily" tasks, up to 10 apps open at a time. Gaming of course will drain more, as will 144hz. I also have dark mode enabled in Settings. To get idle drain down I disabled 3 additional wakelocks that were causing high screen off drain, and so far I haven't seen an issue with blocking them. I also removed wakelocks that no longer exist since the Boeffla WL Blocker default list was created (it was quite old) so it now should be relevant for this device, with no interaction on the users part to disable anything via a kernel manager. Still, in SmartPack you will see a Wakelocks menu in case you install an app that causes idle drain to rise, this can be used to find and block wakelocks causing the problems. It can sort by wakeups and also by time. As it states though, you should be very careful what you disable. There can be unintended consequences and most wakelocks are not well documented as to what they actually control.
Dynamic Stune Boost is entirely removed from the kernel code now, as I didn't see any benefit from using it with this kernel.
Don't forget Dynamic Fsync is hidden under Misc in SmartPack which if you turn on will speed up your SQLite speeds. AnTuTu will penalize you for this, ignore it, your phone will be faster - but I leave it off by default. Androbench will show the true memory benefit. It is significant if an app does a lot of operations on databases. Journaling for the database is held in memory until the screen is off, then it is written. Although there is a chance of a data loss or corruption with this on if the device were to crash, it is safer than just turning off fsync. If you have any unstable apps, just leave it off - better to be safe. On a solid system though, you may notice better performance.
Also remember under SmartPack / GPU there is AdrenoBoost - it is set to low. You can alter to medium or high to get faster transfer between GPU frequencies, although it has worked great for me the way I use the phone. For you another setting may suit you better. Recall RedMagic OS only allows several frequencies which I spaced out as well as possible at 305mhz, 400mhz, 525mhz, 670mhz, 800mhz, and either 900 or 940mhz depending on the version you installed.
Overall I'm very satisfied with this kernel build and don't plan on adding or subtracting anything from it for the time being. It does what it should do, gives solid performance, and good battery life. My last score on AnTuTu setup with defaults 12GB/256GB was 682K which currently is still the top performing phone out there - running at 940mhz GPU. Not all phones can handle 940mhz so use 900mhz if yours cannot. If there are enough requests for an intermediate build (say 925mhz) I can add one later off the same code base. Also note in releases there are "gaming" builds that don't keep track of CPU times at each frequency, which was a request by users to remove any potential lag while gaming. I run the non gaming version, useful if you want to tweak battery usage, but nonetheless, both versions are there for you to use.
I'm on Telegram t.me/NubiaRedMagic5G_Mods as long as I have the phone. Which will be quite a while if Red Magic / Nubia decides to fix N41 5G in the USA.
Also note that all the features of this kernel (besides ones specifically added by me) are the creation of other developers whose contributions are all notated in the kernel source code. Some of the developers that have contributions here or helped me in some fashion: Resurrect88, DD3Boh, PappaSmurf, kdrag0n, Ayrton990, Flar2, Lord Boeffla, plus many more across the globe. Without them, I wouldn't be making any kernels! And I'm sure there are many other devs I've forgotten to mention, I thank all you guys for your help and support.
MOD 1.4 Download Link:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.4
PRIOR RELEASES BELOW:
8th Release:
MOD KERNEL 1.35-BBRv2 STABLE:
RELEASE NOTES:
This is an intermediate release - I realized that the prior release was draining far more battery than it should, and I found the source was debug related code in BBRv2 from Google. So this is the updated kernel that gives you battery life like before this TCP algorithm was added.
CONFIG_CPU_FREQ_TIMES=y has also been added so you can see in a kernel manager how much time is spent in each mhz block for each set of processors. This can be useful if you set in a kernel manager (like SmartPack) a minimum CPU mhz to see how much time is actually spent at each level.
The code base also has Dynamic Stune Boost, but I haven't had time to optimize it for the device, so it's just on default settings. So there are 2 versions of this 1.35-bbr2 release. At some point it will be enabled as part of a regular release (some 17 commits squashed together into 1, Stune Assist was causing issues so I turned it off). The main idea of that set of code additions is to run the device at lower frequencies, saving battery, while still achieving the same performance level to the user of the phone. If you want to try different options for it in SmartPack or FK Kernel Manager you can.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.35-bbr2
7th Release:
MOD KERNEL 1.3-BBRv2 STABLE:
RELEASE NOTES:
Added the 31+ commits for BBRv2 from Google. Squashed the commits down to 6 by author from Google (for easy code maintenance). It's said to be the best TCP (internet congestion) algorithm so this sets it by default. You can still select from the others added in 1.3, as mentioned only EX Kernel manager properly shows them. But SmartPack if you choose the one you want under Misc, then click Apply on Boot, it actually will load the TCP algo you selected. It's just a visual defect. I also made a script for SmartPack uploaded to show you the TCP algo that's selected in my repo you can install so you can verify for yourself. Give it 10 seconds (default on boot setting) before you check.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3-bbr2
6th Release:
MOD KERNEL 1.3 STABLE
RELEASE NOTES:
All this release adds is TCP congestion algorithms. The only kernel manager which correctly shows the algo set correctly is EX Kernel Manager. Using SmartPack or FK Kernel Manager will tell you that you're always on Reno, when in fact, you aren't. I'm not quite sure if this is bug related to 865 kernels as a fellow dev had the same experience (on an Op8 Pro). Now the default is set to BBR. Why? No reason specifically, although it is one of the better algorithms for internet usage. You can easily change in any kernel manager and set on boot which one you'd like to use (see above RELEASE NOTES if using SmartPack). But this gives you plenty of options:
BBR, BIC, CDG, CUBIC, DCTCP, WESTWOOD, HSTCP, HYBLA, HTCP, VEGAS, RENO, VENO, SCALABLE, LP, YEAH, ILLINOIS
You can Google the benefits of each and pick what you like. Or just leave it alone. The prime idea of MOD kernel is that you don't need to adjust anything it just works optimally without any intervention. Read the release notes for prior features that have been added. There are many just not summarized in a single place at the moment. All the optimization has been done for Red Magic OS.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3
5th Release:
MOD KERNEL 1.25BETA
RELEASE NOTES:
This release is mostly about battery savings. I'm averaging around 6.5% active drain on normal tasks with this version (90hz setting), and around 0.5% screen off drain. A big improvement over the stock kernel. So I ended up with about 13 hours SOT + 24 hours screen off on 1 charge! See the picture, I stopped at 11% left. Now I didn't say anything about gaming. If you want to game and have power saving benefits, don't enable any of the built in boosting modes in the game launcher - the Red Magic OS will override everything. Let the kernel do the work for you. And if you're seeing any graphics lag, go into SmartPack kernel manager (free) and go under GPU, Adreno Boost is enabled on low, you can set it to medium or high. That will increase the speed at which the GPU throttles up and down.
1) Switch to the Energy Model for CPUs: Several subsystems (thermal and/or the task scheduler for example) can leverage information about the energy consumed by CPUs to make smarter decisions. This config option enables the framework from which subsystems can access the energy models.
2) Added CPUMASKS for the Little, Big, and Prime cores from Sultan Alsawaf Sultan: SultanXDA, prime added by Danny Lin: kdrag0n.
3) Added kernel control of the minimum frequencies for the little and big clusters by Danny Lin kdrag0n. They are set to run at their minimum running frequencies when idle 691mhz (little) and 710mhz (big) which results in nice power savings when web browsing or just under low load in general. Prime cluster min is not set as it makes the CPU scheduler function poorly.
4) Added AdrenoBoost by Aaron Segaert: Flar2, with all its changes squashed into 1 commit. Defaults to low setting. As mentioned before, you can change in SmartPack, and set on boot if you need a higher value than low: https://github.com/SmartPack/SmartPack-Kernel-Manager/releases
5) Uploaded the various GPU OC files to the repo, It still will just build off the default one, but they are here to be complete. 940mhz version again is posted, Building direct from the repo will give you 900mhz max GPU.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.25BETA
4th Release:
MOD KERNEL 1.2 BETA
RELEASE NOTES: (Note a 940mhz GPU clock edition is available, if you want to try it, a few of us have had good results on it. Likely the max an 865 GPU can run. You'll sacrifice the power savings, however):
1) Enable Power-efficient workqueues by default, add a toggle that can turn this off via a kernel manager (under CPU in SmartPack). Enabling this makes the per-cpu workqueues which were observed to contribute significantly to power consumption unbound, leading to measurably lower power usage at the cost of small performance overhead. Have also added many other power saving features to the defconfig. The phone is a beast, power savings is a good thing to implement.
2) Update the LZ4 decompressor algorithm with a much faster variant for the ZRAM swap, now version 1.8.3-9 credits Gao Xiang [email protected] and many others (check commits). Speed improvement below (should help on 8GB devices):
Compressor name Compress. Decompress. Compr. size Ratio Filename
lz4hc 1.7.3 -9 12 MB/s 653 MB/s 42203253 42.20 enwik8
lz4hc 1.8.3 -9 11 MB/s 965 MB/s 42203094 42.20 enwik8
3) Default scheduler is set to SQ deadline. Should see minimal improvements in speed until I get a MQ variant working. On the task list ahead.
Download Link:
1.2BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/download/1.2BETA/MOD-RM5G-GPUOC-Beta1.2.zip
940mhz GPU release here, it's still 1.2BETA, just with the max clock a few of us have been able to use. That doesn't mean your device can for sure handle it, but give it a try if you'd like! Note the power savings will likely not be there vs the other release at 900mhz:
https://github.com/mrslezak/NX659J_...oad/1.2BETA/MOD-RM5G-GPUOC-940mhz-Beta1.2.zip
3rd Release:
1.15BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.15BETA
This is a HEAVILY updated release of the MOD kernel 1.10BETA - I realized the phone's software will allow 6 frequency clocks, although 1 did not have a regulator defined (now patched). NOW I VERY HIGHLY suggest installing SmartPack Kernel manager. It will give you insights into the kernel and how it's performing and it's free. It also will let you adjust added options now in the kernel. Just root your phone and flash from TWRP. If you haven't already installed Magisk, then install that too. There's a guide I posted on XDA about that. Use the experimental method there is no reason to unlock your bootloader. https://forum.xda-developers.com/nu...how-to-unlock-bootloader-redmagic-5g-t4081743
RELEASE NOTES:
1) Bugfix: there was 1 missing 800mhz GPU frequency regulator clock on the prior version. This has been set to TURBO, 1 level under the 900mhz regulator of TURBO_L1.
2) Boeffla WakeLock blocker (v1.10 + tweaks) has been added to reduce battery drain when the phone is not being used, using the latest version and all patches. A default block list is included. You can access in SmartPack Kernel Manager under the new menu that will appear "Wakelocks" - especially investigate if your phone has high idle drain, you can experiment with blocking other wakelocks (which don't allow your phone to sleep). Or you can leave as is. I get just under 1% drain (screen off) and the phone sleeps quite often with this version. Take a look at the screen shot! That's just normal phone usage, not gaming.
3) All debug entries (except those required) have been stripped completely out of the kernel. This results in less wasteful debug information being generated.
4) The default algorithm for ZRAM has been changed from LZO (high compression, but slow) to LZ4 (slightly less compression, but fast). LZ4 algo was added. It still defaults to 4GB.
5) Dynamic Fsync has been added to the kernel as well. This patch allows journal entries to be written only when the screen is off. I.e. they are cached and written afterwards. This increases database performance. It is disabled by default so in SmartPack Kernel manager, if you'd like to turn it on, go under Misc, select Dynamic Fysnc, and select apply on boot. There is always a risk of data loss when delaying writes, although I've personally never have had issues - it only happens if the phone crashes, and mine has never crashed on this kernel. This won't normally increase your benchmark scores (except AndroBench), it increases SQLite database access speed. Up to you to use or not, works fine on my device.
6) Here are the updated frequencies (note there is 1 more). Will have to wait for AOSP before I can add back more. Note the 670MHz is likely the 865+ max frequency per the release notes today on the device (which I assumed by the source code anyhow pre-announcement): 900MHz / 800MHz / 670MHz / 525MHz / 400MHz / 305MHz
AS ALWAYS, USE AT YOUR OWN RISK!!!
Github Source:
https://github.com/mrslezak/NX659J_Q_kernel
Initial Release:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.0.BETA
Second release - gets over the "reset to 490mhz" bug caused by the system software, at the expense of reducing frequencies to 6 total:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.10BETA
Newest release -> will be posted on the top from now on.
Telegram:
https://t.me/NubiaRedMagic5G_Mods
And note the AnTuTu benchmark is just a first run after installing. 670K is likely a record on any 865 phone. The last bench turning off 4GB ZRAM (12gb/256gb device) I got 673K. AnTuTu doesn't equal performance, but if you've benched you'll see this is an insane improvement over the stock kernel. Only when the demand is there will it scale up to 900mhz. I've been using for a while now and notice no difference in battery life. The Adreno driver is very good at handling extra clock frequencies efficiently without modification (despite an "Adreno Boost" that is often added to kernels). The gamers using the kernel are making statements that they couldn't imagine the game play any better than it already was, but now it's even smoother.
Unfortunately the way the Nubia software behaves, it auto-resets to power level 5 (which was 490mhz) on the 1.0BETA on boot and also after boosting the frequencies up. I tried every possible way to bypass this but eventually just gave in and removed frequencies. So the BETA1.10 and above have less frequencies but will always revert to 305mhz, the base minimum frequency of the device. Hopefully once we have AOSP ready I can add more.
MattoftheDead
I.e. M.O.D. Kernel Developer
The first Red Magic 5G OC kernel.
Xiaomi Mi9 / Mi9T Pro Pie V2 and Q V1.5 Kernel Dev

Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.

This is amazing !!! :laugh:

Is this going to work on all roms like CN, NA or EU Roms? Im currently running NA 3.11 flash from CN rom with root and twrp

We have people using it on CN Global and NA versions no problem at all. Works fine on every model.

Kernel is fully functional no issues at all.
CN Rom to NA Rom v3.11
305mhz min to 900mhz max confirmed and using smart pack to control the frequency
Thank you for this hopefully there is more development i really appreciate ur effort

Kernel building is just a hobby of mine, I was posting a minimal kernel to get some more kernel developers on board to hopefully add more features. I usually add Boeffla Wakelock Blocker and Dynamic Fsync and call it a basic kernel. The last super kernel I made took way too long, and I don't have that kind of time anymore - boost functions and underclocking to balance out the battery life and such. Development work doesn't pay anything, I didn't get the phone free, all my donations go to other developers. And I have a full time job and family. But if anyone wants to port over my MOD Kernel Q 1.5 Mi9 features, well that would be a super kernel. It's just really, really time consuming, time I don't have at the moment. And the merging of source has to be EXACT or you end up with a really slow phone rather one that balances underclocking, boost, and overclocking.

MishaalRahman said:
Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.
Click to expand...
Click to collapse
All the gamers using the kernel are reporting that the games run smoother than before, which no one thought was possible. It is already a flagship device. But the GPU OC with the Adreno driver scales when needed up to the frequencies that it has in the table and has no issue on 670, 800, and 900mhz reported so far. There are gamers on NA, Global, and CN ROMs, with no bugs reported. No issues and everything works properly. I have tested myself and although I'm not a gamer, all the functions work as they should. It still connects via Bluetooth, it still takes photos and videos, etc. There is no lag whatsoever. Overall I think the frequencies are ideal for this device with it's advanced active cooling system. Other devices however, with passive cooling, are unlikely to handle the increased GPU clocks.

I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update

What to do to root the phone without breaking the fingerprint please. I read the article publish nothing understood someone can explain to me step by step. I am an amateur I never root a phone. I have cn 2.55 16gb.

I don't have the same issue - I just tried to recreate it by watching a YouTube video and I went back to SmartPack and it still shows 305MHz GPU frequency. Although I'm using the debloated / optimized ROM I created Black Magic 5G which has everything setup properly, Nubia apps frozen, everything moved to 3rd party apps. NETFLIX patched to 4K HDR10, YouTube Vanced, a ton of root utilities, AdAway ad blocker, etc. You can find it on the Telegram channel (I'm using the NA/Global version of Black Magic 5G). Then I watched Netflix, still at 305mhz. As I have no idea how you've setup your phone, I just can't recreate it.
shaifabra5 said:
I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update
Click to expand...
Click to collapse

Yeah maybe because you modified the rom.
Im currently running Flash Global V3.11 when i tested your kernel no modification made im just rooted with TWRP Installed and i posted this kernel on red magic 5g group on facebook and 3 of us having the same issues as well.
Im gonna try it again on V3.13
UPDATE:
still returning to 490mhz as minimum frequency after gaming and after watching one youtube clip
kinda sad hopefully you can fix this bug on the global rom that nubia provided if you have the time, great kernel for gaming because of the 900mhz boost and the phone can sustain this boost because of the active fan

Why don't I have a roughly similar score?

Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.

Blink003 said:
Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.
Click to expand...
Click to collapse
I believe Qualcomm blocked overclocking of CPUs quite a while ago from SD845. Only GPUs can be overclocked.
Though I don't know if devs have gotten tools to get around it.

The 490 bug looks like it's related to the gaming mode APK resetting the min frequency. I can't decompile or recompile APKs so I don't have a way to get around the system reverting to 490 without removing 3 other frequencies. It seems hard-coded in the app that it only expects to see 5 frequencies so to have all working properly, 3 need to be removed. This is in contrast to what my buddy dev on the Op8 Pro can do, but this device is designed differently in how it boots and custom apps that increase frequency clocks. If any devs are good with APKs it's a very simple function call that sets the minimum GPU frequency. The only odd thing I see is that the minimum power level stays at 8 (minimum) which corresponds to the lowest clock speed. That number doesn't change in a kernel manager when the min GPU clock reverts to 490.
I'm off on vacation not near a PC but will try to come up with a stock # of clock frequencies that still scrolls smoothly between them and the Adreno GPU driver. May take a few tries but it's quite easy to modify. I already think 180mhz is too low from using it, it's more of a sleep frequency some suggested going this low but I think the phone design is for 300+. I prefer to use more clocks for better throttling but have to work with what we are given and do the best inside those boundaries.
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.

mslezak said:
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.
Click to expand...
Click to collapse
Qualcomm's Meizu’s CMO Wan Zhiqiang recently commented on Weibo saying that there won’t be a Snapdragon 865 Plus this year.
We will see!

No 865+ this year..
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.

mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
Is it possible to overclock the memory clock too? I assumed that 900mhz is the core clock.

mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
You're right, that makes sense.
I'm glad they are making a refreshed chip.
On another note, do you think we will see an overclocking tool in the future?
Possibly with a custom ROM?