Hello everybody, today I present my guide or actually the procedure of modifications presently installed on my Xperia U.
1. Grab your Xperia U (I presume it is bootloader unlocked, rooted and installed Stock ICS based firmware)
2. Battery Supercharging-
a. Let your battery charge to 100%
b. Unplug charger and Reboot into CWM and wipe battery stats
c. Reboot into system and use phone as normal until battery is exhausted. (Now your battery is calibrated)
d. For maintenance of life of battery pack thereafter, let battery drain to not below 10%
e. Always charge battery short of 100% i.e. 85-95%
f. Once in a month, shut down your phone at 30-60% charge, remove your battery, and just leave it outside the phone for an hour or so.
Be compassionate, as Gandhiji had said
g. If you want to recalibrate your battery, follow steps 2a-2c. Recalibration for Li-poly is not that essential, since it has no memory but you can do it once a month or after flashing a new ROM.
h. Never leave your battery discharged for very long. Your Li-Poly battery will suffer a deep discharge.
3. CPU Control
a. Download BrainsKernel or Munjeni's Kernel
b. Install it using flashtool or fastboot (i presume you know how to do so)
c. Download your favourite CPU Control App (setCPU, noFrills CPU Control etc.)
I recommend CPU Tweaks as it gives you info on both cores at the same time and also has the time graph for when CPU is asleep (setCPU lacks that)
d. My recommended governor setup-
[Try to use a governor with inbuilt hotplug technology (hotplug means ability to control cores i.e. turn of second core when not required and turn it on when required) Eg. Hotplug, Lulzactive, PegasusQ, Hotplug etc.]
For normal use-
LulzactiveQ 800/200 MHz
For Music(Screen Off)
OndemandAX 800/200 MHz
For Gaming(Dead Trigger etc.)
Ondemand/Hotplug 1000/200 MHz
TIPS-
Remember that most governors with a screen off profile(Smartass, LulzactiveQ, OndemandAX) built in have a wake frequency (CPU immediately jumps to that frequency when screen on) is around 500-700 MHz, so try too keep your Max CPU limit at 800 MHz to prevent screen on delay. This is required as Xperia U has no 600 MHz intermediate CPU step, it has only 400 and 800. 400 is below the wake frequency so capping CPU at 400 MHz will cause lag during wakeup.
For me, using LulzactiveQ saves more power than SmartassV2 or Powersave. This is due to the fact that LulzactiveQ shuts off my second core much faster and much more dynamically than SmartassV2 of Powersave.
LulzactiveQ has a screen off profile of setting CPU speed to around 200-400 MHz while OndemandAX caps it at 500 MHz.
So OndemandAX is better for music as there is no tearing in playback when screen is turned off.
e. If you want to forcibly keep one core off (NOT RECOMMENDED. USE A HOTPLUGGING GOVERNOR INSTEAD) use XCore. It works on Xperia U and Xperia P. Check out the Play Store for further details.
4. RAM Management (Android does this on its own, usually. But you can help it)
a. NEVER use a Task Killer. Android kills tasks much more dynamically than your brain does
b. Delete all bloatware you do not need. This will prevent some background processes from being run and it will save some RAM.
c. Do not use a separate app for Facebook unless absolutely needed. (XDA App is fine )
d. That widget, sitting on your homescreen, which hasn't been touched for the past 1 week can be trashed.
5. GPS Superiority (You'll never use AGPS anymore)
a. Download an app called FasterGPS from the Play Store.(needs root)
b. Open the app and choose you continent and region. If your region isn't there, choose the closest region.
c. Get your ass out in the open and get a lock in less than a minute only on pure integrated GPS.
6. General Tweaks
a. Go to developer options in settings and set Animation Scale to 0.5x
b. Get a good statusbar mod (I recommend Xperia Tab n Grid Jelly Bean).
Why? So that you turn off the WiFi and BT and Packet Data when not required. I wouldn't do that earlier as I was too lazy to go all the way to settings to do so. Now I use the notification toggles and save some power
c. Turn OFF your phone and then charge it.
d. Use Lux Dash, an app to control your brightness. At night, set it to sub-zero to save power.
7. Physical Tips
a. Get a case for your phone. Incase you drop it, it will protect your phone.
b. I know you're tempted to take your phone to the pot and have fun but NO. People have lost phones like that.
c. Every week, clean your phone with a spectacle cloth.
d. Do not overstress your phone, or else you risk your hardware. I know they are designed to face all this but as Gandhiji said, compassion.
Hope these tips help you and your phone
We're trying to benchmark an app on our DNA Droid and want to forcibly enable/disable CPU cores. We've done this on other devices, but it appears the Krait/Qualcomm stuff has another layer that disables CPU cores after we enable them through /sys/devices/system/cpu/cpu#/online = 1. I'm guessing a power save level. We also normally switch to userspace governor to force the CPU to run at a certain frequency.
We could use an app if that is the only way, but we would prefer scriptable (command line) solutions. And we're running a basically stock kernel + the writable system area patch (from here).
Thanks in advance.
Using the shell, try killing mpdecision.
Sounds like a good target after my quick Google search for what that is. I'll let you know what we figure out (the other guy is at lunch right now ).
---------------------------------------
"adb shell stop mpdecision" seems to block it until the screen goes off. Then if you disable the screen sleeping while connected (in developer options usually) we hope to be golden for now. Would be nice to be able to just disable it all together, but this is at least a workable crutch.
Apparently killing the process just triggers a re-run of the it.
I believe there is a great deal of confusion or lack of technical explanation available here in the community, when we discuss the how’s, why’s and what’s behind the things we choose to modify in the Android OS in an attempt to squeeze better performance from a very complex operating system. Many of the things I tend to see presented to users are focused on very ineffective and ancient mentalities, pertinent to an older version of the operating system. Much of this is attempted through modifying build properties, and that’s usually about where it stops. My objective here is to describe some of the ins and outs of tuning a mobile operating system such as Android, and looking at it in a different light - not the skin you lay on top of it, but as advanced hardware and software, with many adjustable knobs you can turn for a desired result.
The key players here are, usually, without fail a couple of things alone:
Debloating – which, I suppose, is an effective way to reduce the operating system’s memory footprint. But I would then ask, why not also improve the operating system’s memory management functions? (arguably more important than merely removing unwanted apps)
“Build prop tweaks” – the famous build.prop, which is a property file by which you can apply very effective changes like the ones presented in my post_boot file (the only difference being when they are executed, and how they are written out), but most of the “tuning” done here focuses on principles that were only once true and, thereby, mostly irrelevant in today’s latest versions of Android. There are many things within the build.prop that can (and sometimes should) be altered to directly impact the performance of the DVM/JVM. However, this is almost always untouched.
Every now and then, somebody will throw a kernel together with some added schedulers, or some merged sound drivers, etc., but there is really little to no change that would effect real time performance observed by the user.
So, what about the virtual machine? What about the core operating system? – what Android actually is – Linux.
You’d be surprised how effective some simple modifications to just 1 shell file on your system can be at improving your experience as a user.
So, how do we make our devices feel like they have been reborn with just 1 file and not an entire ROM? That stock ROM you are on will suddenly feel not so stock.
My aim here is to talk about, at a medium to in-depth level, what exactly went into the file I added to the development section that turned a performance corner for your device. For now, let’s just talk about the CPU.
Let’s look at a snippet of some code from the portion of the file where most of the CPU tuning is achieved, we’ll use cluster two’s example. Bear in mind, the methodology here was used for cluster 1 as well – your smaller cores were treated the same, in theory:
Code:
# configure governor settings for big cluster
echo 1 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load
echo 1 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif
echo "10000 1401600:30000 2073600:60000" > /sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay
echo 20 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load
echo 10000 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate
echo 20000 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack
echo 806400 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq
echo 1 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/io_is_busy
echo "40 1190400:60 1478400:80 1824000:95" > /sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads
echo 30000 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time
echo 0 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis
echo 307200 > /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq
echo 0 > /sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif
So what did I do here? Well, let’s start by explaining the governor, and then its modules.
Interactive: the interactive governor, in short, it works based on timers and load (or tasks). Based on load when the timers are ticked and the CPU is polled, the governor decides how to respond to that load, with consideration taken from its tunables. Because of this, interactive can be extremely exact when handling CPU load. If these tunables are dialed in properly, according to usage and hardware capability, what you achieve is maximum throughput for an operation, at a nominal frequency for that specific task, with an optimal delay. Most of the activity seen in an Android ecosystem is short, bursty usage, with the occasional sustained load intensive operations (gaming, web browsing, HD video playback and recording, etc.). Because of this unique user-interaction with the device, the default settings for interactive are, usually, a little too aggressive for a nominal experience – nominal meaning not “over-performing” (or the opposite) to complete the task and wasting CPU capability or overusing it. The interactive tunables:
use_sched_load: when this value is set to 1, the timer windows (polling intervals) for all cores are synchronized. The default is 0. I set this to 1 because it allows evaluation of current system-wide load, rather than core specific. A small, but very important change for the GTS (global task scheduler).
above_hispeed_delay: when the cpu is at or above hispeed_freq, wait this long before increasing frequency. The values called out here will always take priority, no matter how busy the system is. Notice how I tuned this particular setting to allow an unbiased ramp up until 1.40 GHz, which then calls for .4 seconds delay before allowing an increase. I did this to handle the short bursts quickly and efficiently as needed, without impacting target_load (the module, in this way, allows the governor free range and roam according to load, then, is forced to wait if it wants to utilize the faster but power-costly speeds up top). However, sustained load (like gaming, or loading web pages) would likely tax the CPU at intervals larger than .4 seconds. The default setting here was 20000. You can represent this expression as a single value, followed by a CPU speed and delay for that speed, which is what I did at the 1.40 GHz range. I usually design this around differences in voltage usage per frequency when my objective is more to save power, while sacrificing a slight amount of performance.
go_hispeed_load: when the CPU is polled (at the timer_rate interval) and overall load is determined to be above this value (which represents a percentage) immediately increase CPU speed to the speed set in hispeed_freq. Default value here was 99. I changed it to 20. You’ll understand why in a second.
timer_rate: intervals to check CPU load across the system (keep in mind use_sched_load). Default was 20000. I changed it to 10000 to check more often, and reduce the stack up delay the timer rate causes with other tunables such as above_hispeed_delay, as the timer rate is added on top of that value. Meaning if you set the timer rate to 10000 and the above higspeed delay to 50000, your total delay above hispeed is 60000).
hispeed_freq: counterpart to go_hispeed_load. Immediately jump to this frequency when that load is achieved. Default here, in Linux, is whatever the max frequency is for the core. So, the CPU would be tapped out when load is 99%. I usually set this to a lower speed and compliment it with a smaller go_hispeed_low value, and adjust dynamically all the way to max frequency. The reason I do this is to respond appropriately to tiny bits of usage here and there, which minimizes the probability that the CPU will start overstepping. There are a lot of small tasks constantly running, which can and should be handled by lower frequencies. The trick with this method of approach is to stay slightly ahead of the activity, which increases efficiency, while removing observed latency as much as possible. There is no hit in power by doing this. This principle of approach (on a broad scale) is how to use interactive to your advantage. I remove its subjective behavior by telling it exactly where to be for a set amount of time based on activity alone. There are no other variables. “When CPU load is xxxx, operate at these parameters.” Or, “when CPU speed is xxxx, operate at these parameters.”
io_is_busy: when this value is set to 1, the interactive governor evaluates IO activity, and attempts to calculate it as expected CPU load. The default value is 0. I always set this to 1, to allow the system to get a more accurate representation of anticipated CPU usage. Again, that “staying ahead of the curve” idea is stressed here in this simple but effective change.
target_loads: a general, objective tuneable. Default is 90. This tells the governor to try to keep the CPU load below this value by increasing frequency until <90 is achieved. This can also be represented as a dynamic expression, which is what I did. In short, mine says “do not increase CPU speeds above 1.19 GHz unless CPU load is over 60%... and so on…
min_sample_time: this is an interval which tells the CPU to “wait this long” before scaling back down when you are not at idle. This is to make sure the CPU doesn’t scale down too quickly, only to then have to spin right back up again for the same task. The default here was 80000, which is way too aggressive IMO. Your processor, stock, would hang for nearly a second at each step on its way down. 3/10th of a second is plenty of time for consistent high load, and just right for short, bursty bits of activity. The trick here is balancing response, effectiveness, acceptable drain on power, with consideration to nominal throughput.
max_freq_hysteresis: This one is a ramp down delay only enforced when the core’s max scaling frequency is hit, specified in µs (microseconds, i.e. 20000) which tells the CPU that when the core hits its max frequency, keep it there for this long before ramping back down. This parameter is used as an assumption, really, in the sense that “because CPU core0 was tapped out to max frequency, there is probably more heavy lifting coming, so we’ll remain here to make sure there isn’t more to do”
So, you can see how we are starting to better address the “activity vs. response” computing conundrum a little more precisely. Rather than throw some arbitrary numbers out there, I specifically utilize a frequency windows with a percentage of system-wide usage or activity. This is ideal, but takes careful dialing in, as hardware is always different. Some processors are a little more efficient, so lower speeds are ok for a given load when compared to another processor. The key is understanding the capability of your hardware to handle your usage patterns appropriately, is absolutely critical to get this part right – the objective is not to overwork, or underwork, but to do just the right amount of work. Turn small knobs here and there, watch how much time your CPU spends at a given speed, and comparing that with real time performance characteristics you observe, etc… maybe there is a little more stuttering in that game you play after this last adjustment? OK, make it slightly more aggressive, or let the processor hang out a bit more at those high/moderately high speeds.
One way I like to measure the effects of these adjustments is to use graphical benchmarks that don’t really push the limits of the hardware, but bring it right to the edge. You simply watch framerates, stuttering, and turn knobs as needed.
That’s about it for this, hope this provided a little bit of clarity for some of you! I’ll do another write up on the vm (virtual machine) adjustments another time.
thank you for this topic , Any details on ' build.prop tweaks ' ?
and what's the best app for CPU Config ?
Please, can you maie a GPU tweak tutorial?
H-banGG said:
thank you for this topic , Any details on ' build.prop tweaks ' ?
and what's the best app for CPU Config ?
Click to expand...
Click to collapse
Kernel auditor
And which shell file do i have to edit?
I was tired of badly designed SIP clients eating 100% CPU and keeping the device awake, when trying to re-register on a SIP server. So i changed some settings in Synapse for my Note 4 N910F.
When device is asleep (screen locked), the CPU is on minimum freq (268 Mhz).
when screen is unlocked, maximum frequency is 2000Mhz (vs 2800 by default).
these settings helped me get solid 1 day uptime (with quite a lot of browsing), or sometimes 2 days. No problem with calls, or waking the device. (Note 4 Snapdragon).
even when the sip client is keeping the device awake, it is still manageable (due to minimum cpu freq).
This seems so cool!!! Thank you for this write up!! Has anyone ran any battery life and performance benchmarks to see if these mods makes any difference, good or bad?
Also, which shell file do we modify? Which folder is it in?
Neo3D said:
This seems so cool!!! Thank you for this write up!! Has anyone ran any battery life and performance benchmarks to see if these mods makes any difference, good or bad?
Also, which shell file do we modify? Which folder is it in?
Click to expand...
Click to collapse
@warBeard_actual shared his modified file here: https://forum.xda-developers.com/ax...017-axon-7-msm-8996-cpu-vm-ram-t3557392/page6
From my understanding, Kernels that have schedutil governor has a CPU frequency boosting feature which gives the CPU a push from the back to do a job faster than it was supposed to.
It does make the phone notably faster and smoother but if not configured properly the battery takes a hit.
Enabling schedtune.prefer_idle turns off that frequency boost of a running core and forces the workload on an idle core. But there seem to be 4 separate options to enable schedtune.prefer_idle and I have no idea what they are and how they are gonna affect the kernel after enabling/disabling
Those 4 options are :
• Foreground
• Background
• Real-Time
• Top App
Here are the pictures if you want to take a look.
https://imgur.com/a/sxuBvWR
https://imgur.com/a/8e4nuxj
Can someone tell me what each function does? Thanks in advance
@TrenchFullOfSlime can you help me out one more time if possible?
schedtune.prefer_idle appears to influence only one thing: whether a process will share time on an already-active core or wake up an idle core. The latter uses more power but gives the process more resources. CPU frequencies are determined by the _boost toggles, with schedtune.boost determining how aggressively the frequency is changed (accepted values are 0-100, so I guess it's an abstract scale hiding the actual size of the frequency steps). This apparently works by lying to the governor about how heavy a process is: https://lwn.net/Articles/706374/
https://forum.xda-developers.com/t/...-pixel-xl-and-eas-even-more-smoother.3528807/ suggests not going over 10.
https://forum.xda-developers.com/t/screen-on-time.3923963/page-9 suggests "turning off prefer.idle and enabling stune.boost reduced power use by 15% without affecting responsiveness" (paraphrased). Turning both on could increase responsiveness at the cost of greater power use, turning both off would do the opposite.
As for the different categories, they determine what triggers this behavior. You might prioritize performance for foreground apps, but battery efficiency for background apps. It can also be used to increase boot times: https://source.android.com/devices/tech/perf/boot-times
More information: https://www.fatalerrors.org/a/schedtune-learning-notes.html
TrenchFullOfSlime said:
schedtune.prefer_idle appears to influence only one thing: whether a process will share time on an already-active core or wake up an idle core. The latter uses more power but gives the process more resources. CPU frequencies are determined by the _boost toggles, with schedtune.boost determining how aggressively the frequency is changed (accepted values are 0-100, so I guess it's an abstract scale hiding the actual size of the frequency steps). This apparently works by lying to the governor about how heavy a process is: https://lwn.net/Articles/706374/
https://forum.xda-developers.com/t/...-pixel-xl-and-eas-even-more-smoother.3528807/ suggests not going over 10.
https://forum.xda-developers.com/t/screen-on-time.3923963/page-9 suggests "turning off prefer.idle and enabling stune.boost reduced power use by 15% without affecting responsiveness" (paraphrased). Turning both on could increase responsiveness at the cost of greater power use, turning both off would do the opposite.
As for the different categories, they determine what triggers this behavior. You might prioritize performance for foreground apps, but battery efficiency for background apps. It can also be used to increase boot times: https://source.android.com/devices/tech/perf/boot-times
More information: https://www.fatalerrors.org/a/schedtune-learning-notes.html
Click to expand...
Click to collapse
I don't know who you are, I don't know what you do but I feel like you are an angel! You went through all the troubles to get those links only to answer me which made me so happy.
If I'm being honest, the way you describe things is incredible. I didn't have to read a sentence twice. You can be a good writer or a teacher if you try.
Thank you so much