Keep meaning to ask this and keep forgetting. My Prime goes into Balance Mode automatically throughout the day, and I assume it's a battery saving feature. Is there a way to prevent this from happening and keep it in Performance mode always?
not really. its like that by default. if you rooted, what you could do is install Ezoverclock app from developement section. this will give you an overclock. it changes your Asus power settings. with this app. your performance mode will be 1.6Ghz. your balanced mode will be 1.3Ghz(Asus stock performance mode), and power savings stay the same at 1Ghz. you can also change the values for each mode if you wish. all you have to do is install this app, if rooted, and that's its. now your default balanced mode will be 1.3Ghz instead of Asus stock 1.2Ghz. works very well and simple to install and use.
czerdrill said:
Keep meaning to ask this and keep forgetting. My Prime goes into Balance Mode automatically throughout the day, and I assume it's a battery saving feature. Is there a way to prevent this from happening and keep it in Performance mode always?
Click to expand...
Click to collapse
This isn't a battery saving feature--your prime is most likely rebooting when you aren't using it, and when it resets it returns the power settings to balanced (default). Hopefully they will fix the reboots for good before long
demandarin said:
not really. its like that by default. if you rooted, what you could do is install Ezoverclock app from developement section. this will give you an overclock. it changes your Asus power settings. with this app. your performance mode will be 1.6Ghz. your balanced mode will be 1.3Ghz(Asus stock performance mode), and power savings stay the same at 1Ghz. you can also change the values for each mode if you wish. all you have to do is install this app, if rooted, and that's its. now your default balanced mode will be 1.3Ghz instead of Asus stock 1.2Ghz. works very well and simple to install and use.
Click to expand...
Click to collapse
Thanks, so if i have it on 1.3 the screen will be crisp like it is in performance mode, even though it's on balanced?
redandblack1287 said:
This isn't a battery saving feature--your prime is most likely rebooting when you aren't using it, and when it resets it returns the power settings to balanced (default). Hopefully they will fix the reboots for good before long
Click to expand...
Click to collapse
True, thats most probably the issue
czerdrill said:
Thanks, so if i have it on 1.3 the screen will be crisp like it is in performance mode, even though it's on balanced?
True, thats most probably the issue
Click to expand...
Click to collapse
on Asus stock, the screen is crisp on balanced and performance mode. its only on power savings where it decreases the screen quality. but yes, with root and Ezoverclock you can set balanced to 1.3Ghz. actually its set to that by default. so if the device ever reboots or whatever, it'll still be on 1.3Ghz. with that app performance mode is now 1.6Ghz. unless you change it to 1.5Ghz or something. its customisable to what ever you want Asus stock power mode settings to be.
Hi, all!
Some people, like me, may have downloaded a cpu-monitor app like System Tuner then notice their second cpu (cpu1) always appears offline.
First off, I recently realized that that is often inacurate. Using another app like SystemPanel would show both cpus being online, and more importantly, checking sys/devices/system/cpu/cpu1/online would show it's "1" indicating online. Many cpu app's inability to read cpu1's info is because "cpufreq" folder is missing from cpu1 folder (if you check cpu0's cpufreq folder it's always there).
K, now also, some poeple like me, thought cpu1 was really offline, and used System Tuner's "Force all cpus online" option, and viola, after reboot the second cpu showed up. But why? Cuz a "cpufreq" folder is found in cpu1 again.
What is interesting is both files "affected_cpus" and "related_cpus" would show "0 1" meaning core 0 and core 1 are in sync and both coordinated simultaneously. if you change settings(freq,governor,etc) for one core it automatically changes the other.
Now here's the tricky part, however after the tablet goes to sleep, when I wake it, cpu1's "cpufreq" folder would disappear again, meaning Sytem Tuner would show cpu1 agains as "offline". But if you chekc "online" file in folder you'll see it's still online ("1") and SystemPanes still shows cpu1 activity. However "affected_cpus" and "realated_cpus" will show only "0" meaning only cpu 0 is in this categoty and cores are no longer in sync.
Conclusion: so far what I deduced is my tablet in its default state has both cores online, but are off-sync. After turning on "Force all cpus online" and rebooting, they are both online and in-sync. After the device goes to sleep and wake, the two cores are still online but now off-sync.
The important thing about this investigation is how much it affects 3D performance. I was always confused why my device lags with a aged-game like Counter Strike portable but is perfectly smooth in a consol-quality game like Mass Effect Infiltrator. My current thought is Mass Effect acttively tweaks your cpu while most other games leave cpus as they are.
Benchmarking (using market benchmark apps):
(First off, the FPS difference may seem small but in running the actual games for some reason it made a enormous difference, often the difference between crashing and not crashing/playable or unplayable in Nova3/Shadowgun)
Default, newly flashed rom: FPS :33 (Some games fail to load graphics properly for some unknown reason)
Turn on "Force all cpus online" with Sys Tuner: FPS 39-40 (All games are silky smooth, no errors, tablet temp hotter)
"Force cpus online", then after wake from sleep: FPS: 33-34 (not as smooth before sleep, but games generally load properly)
**Switching my cpu0 gonernor to the same governor I think cpu1 is using: FPS 35-37 (no errors, almost as smooth as "Force cpus online")
Here's a crappy surprise --Cpu1 off (turn off dual core): FPS: 39. (Completely smooth, zero errors, hottest tablet temp)
**after cpufreq folder disappears from cpu1 I cannot be sure which governor cpu1 is using, but checked with Kernel Tuner and believe the system switch it back to "performance2" which is a governor foudn in my tablet.(it it not like "performance" governor) upthresh 60 downthresh 30 freqstep 5.
Conclusion:
This leads me to the conclusion that having both cpus online does not necessarily improve performance, but if the two cpus are off-sync it definitely BUTCHERS performance. It does so so badly that running one core is actually better. Having both cores run the same governor also seems to help somewhat.
Need help:
I hope the info so far may helped some people, but the help I also really need is someone to tell me how are "affected_cpus" and "related_cpus" controled by the system? So far I had no sccucess modding their values and forcing cpus to "sync". I enter "0 1" but it doesn't go through. Since having the cpus in sync seems to give good performance and lower temp (single core was good but temp was noticeably high), I want my cpu cores to remain in sync, but currently it undoes the sync after waking from sleep. I need to understand how and why the system somtimes decides to coordinate both cpus synchronously so both cpus appear under "affected_cpus" and "related_cpus"?
Thanks to anyone for reading!
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.
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