Code:
Disclaimer: I am not responsible for any damage caused by or done with this kernel.
.
About
Welcome! Plasma kernel is a unique and specially tailored custom kernel for the Snapdragon variant of the Note 4. It is the product of my strange brain and the monkeys that reside within it. Plasma kernel is designed to be very flexible, able to cater to those who wish to miser every bit of power, as well as those who demand performance, speed, and fluidity. It combines some common features from brilliant developers around the world, along with a great deal of my own work. One thing worth mentioning is that unlike most other kernels, this one does not offer many CPU governors, as much work was put into its flagship governor, ZZMoove. Currently Plasma kernel is only for TouchWiz ROMs, but an AOSP version is already in the works. Thank you for your interest!.
Screenshots
.
{
"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"
}
..........
.
..........
.
.
General Features
Compiled with Linaro 4.9, tuned and optimized for Cortex A15
Initially based on Starkissed's (twistedumbrella) repo
All settings fully configurable with andreilux's free Synapse app
Mpdecision and thermald disabled
Additional I/O schedulers (noop, deadline, row, cfq, bfq, sio, fifo, zen, vr, fiops)
CPU under/overclocked to 268 MHz - 3,072 MHz
CPU voltage control
GPU under/overclocked to 166 MHz - 800 MHz
Simple GPU Algorithm
Charging control
mDNIe Hijack color control for KitKat
KCAL color control for Lollipop
Kernel Samepage Merging (KSM)
CRC control
TCP control
SELinux always permissive
Frandom
Rngd control
Stereo call recording
Fauxsound
Plasma Features
Extended LED control
Touchkey multipress lockout
Touchkey remapping at the driver level
Touchkey Flicks
Touchkey Slides
Turbo Home button
Plasma Simple Scaling Lock instead of Hardlimit
Optional kernel-level universal wakelock
Optional always-on voice detection tweaks
Optional always-on touchscreen (can wake from deep sleep)
Touchscreen reduced scanrate while sleeping to save power
TouchWake (my implementation)
Slide2Wake (my implementation)
Pull2Wake (my implementation)
Arc2Wake (my implementation)
PlasmaUnlock 2.0
MultiButton
Stem Gestures
Tactile controls (vibrate when touched with finger or S-Pen)
S-Pen adjustable minimum pressure (aka sensitivity)
S-Pen adjustable fixed pressure
S-Pen WorryFree mode
Detailed Plasma Features
ZZMoove: Plasma Edition
Heavily modified version of ZZMoove
Supports various low-level boosts that hook into all other Plasma features
Music detection to help avoid skips
Native Input Booster
Applies a different up_threshold and various other parameters when input events are detected
Dynamically restarts governor timer to instantly apply the requested boost
Can detect, restart, and change frequency within 1ms (according to Wikipedia, 1ms = the time for a neuron in human brain to fire one impulse and return to rest, 100-400ms = time for the human eye to blink).
Many, many other features to be documented later
Extended LED control
Full sub-LED control (RGB) allows you to calibrate to a beautiful white, since not all LEDs are the same and may exhibit ugly tints with factory settings
Adjustable global high and low power sub-LED brightness
Optional pulse (fade) style blinking
Adjustable blink timing
Customizable driver-level TouchWiz LED colors
High/low missed notification sub-LEDs color, defaults to white
High/low charging sub-LEDs color, defaults to white with a red tint
High/low charged sub-LEDs color, defaults to white with a green tint
Touchkey multipress lockout
If you find yourself accidentally pressing a touchkey, this feature can require a double or triple press. Useful for handing someone your phone and not having them accidentally press the Back button.
Touchkey remapping at the driver level
Touchkey Flicks
Quickly pressing and flicking up from either touchkey can perform 2 unique actions
No residual pass-through - meaning only your action gets performed, the touchkey press and any touchscreen input are blocked at the driver level
Supported by Automatic Media Mode
Optional crossed mode to offer an additional 2 unique actions
Touchkey Slides
Quickly slide across the touchkeys from either left or right for 2 unique actions
No residual pass-through - meaning only your action gets performed, the touchkey presses are blocked at the driver level
Only works while the screen is off
Can wake from deep sleep, but may be unreliable for now
Turbo Home button
By default the home activity is executed after the home button has been pressed AND released, which can introduce as much as 100ms of wasted time. This feature will immediately send an up-event as soon as a down-event is detected. Unfortunately this breaks the ability to press and hold the home button - however there is one workaround - another optional mode that will send the up-event, then immediately send another down-event, and whenever you lift your finger, that will provide the mating up-event. This will allow long-pressing the home button, but the downside is that it always must send a complete press before starting to hold.
Plasma Simple Scaling Lock
A very simple replacement for hardlimit
Locks governor name and min/max for anything but Synapse
Kernel-level control of back (flash) LED
Optional kernel-level universal wakelock
Optional always-on voice detection tweaks
Force screen on when activated - If you use a 3rd-party lock screen, you may have noticed "ok, Google" is acknowledged, but doesn't wake anymore. This will send a power-on event to mimic the normal behavior.
Turn power off on second activation (from screen-off) - This was a silly idea I had, but it sorta works. I was frustrated because after saying "ok, Google" and asking my question, the screen would stay on. When this is enabled, it will turn the screen off when you say "ok, Google" a second time. Example: Ok Google...what time is it in NYC?...[The time is 12:21 AM]...ok, Google...[screen turns off]. This obviously only works for things that don't require more input, in which case touching the screen will restore normal behavior. It's sorta cool though because in a quiet car you can ask a question to your pocket and then tell it to turn itself off.
TouchWake (my implementation)
When the screen times out you can wake it with a tap or button press. Functionality is like the existing, well-known TouchWake.
DoubleTap2Wake (see PlasmaUnlock)
Slide2Wake
Pull2Wake
Pull2Wake will wake your device when swiping from the top of the screen, to the bottom. If done slowly, you can use your fingertip to
Arc2Wake
Now part of Stem Gestures
Turn your phone on while grasping it - left/right arc with your thumb from above Home to the side
Touchscreen
Support for waking from deep sleep
Adjustable width for valid Slide2Wake/Pull2Wake to filter out false positives
Reduced scanrate while sleeping to save power
Support for detecting finger hovering (very buggy at the moment)
PlasmaUnlock (previously called PatternUnlock)
A kernel-based screen/input locking mechanism. It is designed to be as flexible as possible, from serving as a simple way (eg. DoubleTap2Wake) to augment your existing power-on methods, to a robust means of protecting your phone from prying-eyes. It features up to a 20-step lock pattern, verified against not only x/y coordinates, but also time between taps, and tap peak-width. Because it resides within the kernel, low-level access provides some unique features not found elsewhere, such as power key blocking, screen blanking, and locking that takes effect so early, it even blocks the boot-animation.
Can be on at all times, doesn't need a wakelock
No complex coordinates to set, the pattern recording feature accessible via Synapse makes creating your pattern easy
Up to 20 taps can be recorded
Mode for taps only, or swipes only (like connect-the-dots), or both
Taps are validated against x/y coordinates, optionally milliseconds between taps, and optionally width
Relative coordinate mode allows for abstract patterns to be input anywhere on the screen, as long as the display is in a portrait orientation
All detection methods can be independently disabled, achieving a variety of results such as:
Unlock with a sequence of wide-thin-wide presses anywhere on the screen, by turning off x/y coordinate and time validation
Unlock with one wide press at a specific spot on the screen, by turning off time validation and using absolute x/y mode
Unlocking with a simple double or triple tap anywhere on the screen, by turning off width validation and using relative x/y mode
Unlocking with a rhythm, by turning off x/y coordinate and width validation and using time only
Adjustable pattern entry timeout (so you don't have to wait for the normal Android screen timeout delay, which is usually at least 30 seconds)
Lockout mode
Can take effect at the boot animation
Locks the touchscreen, S-Pen, and disables USB data connections until the correct pattern is entered
Can also black the screen out. Besides obvious privacy reasons, it also has the potential to confuse/delay thieves.
Optionally disables the power and/or home button (three very fast power presses will always turn on)
When screen is on, power long-pressing is prevented
Option to automatically disable/restore lockout
When connected to USB
When connected to a defined safe WiFi SSID
Adjustable delay before relocking after the screen goes off
Tamper evident mode will flash the front LED when any attempt has been made to turn the screen on
Optionally block all LED activity while locked (to help give the appearance of a dead phone)
Optionally disables itself while on a call, then immediately relocks when hung up
Optional automatic home button press (so you always unlock to your home screen)
Optional delayed blackout restoration (when used with the automatic home button feature, this is so no one will see what app is in the foreground the instant your screen turns on)
Can automatically unlock for Touchwake
Option to coexist with Slide2Wake, Arc2Wake, Pull2Wake
Stem Gestures
A series of versatile touch gestures that are specially designed to be unintrusive. By existing within the kernel, the Stem engine is capable of blocking and restoring input events, allowing the gestures to be triggered and used without interfering with normal device usage. This iteration is a hybrid of previous Plasma kernel features "Arc2Wake" and "HomeUp".
Supported by Automatic Media Mode
Works in deep sleep
20+ customizable payloads delivered via VirtualKey engine
Tap2Repeat repeats last action when finger is lifted then put back down in the same place
Equal for right or left handed people
Gestures (some can have different screen-off and screen-on payloads)
High Left
High Right
Low Left
Low Right
Side Up Left
Side Up Right
Arc Spike Left
Arc Spike Right
Center Spike High
Center Spike Low
Center Spike Bottom
MultiButton
When enabled, pressing different combinations of buttons will yield up to 6 different payloads. This iteration is a version of the previous Plasma kernel feature the "Volume MultiKey."
16 customizable payloads delivered via VirtualKey engine
Combinations (each can have different screen-off and screen-on payloads)
Volume Up + Volume Down
Volume Down + Volume Up
Volume Up + Power
Volume Down + Power
Volume Up + Home
Volume Down + Home
Long-Press Mode
Supported by Automatic Media Mode
Combinations (each can have different screen-off and screen-on payloads)
Long-press Volume Up
Long-press Volume Down
Automatic Media Mode
Detects when music is playing, and overrides certain payloads with music-oriented ones instead (volume, track control, play/pause)
Allows for altered parameters in ZZMoove to prevent skipping, include when recording audio
Userspace Booster
Provides small boosts for common things, like the keyboard opening, files being transferred, incoming calls, packages being installed or updated, etc.
Adjustable frequency and core count boosts for:
New app starting
Scrolling in a list
Activity changes
Progress bar being shown (KitKat only)
S-Pen
Adjustable minimum pressure to help prevent errant input, especially when doing things like crossing t's or dotting i's.
Adjustable fixed pressure to effectively disable actual pressure input, to make writing easier for some people.
WorryFree mode that always disables the touchscreen and touchkeys while the S-Pen is out.
GPU
Adjustable minimum frequency while interacting
Adjustable minimum frequency while plugged-in
Nightmode
A very fast home button double-press will toggle nightmode (red screen)
Synapse
Set DPI to 640/480/320
Built-in support to apply the surround sound hack at 3 volume levels: stock, medium and loud
Changelog
v.1.00
Initial release
Installation
Download
Flash via recovery
Reboot
Optional: Install Synapse
Download
Plasma kernel 1.00 for Sprint Note 4 - KitKat (4.4.4)
Plasma kernel 1.00 for Sprint Note 4 - Lollipop (5.0.1)
Until I update this post, please see my replies in this thread for the latest versions (1.21 for CM-13, 1.20 for CM-12.1, and 1.17 for TouchWiz)
Known Issues
Lollipop (5.1.x)
Surround Sound mod untested
Donations
Developing Plasma kernel takes an enormous amount of time and effort. Features like MultiButton, PlasmaUnlock, and the Stem Gestures represent hundreds upon hundreds of hours of planning, testing, development, more testing, squashing bugs, and even more testing. If the functionality they offered were apps, each would be worth a few dollars in the store. But alas, they are merely free. If you find my work useful, consider helping your starving developer out and make a donation - it would be GREATLY appreciated! However, if you do, please understand that donations are reciprocation for all this existing work, and are not guarantees of support. It's not because I'm mean, it's because like all the other developers here, I do this in my free time, and sadly that is a very finite resource
Donate!.
Credits
LoungeKatt (TwistedUmbrella), ZaneZam, AndreiLux, Faux123, Franciscofranco, Friedrich420, savoca, Yank555.lu, and many others.
A special thank you to bjrmd and everyone else who has helped test and support Plasma kernel on the Note 4
.
Source
Source code can be found on my github.
XDA:DevDB Information
Plasma kernel, Kernel for the Sprint Samsung Galaxy Note 4
Contributors
ffolkes
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: 1.00
Stable Release Date: 2015-06-18
Created 2015-06-18
Last Updated 2015-11-25
Great to see you back, looking forward to trying it out!
Awsome great to see that you got this working with lp cant wait...
Sent from my SM-N910P using Tapatalk
Oe1 or ob7 fingers crosses
pbedard said:
Oe1 or ob7 fingers crosses
Click to expand...
Click to collapse
Works on my oe1!
Perfect for me- ob7--thanks.
Looking forward to the AOSP one for sure
Working well here on LP. Only issue I'm having, and I had it on the KK version as well and forgot to mention, is with smart stay. Proximity sensor isn't keeping the screen on like it should when looking at screen. Working on stock kernel, and another kernel I tried. Anyone else? Thanks for the update! I sure missed all the features of this kernel.
Sent from my SM-N910P using Tapatalk
Whats the securty thing always going off
See here
egodriver07 said:
Working well here on LP. Only issue I'm having, and I had it on the KK version as well and forgot to mention, is with smart stay. Proximity sensor isn't keeping the screen on like it should when looking at screen. Working on stock kernel, and another kernel I tried. Anyone else? Thanks for the update! I sure missed all the features of this kernel.
Click to expand...
Click to collapse
I've never used smart stay, but I will give it a try and see what's going on.
pbedard said:
See here
Click to expand...
Click to collapse
That is really weird. What ROM are you using? I've been using HybridX for KK and Notarized for LP and I have never seen a dialog like that before. When does it happen? When using Synapse?
Synapse never installed and im using the 0e1 stock rom
I am loving this kernel great job.
The settings inside synapse for this kernel is amazing. I had an antutu score around 40 but I'm sure that can be fixed once I get the hang of setting this up
OK, I love this kernal. The amount of options and tweaks are unbelievable. I loved this kernal on my note II and was disappointed when it fizzled out at 4.1.2
I have an issue with this build though. For some reason zzmove has never given me good results. It is good for battery life, but performance is bad. I could not find a good balance for this govenor on my Note II (AT&T) and my Note 4 doesn't like it either. I have tried many different variations of zzmove to no avail. It's a deal breaker on my phone.
Would you be absolutely opposed to using other govenors? Intelliactive and Alucard have worked the best for my phone (trltespr). Blueactive and Interactive Pro have also been popular on this device. Your choice of schedulers is great
Your work is much appriciated :thumbup:
Zzmove is giving me music skips while the screen is off. Anyone know what setup u should use to stop it
thatdudeaaron said:
Zzmove is giving me music skips while the screen is off. Anyone know what setup u should use to stop it
Click to expand...
Click to collapse
zmove scaling page---freq limit while screen off-- set to 2649
max freq while screen off and music plays--2649
min freq while screen off and music on--576
zmove hotplug page--max core while screen off--change to 2
my problem is that the music detection algorithm is not very accurate, so the "freq limit while screen off" is the setting that saves me.
TY
Kernel breaks proximity sensor for me. Running stick oe1 ROM. Any fix to this?
Oh well music still skips on zmoove governor
V12 turbo charged - Good Job ffolkes
Buckle Up Folks long post coming through.
For those that just want to get strait to the point Skip down to the Bold “Tweaking the governor” section.
This kernel has changed my opinion on what is possible with the note 4 from a fluidity stand point. I always thought that androids weakest points was scrolling performance, general fluidity, and speed, but this kernel along with the Noterized Rom with the Next Launcher 3d shell on top, makes my brothers iphone 6 plus seem sluggish.
I’ve been playing around with the lollipop version of this kernel before ffolkes officially released it (since version 18 and 18a). From my experiences with it, I have discovered the same thing that some of you have probably noticed: if left un-configured, it is painfully sluggish in some aspects but battery life is fantastic.
Unlike a lot of other kernels out there, I don’t believe that this kernel was meant to be left alone (ffolkes, please fee free to correct me if I am wrong on anything written in this post. This is your baby afterall, I am not the artist here). Honestly, there are so many options to tinker with, that it would be shame to simply leave it alone. This baby is a v12, turbo charged monster with a hidden Nitrous boost button just waiting to be pushed.
Some have asked for settings, So I am going to do my best share with you my experiences with tweaking this kernel thus far. Hopefully it will help someone.
A quick disclaimer with reference to my usage habits: I like to Glide. For me, my phone has to feel like the content on the screen is like a puck on an air hockey table or a hovercraft on water. I want no hard stops, as little friction as possible. I am obsessed with flicking things around on my screen and watching it glide to a slow, almost un-inhibited stop. The longer the glide the happier I am. My finger does not stay on the screen for more than half a second but If I do a full flick the content does not stop until 3 to 4 seconds later and it always a slow, gradual descent with no stutter or lag.
To achieve the above effect , 2 things need to happen. The application you are using has to be properly coded and configured, and the kernels governor needs to be tweaked.
Tweaking the applications:
Through my testing, I have found what I feel is a direct relationship between the applications dpi setting and scrolling/panning smoothness. How long it takes items to come to a stop after being panned or scrolled with a flick, seems to be directly related to the dpi. The lower the dpi, the longer the glide. I have narrowed my preference to three specific dpi settings:
345 – My personal favorite – you could set the entire rom dpi to this and get tablet mode for most apps and the text is still legible(to me), I could use this without exposed though you will have to user a different dialer and camera app due scaling issues.
380 – Text is much more legible (most will prefer this mode) and apps also tend to behave with much less stutter.
430 – Good Performance, Text is super legible but not to big but the air hockey glide effect only last about half a second.
Tweaking the governor:
Lets start with the touch-bootster
Sampling rate = 60000
Input Boost Punch Minimum Cores = 4
Input Boost Punch Frequency = 2649
Input boost Punch Cycles = 50
Input boost Up Threshold = 20%
Punch on Every Initial touch = enabled
Punch on All Touch Movements = enabled,
Punch on all S-Pen Movement = enabled,
Level 1 Batter Threshold & Master Switch = Disabled
For most, the above settings alone will remove almost all lag if you are using Noterized Rom or a Variant that uses it as a base ie Hybrid X (heck of a job also tx_dbs_tx). Just to let you know, with these settings, I can get 5 hours of web browsing along with and additional 40 to 60 minutes of web video streaming. If your video content is from the youtube or Netflix app, I can almost double the video streaming time when using Netflix, and almost triple it for google Youtube. I've gotten close to 8 hours of total onscreen time, even when pushing the touch-booster really hard with the above changes only.
To further squash out any lag related to general application load, change the following:
Down threshold While Screen On = 11%
Up Threshold while Screen On = 12%
Smooth Up threshold while screen on = 15%
Fast Scaling Up While Screen On = 4 Steps
Scale Blocking Cycles = Disabled
Scale Up Blocking = Disabled
By now if you still have lag then issue is either application specific, ROM specific, incorrect user settings or failed hardware. But if you still need more power and you don’t want an application to even think about stuttering, then go over to the zzmove hotplug page and change the following
*****Delays*****
Block Up Logic Cycles = Disabled
Stagger Up = unchecked
Block Down cycles = 5 cycles
Stagger Down = checked
*****CPU Core 2****
Up Block Multiplier = 0x(No delay)
Down Block Multiplier = 10x
Up Threshold = 10%
Down Threshold = 9%
Up Frequency Threshold = 422 MHz
Down Frequency Threshold = 345 MHz
*****CPU Core 3****
Up Block Multiplier = 0x(No delay)
Down Block Multiplier = 5x
Up Threshold = 15%
Down Threshold = 14%
Up Frequency Threshold = 652 MHz
Down Frequency Threshold = 576 MHz
*****CPU Core 4****
Up Block Multiplier = 0x(No delay)
Down Block Multiplier = 10x
Up Threshold = 20%
Down Threshold = 19%
Up Frequency Threshold = 806 MHz
Down Frequency Threshold = 729 MHz
God I hope by this point your still not lagging but if you are there the usual kernel lever tweaks that
1. include things like are things like:
2. enabling Dynamic Fsync,
3. disabling Error Correction,
4. Upping the GPU touch boost to 500, (very important for Noterized Rom or other variants that are fully Hardware accelerated(gpu rending forced + hardware acceleration) This is one reason I believe this rom can sometimes eat into batter life pretty quickly.
5. Increasing GPU Laziness to 8
6. Reducting the GPU ramp Up Threshold down to 300
7. Zram, Low Memory Killer, Frandom and all the other settings have pretty good guides out there to tweak accordingly.
Battery Life:
Tweaking battery life has to be done methodically. It should be based on each individually usage habits and should take into account the apps running in the background and available memory (low memory killer and Swapness should help out with this also)
Choose and Good Test Application - To start with I would find and use a good Application validate if there is lag and or stutter. This app should not be one the pushes the note4 to its max limit all the time, unless it is the primary app you use on the phone. Testing with such in app will have you tweaking your system to maximum performance all the time. At that point you could simply leave the settings that I gave you earlier as is and skip the rest this these sections. Those setting will get you maximum performance out of your phone when you need to running your hard-line application and still provide 4 to 5 hours of no screen time when you don't. when tweaked ffolkes version of zzmove can get you on-demand performance governor performance without the wasted power. You could just also switch to the standard performance or on-demand governor.
For the rest of us, when it comes to scrolling I would highly Recommend UC Browser(Can’t Sing it’s praises enough). Don’t just download the latest version. Not all versions are equall when it comes to scrolling performance and lag. I will include an APK in the post or link to their historical archives. There are three that I would recommend:
build dated 01/27/2015 - It is a web page eater. It is quick light and is stutter free if you are using a lollipop rom Based on Noterized. If on Kit-Kat it is not as smooth as the version listed below but still better than chrome, firefox or the Samsung browser, the new versions of dolphin might come close but still a distant second in scrolling performance.
build dated 06/04/2015 - about 5 to 10% slower on than the one above for java script performance but man is scrolling smooth on Noterized. If you guys remember the Old webkit browser on android 4.2.2, This one out does it and makes my brother want know how to get his iphone 6 to work like my Note 4 when it comes to website loading and smoothness. This version also has UC excellent Night mode with transparent background that makes things look even smoother when using dark themed wallpaper and has the added bonus of extending the notes battery life significantly. Keep in mind to achieve this performance, for me takes 345 dpi. 380 and 420 aren't bad either.
build dated 05/15/2015 - honorable mention goes to this build for its superb memory management. No crashes, hangs or forecloses with a variety of content for 2 weeks straight. remains snappy even though phone was never rebooted and memory never cleared. Was my go to until I started us plasma on lollipop and saw that I could have the best of both worlds and went back to the 01/27/build. the bruit force of the input booster will make anything that has a remote chance of being smooth, glide like butter.
The uc browser archives:
http://wap.ucweb.com/verlist/english_354/ucbrowser/145?uc_param_str=vepffrbiupla&from=U3-help&plang=
If using a web browser to determine lag and smoothness Desktop Mode mandatory for UC and the following Web Pages:
Yahoo.com – Stutter city because of the continuous loading of content ( you have to scroll for a good while, but once enough content has loaded you will see the limits of your browsers memory handling and allocation. This could also be a good benchmark for your io scheduler , and tcp congestion algorithm of choice.
Youtube.com – Same as above but content is heavier. Good test due to the fact that it will show you when you are not properly optimized, but reward you greatly if you are. You are either in the gutter or you’ve hit a strike.
Espn.com-Highly optimized well written code and template, should be smooth even though the content containers may load slowly. Again good test for tcp congestion. This site will also expose the performance delta between the 01/27 build of UC and the other builds mentioned.
Touch-Booster Battery Life - You need to tweak the touch booster settings to match how you interact with you screen. Some people flick there content always letting it glide and some people keep their fingers on the screen until they get to where they want to go. This alone will change how you optimize the setting for the touch booster to maximize battery life.
Using me for example, the settings listed in the touch-booster tweaks was custom tailored to me. Most of the time, I use my phone for web browsing, reading pdf files, and emails. As stated earlier, to interact with content on my screen, I flick on my screen and expect content to glide for as long as possible. On average, in UC browser (my browser of choice and the smoothest out there for scrolling performance) , even a light flick will last 1 to 2 seconds and if I flick content quickly enough, the content could glide along the screen for as long as 3 full seconds. Therefore I need my Input Punch boost to last 3 seconds just in case.
If My sampling rate is 60ms for the above stated situation, I need 50 cycles(Input boost Punch Cycles ) of the 60ms sampling rate to give me a total cycle time of 3,000ms, which of course we all know equals my 3 seconds. If I am someone who keeps my fingers the screen and rarely flicks then that’s a lot of wasted power for absolutely no reason at all.
To tweak touch-booster for , start with the settings I gave in the first section and reduce “Input Boost Punch Frequency ” until you begin to notice your first hint of lag on the above pages. One you experience lag increase the frequency by 2 steps from that point. Now reduce the number of active cores until you get lag again. Once you get lag, increase the core count by 1. Finally, decrease the power usage caused by the sampling rate by increasing the time between intervals by 5ms at a time. So from 60 to 65, then to 70. Once things start to lag, decrease the interval by 10ms
GPU Battery Life - In addition to the cpu touch-booster tweaks, flokes was even nice enough to include input based boosters for the gpu(freaking awesome by the way dude). He gave us the ability to under-clock the gpu to 166 when not in use (fingers off the screen) but giving us power for 1.5 seconds(hope this duration is tweakable in the future) of up to 800mhz. This is important for a Rom Like Notarized where gpu is doing most of the work all of time. The gpu is in use even for traditionally lite loads such as 2d work. I would recommend lowering the min frequency all the way down to 166 and capping the gpu somewhere between 266 to 300 if you are like and don't game much. if you get lag or stutter/jitter then increase the frequency one step at a time until the lag disappears from your application. You will get so much more mileage from steaming video like Netflix. The Adreno 420 is powerful enough to handle light loads without flexing its muscle, but will flex it anyways if not kept in check.
General Applications Performance and Battery Life - First you need to tweak the main up and down thresh hold for cpu load:
1. Increase the “Up Threshold while Screen On” by 10 until you notice your hint of lag in your application. 2. Once you noticed the lag or stutter decrease the “Up Threshold while Screen On” by units of 2% points until lag goes away.
3. Once you found you optimal number, increase the “Down Threshold while Screen On” number to a number 10 less than the “Up Threshold while Screen On”.
You can follow the same procedure listed above for the hot plug algorithm, Tweaking each individual cores up and down thresholds starting with core number 4. Once optimal threshold is set for core 4, test core 3 in the same manner then core 2. Once thresholds have been optimized, starting with the 4th increase the “Up Frequency Threshold” until you notice lag in your application. One you hit the lag frequency decrease your frequency step by 2 levels and then move on to the next core doing the same thing.
After achieving the optimal hot-plug and frequency thresholds for each core. You can then begin to explore power saving by adjusting the up and Down delays. Starting with Core 4 and working your way down, decrease “Down Block Multiplier ” in increments of 1 until lag is achieved. If no lag is achieved after getting to zero. Then your usage pattern is not effected by this and you can simply disable this feature for that core.
Normally I would not recommend introducing lag but from a power saving standpoint it also might be to your advantage to increase the “Up Block Multiplier ”. Starting with core 4 increase the number slowly until you begin to notice lag with you usage pattern. Do this for each core until you fine the optimal multiplier.
Other Power Tweaks – In my opinion remaining power tweaks can be done without effecting usage by much:
1. Sampling Rate Idle = 500ms – Decrease the number if you notice lag when try to interact with an application after having you finger off the screen for a while. I am not sure but I believe the input booster engine relies on this setting since it does not have a setting listed for poling in the governor(ffolkes correct me if I am wrong). If you notice that applications work great when you touch the screen and poorly when you don’t, you need to decrease the “Sampling Rate Idle Threshold(Frequency)” and/or “Sampling Rate Idle Threshold(load)” until its gone.
2. Sampling Rate Multiplier While Screen Off = 8x – The higher this number, the bigger the sampling interval when the screen is off. I love this feature. It’s given be great talk and music playback time when the screen is off. I don’t do it very much, but if I remember correctly I was getting less then 1 percent battery loss for an hours call with my sister(yeah she’s a talker).
Lastly, In my opinion, a good experience on the phone comes down to three pillars. The Rom it’s running on, the kernel, the Launcher, and then the Web browser. You already know about The Rom (Notarized), The Kernel(Plasma), and the browser Being UC browser. What I have not told you about is the Launcher. If you guys have not Tried Next Launcher 3D. Take it for a spin. If is not only full accelerated but it is full optimized for battery life. Even before I was using Plasma and the touch-booster. It was the only part of my note 4 I had never seen lag. The screen shot look Gimicky but when tweaked to your taste it can do a flat design like the other launchers with all the widgets and icon packs. The only difference is it does not slow down and does not eat your battery. Also no FC's. I am a stickler for smooth and this Launcher with Plasma and Notarized just plane burns.
Told you this was going to belong, but I am done. I would like to finish by Thanking Ffolkes for his hard work. This is not copy and past code folks. I have not even gotten talk about the rest of the settings in this thing like the gestures, multi-button and so on. This guy toils to bring a lot of these things to us. He's not just waiting for linux versions to do his releases. Considering the open source nature of android, I can’t state for sure that this is all his engineering but it sure looks like it. You tell me if you’ve seen this type of attention to detail and code command, in any other kernel. It’s not just him though I think SaintZ93 deserves more than a round of applause for fundamentally changing the base for all or our roms for the better. If Norterized is now base for our custom roms and I will accept no Less than Plasma for the kernel(People will, emulate, wait and see), Then the future looks Golden. Donate people. Think of it as taking the guy out to McDonald’s or for a pint of Beer and some fry’s. We all know he deserves at least that. Hope I am not breaking some type XDA rule with the length of this post.
Related
What setting do you guys change that effects battery power the most?
Luke
lukesdiesel said:
What setting do you guys change that effects battery power the most?
Luke
Click to expand...
Click to collapse
Hands down, screen brightness. Nothing comes close to eating power like the screen.
Anyone see a big difference if u turn off vibrate when texting?
Luke
lukesdiesel said:
Anyone see a big difference if u turn off vibrate when texting?
Luke
Click to expand...
Click to collapse
No, but assisted dialing, tell htc, phone finder, and backup assistance drain a ton of batt, just to name a few
Sent from my TBolt using my f***king thumbs...
here is what i do:
turn down brightness (have it ALL the way down at night)
disable GPS (unless i curently need it on)
disable Auto-Sync
disable Background Data (unless i need to use Market)
disable All Animations
use Silent Mode (with all vibration turned off)
disable Phone Locator
disable LED Notifications
disable Fast Boot(if on a Sense rom)
also, i use a program called "Bloat Freezer" (it's 99 cents on Market) to freeze any extra apps that i don't need or want running.
lastly, if i find myself using a Sense ROM for whatever reason, i use "Launcher Pro" and have Bloat Freezer freeze all Sense stuff
To list, in order, the devices and functions that eat the most power inside a Tbolt:
The screen, just being on makes it number one. The radios, especially the LTE radio under heavy use and the CDMA radio at cell edges. The CPU, especially during lengthy write cycles to any NAND device such as the SDcard or eMMC. NAND memory, because it uses higher voltages than RAM to read and write, and takes more time. GPS, because it's a relatively high gain antenna that requires high quality class a signal amplification.
The display isn't anything you're ever going to get around. The radios can be managed through appropriate syncing schedules and avoid resource abuse apps that pointlessly hunt for data. The CPU is best managed with a well built kernel using a sysfs interface that allows custom voltages, choices of scaling governors, and parameter alterations to that scaling governor, as well as conservative garbage collection to keep memory resources as completely used as possible. NAND reads and writes can be kept to a minimum maximized through avoiding app killers, garbage apps such as system resource management apps, zip aligning your ROM, and running an IO scheduler at least as good as Deadline (most kernels do this by default, but some mods attempt to change this). GPS, contrary to the popular myth, is ONLY used when an app summons it's use. Some apps and widgets will abuse this feature and will seek a GPS lock a dozen times an hour or more.
ANY moving electronic part eats power, like vibration motors or speakers. Sound effects less so, but still, that's a a relatively large lump of power being used, and that also calls for the amplifier to be active and eating power.
Using my device as I please, without sacrificing features, usability or constant LTE connectivity, and implementing the theories above as best as I know how to do, I can run my phone OC'd to 1.57GHz for 12 to 14 hours consistently as a moderately heavy user, using nothing more than the stock battery which currently registers all of 1367 mAh's.
So before I got my MoPho I had been using a Hero for over two years, and the one tweak I found to be completely necessary was the Collin_ph Batter Tweak. If you never tried it, here's the basics:
What does it do?
This tweak creates a service that periodically checks the phone's power source.
If the power source changes, it reconfigures the device for maximum performace, battery and safety.
Tweaks compcache (if enabled) for current power source
Tweaks memory settings for current power source
Re-clocks CPU based upon battery remaining or current power source
Reclocks for maximum performance if on AC power
Reclocks for maximum performance and charging safety if on USB
Reclocks for performance and battery if on Battery
As Battery life is diminished, Maximum CPU frequency is lowered
Tweaks scaling charactaristics depending on power sourcee
CPU Scales up less frequently on battery power
CPU Scales up more frequently on USB/AC power
The CPU is allowed to scale dynamically in all charging states based upon CPU usage
Includes a batt-cfg utility to configure the system
You may load 1 of 2 pre built profiles
Manually configure CPU Frequencies in all charging states
Determine the percentage of underclocking as the battery drains
Configure how often to poll the power state / battery statys
Disable batt.sh service from running at startup
Includes a batt-rm.sh uninstall utility
Includes a batt-diag diagnostic utility
Includes an LED fix if your LED is stuck on
Includes optional experimental performance tweaks (disabled by default)
Includes optional Disk performance tweaks (enabled by default)
Includes optional froyo Audio quality fix (disables stagefright)
How does it do this?
The batt.sh service runs perodically to detect the power source through the kernel. When the service detects a change, it makes temporary changes to kernal run-time parameters. When you reboot, all changes are lost, however, if the batt,sh service is not disabled or uninstalled, upon startup, it will restore the settings.
If you're really interested, just look at the /system/bin/batt.sh script for all the gory details.
The service is started in /system/etc/init.local.rc
Click to expand...
Click to collapse
I really miss the ability to run a higher mhz when I'm plugged in, and lower my mhz when my battery is low or my phone is too hot. And as a service, there wasn't an app running at all times.
So my question is, is there anything like this out there for our photons? If not, how hard would it be to port (I have zero programming experience), since it looks like it's been ported to a number of other phones?
SetCPU profiles can do some of that, lower/higher clock speeds when battery hits X percent, the clock speeds for temps, the clock speed for charging(AC and DC), for when screens off, in call, etc.
I made a lot of experiments trying to squeeze most of my GT-I8552 battery & RAM, and finally I reached those results by the below strategy (please note that this will be just strategy/tips, not detailed steps), and on ROOTED STOCK ROM It currently gives me:
1) Average Screen Off Discharging Speed 0.3-0.5%\hour (so battery needs 200 hours to discharge, or more than a week!)
2) Average Screen On Discharging Speed Between 10%-20%\hour (no Gaming) (so working hours about 8-7 hours)
3) Free RAM after full startup 65%.
(I gathered those statistics by setting Tasker to calculate them for me).
Battery Tips:
So to see almost a perfectly horizontal line of your battery discharge during your sleeping, you will need:
1) Rooted Stock ROM (I tried this on KitKat latest version).
2) Greenify.
3) Tasker
4) Your brain and some work.
OK to get most of the battery, do the following:
Remove all LG & Google Bloat ware; search XDA how to do that.
Disable all animations in you Settings-> Accessibility, this will save our battery and make apps faster.
Now all of the work should be done in Tasker, I assume that you already know how to work in this thing, if not search XDA there is a lot of tutorials...
Once your screen is off, do the following in Tasker:
Turn off the following : WIFI, Bluetooth, GPS, Auto Sync.
Greenify all bad behaving apps, after that use tasker to force close many of the bad behaved one (you should experiment with this).
Down Clock your CPU, for some reason my device reboots unless I set Governor to conservative or onDeman, so here we put it on conservative, with CPU clock between 300 and 652 MHz, there is no need to make it lower, because it gives no better battery life, and it makes wake up time longer.
Those steps are enough to make sure that you will lose about 0.5% per hour only! (my CPU needs about 5-10 minutes to enter deepsleep, this means that your battery drain during this time will more than 0.5%)
On screen ON, you need to immediately set back your CPU to onDemand mode, otherwise it will lag, actually I made 3 profiles for CPU, low (during screen of), medium (when screen on), and high (during gaming), so here I set the OnDemand with frequency 300-1190 MHz, and you will not notice any lag with those settings, also you need to set the maximum priority for the Tasker profile that will do this, well actually I made my own Lock Screen by Tasker screen so that tasker will stay foreground app and has best CPU priority, so swapping CPU profiles will be quite fast and you will see no Lag.
Also I set a periodic sync, when screen off each hour my phone wake ups and turning on wifi (or 3G if I’m out) and turning on AutoSync for couple minutes, and then turn all those things again to enter DeepSleep (step 1).
you need to make a good Screen brightness management in Tasker, there is tutorials on line for that.
Finally, during working, I set many specialized profiles for different apps I use a lot, for example, you don't need AutoSync when you are talking by phone, or reading a book, also when reading books, you don't need high CPU frequency, so I lowering it down, all this tweaks needs some work, but anyway you it will give you considerable battery gain, and you will see that the application that you really using a lot are not more than 10 apps.
I would like to note that I tried many ways to optimize this (except trying different ROMs) like playing with application's wake locks, but nothing worked as good as this strategy for me, if you have some more suggestions it will be great.
RAM Tips:
Many of us trying to make our phones customized and more beautiful, but after a lot of tries I found that all those things only making things worse, even for a monster like LG G2: I tried almost 99% of Launchers available on store, and all of them are very bad in scene of resource usage, for example the most beloved Go Launcher, having 200+ apps, and 3 pages of widgets, uses about 150 Mb. of RAM, this is too much, considering that android itself using about 200Mb. in worst scenarios, even the launchers that claims to be very efficient like Lightning & ssLauncher, that is not true, because once you install them, they indeed use too little at the beginning, but once you customize them and will add widgets, objects to them, they will jump up to 100Mb., well this still is better anyway than Go Launcher.
So to be short, the best one in terms of memory usage, is definitely, and without any competition, is Smart Launcher, it seems that it has a unique possibility to draw/load the widgets on demand (you can add them on special pages) and once you go back to main screen, it will free up used memory in minutes, that's really great, because this launcher on average uses only 50Mb. whatever the widgets you use!!
Also I would like to note that most Lock screens are very memory hungry, I tried lot of them, and none of them used less than 40Mb.!! so it almost like a second launcher! even the best of them like widget Locker or C-Locker! that why I made my own by Tasker itself, but note that after designing a scene in Tasker, it will use a lot of memory (70-80Mb.), and for some reason doesn’t free it unless you restart Tasker, and fortunately after that it will use not more than 20-30Mb. even when the scene is visible! so considering other things Tasker is doing, it's pretty low! so I highly recommend this.
Also any programs like recent app's viewers, side bars, screen buttons etc.. are also very memory hungry, I tried a lot and none of them really efficient, don't dream to get one with less of 50Mb. usage! so it's better, in my tests, "on screen buttons" are the best one with about 10-15 Mb. usage in case you don't like the navigation bar as me))
Dear Axit,
Where did you get the stock kitkat rom for GT-I8552.
Sent from my GT-I8552 using Tapatalk
devesh9 said:
Dear Axit,
Where did you get the stock kitkat rom for GT-I8552.
Sent from my GT-I8552 using Tapatalk
Click to expand...
Click to collapse
Not KitKat..wrote that by mistake..:silly:
ohk
it looks good
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