Related
Are both cores working? Is there an app where I can monitor that? I use SetCPU and have it @ 1.5Ghz on-demand.
Thanks...
You can try CPU Guage from the market
Simple speedometer type guage, shows each core and if active
Both cores are operational in android roms, when needed. That is a fact.
With this app and ondemand setting, core two only kicks in if you exercise the screen quickly by switching between the cpu speed an temperature screens
There are probably other apps that will show the cores better
Good luck
In setCPU select info then CPU and it will show processor 0 and processor 1 but only when the core is been used so make sure something is running
MBQsnipers Guide to Kernel Knowledge
It lives again!
----
CPU Guide app:
Want this in app form? Lucky for you, I made one!
Get it here:
https://play.google.com/store/apps/details?id=com.kyler.mbq.mbqscpuguide&hl=en
----
CPUGuide website:
(If you're using it on a mobile browser, enable desktop mode).
http://CPUGuide.MBQonXDA.net
----
Contribute to the app!
It's always very appreciated. I also need translations.
https://github.com/MBQs-CPU-Guide/MBQs-CPU-Guide
---------------------------------------------------------------------------
Governors:
OnDemand:
Ondemand stands for that it scales up on load in frequency and then detects the load and scales back to a frequency which is fullfills the "demand" of the current load dynamically. (AndreiLux)
Interactive:
Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency. (AndreiLux)
InteractiveX(v2):
The same as Interactive, but when you turn your screen off it forces the second CPU core offline until the screen turns on again.
Performance:
Will constantly run at the highest set CPU speed.
Powersave:
Will constantly use your lowest set CPU speed.
Conservative:
Conservative means that it scales conservatively, not that it is conservative. It pretty much very similiar to Interactive in that it scales up and down in frequency steps. It actually can be one of the most aggressive governors out there. (AndreiLux)
Userspace:
Rare in the word of kernels. Typically not used for mobile phones. But what it basically does is, it runs on whatever CPU speeds the user sets through an app.
Lagfree:
More aggressive kernel. It scales the CPU faster, reducing lag and performance, while maintaining decent battery life. Its main goal is to increase performance without reducing battery life.
Min Max:
Only uses your max screen on frequency, and your min screen on frequency.
Hotplug:
Based off of Ondemand. It allows a CPU to go offline with minimal usage. When you're sending messages, browsing settings, or other simple tasks, most likely one of your CPUs will be offline.
PegasusQ:
Samsungs Governor for multi-core phones. Based off of Ondemand. This kernel controls hotplugging as well.
Lazy:
This Governor doesn't scale as fast. It's really a lazy governor, it tends to stick in the same CPU frequency without changing as much. Which can be beneficial to your battery (if your CPU settings are conservative) or can reduce battery life (if your chosen frequencies are aggressive).
Nightmare:
A modified PegasusQ, less aggressive (Which means not as good performance-wise), and doesn't usually hotplug. It is good for a balance between performance and battery life. May prevent the 'Screen of death' as well, since it doesn't hotplug.
HotplugX:
Its basically a smarter Hotplug, to my knowledge, it shuts off the second core much faster, and is a little bit smarter with CPU scaling and power efficiency.
LulzActive:
Based off of the Smartass and Interactive governor(s), the newer version of this Governor gives more control to the user, and he CPU frequency parameters (Ask for a description if you need one) are smarter. Smart at scaling both up and down.
Smartass:
Based off of the Interactive Governor, this is an older version, but this Governor is (or was) one of the smartest Governors, and is smart with performance and battery. More below.
SmartAssV2:
A re-thought version of the original Governor. This one aims for ideal frequencies, meaning it makes up its own frequences in order to meet the requests the CPU needs. Scales down the CPU extremely fast once the screen is turned off, meaning you will get amazing standby times. No upper limit for the CPU frequencies in both the screen on and screen off state(s). (If you want a better detailed explanation of that, please ask.)
Lionheart:
Conservative-based governor off of Samsung update3 source (Line copied directly from a guide, thank you 'Amal Das'), scales aggressively. This Governor is strictly for performance.
BrazilianWax:
Similar to smartassV2, the only real difference is, it scales more aggressively than SAv2 does, which reduces battery life, while improving performance.
SavagedZen:
Based off of SmartassV2, similar to BrazilianWax, but this Governor tends to favor battery over performance. From personal experience, I can say it does a great job of doing so.
Scary:
Conservative-based Governor with some smartass features. Ramps speed up one at a time, and ramps speed down one at a time (ask for description if you don't understand). Caps your screen off speed at 245MHz. Scales just like conservative would. This Governor is more for battery life than performance.
Sakuractive
A governor based off of hotplug and ondemand. The phone hotplugs (when it can) when the screen is on, and can be described as a 'hybrid' of hotplug and ondemand
OnDemandPlus
A governor based off of OnDemand and Interactive. It provides a balance between performance, and saving battery.
DynInteractive
A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.[/SIZE]
Advanced CPU Governor settings:
I got most of my information from this thread.
Sampling rate:
Microsecond intervals the governor polls for updates. Assists in the Governor determining whether or not to scale up or down in frequency.
Up threshold:
Defines the percentage from 1 to 100 (percent). Happens less often when clocked at a lower speed, overclocks when you get up into higher CPU frequencies. Using a Governor such as OnDemand prevents it from overclocking nearly 100% of the time.
Ignore nice load:
If you set the value to '1' the Android system will ignore 'nice' loads when the CPU Governor scales up or down.
'Nice' load:
When you turn a process into a 'nice' load, it prevents low activity processes randomly becoming high priority processes, which prevents lag. What a 'nice' load is, is how it handles processes. You can 'Re-Nice' processes, and re-set how processes are determined, based on your current processes that you have. Which helps eliminate lag due to processes being re-prioritized.
Frequency Step(s):
Determines how much the Governor will increase, or decrease, based on your CPU speeds. *This doesn't apply to some Governors
I/O schedulers:
Deadline:
Set to minimize starving of requests. In other words, it is designed to handle system requests as quickly as possible.
Noop:
It handles requests in a basic 'first in, first out' order. So any requests that come in, will also be the first to be executed.
SIO:
A mix between Noop and Deadline. Basic process/request merging. One of the most reliable schedulers out there.
BFQ:
Gives each request a time budget. If the request is not met by the time it is given, the request is skipped. Smarter than the CFQ governor.
CFQ:
'Completely Fair Queuing' scheduler. Scales its requests in an effort to insure smooth task handling. Attempts to give each request equal I/O bandwidth. Typically, lag happens with this scheduler due to the effort of competing tasks on the disk because it tries to give equal bandwidth amongst all requests.
FIOPS:
Relatively new. No I/O seek time, ( potentially better for performance), balanced read/write times, one of the smarter I/O schedulers
ROW:
Read Over Write. It will cause better read times for pictures/media, but when transferring data/installing apps, significant reduction of performance will be present.
V(R):
Best for benchmarks due to performance of requests, but is considered unstable due to random drops in performance. Semi-based off of the CFQ scheduler.
FIFO:
Takes each process in one by one, fair process queuing, balanced queue handling as well, processes go in and out in a numerical fashion.
TCP Congestion Avoidance Algorithms:
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Taho, but.. if 3 of the same packets are received, it will halve the window, instead of reducing it to one MSS. It changes the slow start threshold equal to that of the congestion window.
Vegas:
One of the smoothest (next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
CPU Governor recommendations:
Performance: Use Wheatley, or Performance.
Battery life: Use lagfree, Hotplug, PegasusQ, InteractiveX, or Sakuractive.
A fine balance: Use SmartassV2, Hotplug, or Sakuractive at less aggressive CPU frequencies.
Android tips:
Developer options:
Go to settings>build number... And tap 'build number' 7 times, go back, and you have now enabled developer options.
Force GPU rendering:
What it does is, it force enabled 2D drawing (such as scrolling, and anything non-game/app related) to the Graphical Processing Unit, instead of the Central Processing unit. What does/can this do? It has the potential to save battery life, and takes some of the load off of your CPU, which increases overall smoothness and reduces lag.
Keeping WiFi on during sleep:
What it does is, as this ^ suggests, keeps WiFi on while your phone is awake. To enable this, (and there are many ways.. I'll give you the way I'd do it.) Go to settings>WiFi>WiFi settings (3 vertical dots)>Advanced settings>keep WiFi on during sleep.. And set it to 'always' or.. You can use tricksterMOD and enable that via the GUI (Graphical User Interface)
WiFi Supplicant Scan Interval:
Before you freak out, I will give you what it means. What it means is this: how often your phone scans for a WiFi signal. Typically, it is 15 seconds. The recommended number is 300. To change it, you can typically find it in the build.prop manually edit it on your computer, or use an app such as ES file explorer and run it as root. Go to build.prop and look for: wifi.supplicant_scan_interval=x. And change x (usually 15) to 300, save, exit, and reboot. Please note it is not available with some ROMs that are driven towards a stock-ish feeling. Such as CM ROMs, or any derivative of that ROM.
Tips to get better battery life:
Turn off sync, location, Bluetooth when you're not using it, along with WiFi and data, don't use app-killer apps, lower CPU frequencies, and change your Governor to something less aggressive if you don't use it for heavy gaming.
Status bar with 1 finger, panel with 2:
If you want to access the tile settings quicker. Drag your status bar down with two fingers. If you want to bring down the status bar, touch the top of your screen and slide your finger down.[/I]
Autobrightness sucks!!:
Download an app called 'lux' and use that app. It'll take of any problems you're having, plus it'll save battery.
Changing your phones screen density:
In your build.prop, there is a line of code that looks like this: ro.sf.lcd_density=320, change it to 240 for a tablet-ish feel. Don't go under 160 though, you'll have endless bootloops
Change your bootanimation:
Go to system/media, you'll see bootanimation.zip, replace it with your desired bootanimation, change permissions to r-w-rr (read-write-read-read), and reboot. (Assuming you're doing this on your phone)
Block ads:
Download an app called 'adblock' on the play store, run it normally, accept the SU request, hit 'skip' and run the program, exit out, and reboot!
4x MSAA:
4 times MultiSample Anti-Aliasing. What this does is smooths out edges in apps that support AA. It makes your game look better, enhances graphics, but has the potential to degrade performance due to the screen enhancement. To enable this, go to settings>developer options>and check the box that says 'Force 4x MSAA'
zRAM:
Avoids disk paging, compresses your RAM. Disk paging means the way your phone saves temporary data. It helps with fragmentation of your disk and the physical space, which, over time, keeps speed stable and prevents any system slowdowns.
Explanation of TricksterMOD Settings:
General:
TCP:
Affects download speed
Scheduler:
How your system responds to, and handles tasks
Readahead:
How far ahead your internal SD caches when you put stuff on it
Frequency profile:
Save your frequencies
Min:
Minimum screen on time
Max:
^Opposite of minimum
Max screen off:
Max screen off frequency
Governor:
How your CPU essentially scales
Specific:
Wifi high performance:
Keep wifi on when the screen is off
Content adaptive brightness:
Better whites at low screen
Force fast charge:
Fast charge when your phone is hooked up to your PC/whatever
Group task:
Equally distribute loads amongst the CPUs
High performance sound:
Better sound
Headphone volume boost:
Boost the headphone volume for louder audio
Touch wake:
Touch your phone after you turn the screen off, and itll turn it back on
Vibrator strength:
Set the strength of the vibration of your phone
FSYNC:
When disabled, provides faster writing (not reading) of files with the risk of data loss if the phone crashes or is shut down improperly. (Thanks renaud)
Temperature limit:
How high your phones temperature can get before your phone reacts
Temp. throttle:
Enable the temperature limit
GPU OC:
Graphical Processing Unit overclock
MPU:
Mathematical Processing Unit
zRAM:
RAM compression to speed up your phone
*Leave on Core, IVA, and MPU
Voltages:
Set the voltages of each CPU frequency.
Feel free to 'thank' me for this, but.. it isn't expected.
Little outdated.
Will update as time goes on.
thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?
Dark Fear said:
thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?
Click to expand...
Click to collapse
Raise your min screen-off frequency
Thanks for taking the time to put this together, you really have outdone yourself. :thumbup:
Sent from my Nexus 4 using XDA Premium 4 mobile app
yeah little outdated but very informative thread for many new android explorers to understand things better. :highfive:
just a suggestion: UI card like in google now, keep
aLNG said:
just a suggestion: UI card like in google now, keep
Click to expand...
Click to collapse
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
MBQ_ said:
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Click to expand...
Click to collapse
i will give you a prototype what i mean by User Interface (UI) card later
This is great, clears up many concepts! Good work bro!
feedtheducks said:
This is great, clears up many concepts! Good work bro!
Click to expand...
Click to collapse
Myyy pleasure.
Have another version of the CPU Guide app coming soon too.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
(If you are too lazy to read the whole article, head down to The Final Results section and use those values for your kernel but i don't recommend that.)
The Introduction
First of all i am not a pro or something i am just a noob, so if i did any mistake in this post then please let me know. This thread can highly improve your SOT without compromising with the performance. I will try to make this thread as shorter as i can. I was getting 1 hour of SOT on my S5 a few days back, then i discovered this thread. I recommend everyone to leave this thread and read that one because everything is way better explained there but i am writing this for our S5 separately. Other device users can also read this if they want a shorter and simpler version of that original one.
The Setup
I am using smartpack kernel manager to tweak kernel values and i will also use cool tool for some reason (will explain it later.). Open smartpack kernel manager and go to cpu and open CPU Governor Tunables. We are going to tweak these values one by one.
above_hispeed_delay
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. To check this i jumped to cpu voltage section in smartpack kernel manager. My values are:
300MHz=775mV
422MHz=775mV
652MHz=775mV
729MHz=775mV
883MHz=780mV
960MHz=790mV
1036MHz=800mV
1190MHz=820mV
As you can see my voltage was same till 729MHz then it increased by 5mV, So 729MHz is an efficient clock rate for me. Now the volage was increasing by the same rate of 10mV till 1036MHz, So 1036MHz is also an efficient clock rate. Because i am too lazy to do this for every frequency i did that till 1728MHz and these are the efficient clock rates for me:
729MHz, 1036MHz, 1267MHz, 1728MHz
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups.
I really didn't understood the above method, i think because it was for a device with 2 cores but i knew that we don't need perfect values for this because we have to round up these values to our next near efficient clock rate.
So i figured out my own way: I turned off every hotplug and then turned off every core and changed the maximum frequency to the same as minimum (300MHz) and did every task by increasing the maximum frequency till i get the lag free experience. Figure out your nominal clock rates for atleast these tasks:
Idle
Web Page Scrolling
Video
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. Now round up your nominal clock rates to the next near efficient clock rates, For example 652MHz was lag free for me for web page scrolling and the next near efficient clock rate is 729MHz. I got these values:
Idle=300MHz
Page Scrolling=729MHz
Video=1036MHz
App Loading=1267MHz
High Load Processing=1728MHz
The Setup
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do.)
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 729000:60000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 729Mhz. Once it has exceeded 729Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute.)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
My Values: 20000 729000:60000 1036000:150000 1267000:300000
Optimize Idle Frequency (timer_rate)
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (300Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
target_loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
We have to calculate maximal efficient load for our efficient clock rates only and minimal efficient load for the other frequencies.
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 90) / next highest clock rate
For example, the maximal efficient load for 729Mhz would be caluclated as:
(729000 * 90) / 883000 = 74.30% (rounded and normalized: 74)For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - clock rate / previous highest clock rate) * -1For example, the minimal efficient load for 422Mhz would be calculated as:
(1 - 422000 / 300000) * -100 = 40.67% (rounded and normalized: 41)For our Galaxy S5, the maximal efficient loads are:
729:74
1036:78
1267:76
1728:79
For our Galaxy S5, the minimal efficient loads are:
300:0
422:41
652:55
883:21
960:9
1190:15
1497:18
1574:5
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
My Values: 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79
Fix Stuttering (min_sample_time)
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
The Final Results
I recommend you to read the whole article first and calculate everything on your own. It will be fun, trust me! Maybe you will find out better values than these.
above_highspeed_delay - 20000 729000:60000 1036000:150000 1267000:300000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1190400
min_sample_time - 80000
target_loads - 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79
timer_rate - 50000
timer_slack - 80000
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
You may have noticed that i copied and pasted so much things directly from original post, without any changes. That's because there is nothing to change. I only changed some things that i thought are required to better understand this guide for our device.
Thanks a lot... but I cannot change the numbers for interactive frequencies in 5''s it jumps too high.
Power and Performance (PnP) Tuner for Zenfone 8
Hello everyone,
Here´s a simple Magisk-Module that changes the behaviour of the so called "System modes" found in the battery section of settings.
{
"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"
}
I think some of you might have wondered already what the different sections do.
Just below you will find an overview of the different modes and some of their consequences/settings on stock compared to after you flashed the magisk-module.
I´m pretty sure after seeing the overview you understand the reasoning behind some of those changes.
CPU Frequency values are sorted following this scheme: CPU-Frequences Values of Little Cluster/Big Cluster/Prime Core MHZ
DefaultPnP-TunerHigh PerformanceCPU Min 1401/1324/1305
CPU Max:1804/2419/2841
GPU Min 315 MHZ
GPU Max 840 MHZCPU Min 1612/2227/2496 MHZ
CPU Max 1804/2419/2841 MHZ
GPU Min 315 MHZ
GPU Max 840 MHZDynamicCPU Min 300/710/844
CPU Max 1804/2112/2592
GPU Min 315 MHZ
GPU Max 738 MHZCPU Min 300/710/844 MHZ
CPU Max 1612/1766/2035 MHZ
GPU Min 315 MHZ
GPU Max 738 MHZDurableCPU Min 300/710/844
CPU Max 1497/2112/2592
GPU Min 315 MHZ
GPU Max 738MHZCPU Min 300/710/844 MHZ
CPU Max 1497/1440/1670 MHZ
GPU Min 315 MHZ
GPU Max 608 MHZUltra DurableCPU Min 300/710/844
CPU Max 1094/1209/1305
GPU Min 315 MHZ
GPU Max 608 MHZCPU Min 300/710/844 MHZ
CPU Max 1497/1440/1670 MHZ
GPU Min 315 MHZ
GPU Max 608 MHZ
Do not Schedule any foreground or top-app tasks to the prime-core to conserve even more batteryAdvanced LowCPU Min 1401/1324/1305
CPU Max 1804/2419/2841
GPU Min 315 MHZ
GPU Max 840 MHZCPU Min 300/710/844 MHZ
CPU Max 1708/2112/2496 MHZ
GPU Min 315 MHZ
GPU Max 738 MHZAdvanced MediumCPU Min 1497/1555/1785
CPU Max 1804/2419/2841
GPU Min 443MHZ
GPU Max 840 MHZCPU Min 300/710/844 MHZ
CPU Max 1804/2419/2841 MHZ
GPU Min 315 MHZ
GPU Max 840 MHZAdvanced HighCPU Min 1612/1996/2265
CPU Max 1804/2419/2841
GPU Min 540 MHZ
GPU Max 840 MHZCPU Min 691/710/844 MHZ
CPU Max 1804/2419/2841 MHZ
GPU Min 315 MHZ
GPU Max 840 MHZ
Default QCOM configuration
So what do the limits mean. If the powerhal does not interfere or sets different values than those in this table, then this are the Min/Max CPU/GPU configurations the phone runs with in every mode.
For the default Dynamic mode this means the phone runs at maximal 1804/2112/2592MHZ for Little Cluster/Big Cluster/Prime Core when the powerhal decides there´s no reason to boost above these limits. (reasons to boost would be unlocking the device, opening apps, using camera, fling boosts, scroll boosts, drag boosts etc)
So after stumbling over a few reports that reported worse battery life when using the advanced mode a while ago, here is a simple explanation.
The three levels available to choose from in the advanced section resemble X-Mode from the ROG Phone series.
This mode raises the minfreqs to increase performance. The description of the advanced setting "flexible performance settings for all your needs" needs to be taken literally.
There´s only one thing advanced mode gives, even on its lowest level, and that is performance. At the beginning I thought setting the sliders to low would result in a battery saving mode, but it´s exactly the opposite.
I personally don´t see a need for this on a compact device that´s not made for gaming.
So I adjusted most of the modes a bit to my personal liking and created this magisk module.
There´s now only a single high performance mode and that is the high performance mode. It raises minfreqs and is no configuration you should run your phone on a daily basis. It´s primarily meant for benchmarks. There are more boosts in the configuration than those in the overview above, but the overview was large enough as it already is.
Dynamic Mode is now toned down a bit from stock. This is a very good configuration to run games, as the phone will get warm slower and in the end throttle slower if it will at all throttle.
Durable is now an excellent mode to save power if you only do light tasks and need the phone to survive as long as possible, but still want some performance.
Ultra durable is now well, the extreme power saving mode. You can see I raised the max freqs a bit compared to the stock configuration, however we use a small trick. No foreground or top-app tasks (those are usally the apps displayed at the top layer and other important performance hungry tasks) will be scheduled to the power-hungry prime core.
The advanced slider on low for CPU, will use the configuration from stock dynamic mode, which is excellent for day to day usage if you want performance.
It will also allow the Little Cluster to scale back to 300MHZ to save more power, although it´s not default qcom configuration.
The advanced slider on medium for CPU will use max CPU freqs, but still allow the little cluster to go to 300mhz.
The CPU slider on High in advanced mode will now run the phone in the default QCOM configuration for modern QCOM SoCs. That means 691/710/844 MHZ for Little Cluster/Big CLuster/Prime Core alongside the max freqs for each cluster/core.
In a soon to be released update for my kernel you can also combine these modes with the battery saver mode accessible via the CleanSlate config app, which also allows you to restrict the powerhal from boosting above the values predefined in Advanced Low CPU Slider (Level 1), Dynamic (Level 2) Durable (Level 3) and Ultra - Durable (Level 3). As of now the limits differ a little bit, but it can be still done this way.
Just enable the "Battery Saver"-Feature as well as "Battery Saver Touch Limiting" and set the desired level of saving like on the following screenshot:
You can use Durable for example for extended navigation session, or even ultra durable to not engage the prime core while Google Maps is in foreground.
There´s a quicksettings toggle which can be added so I think those settings are really valuable, also to change on the fly more or less.
Anyway, I hope this clears some confusion around the system modes and their usefulness. Also for people that do not decide to unlock their devices.
Download:
Downloads for : -Android- Generic Device/Other | AndroidFileHost.com | Download GApps, Roms, Kernels, Themes, Firmware and more. Free file hosting for all Android developers.
Download GApps, Roms, Kernels, Themes, Firmware, and more. Free file hosting for all Android developers.
www.androidfilehost.com
Requirements:
unlocked zf8 running stock firmware
working magisk enviroment
Instructions:
1. Download the module and flash via Magisk Manager
2. Reboot
3. Profit
Donations:
Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea
If you like my work: http://paypal.me/freak07
this is mine
this is mine as well
well sorry for the misalignment of the "default" column. It seems once in the "edit" post view after initially creating the thread it gets squeezed and there´s no way to stretch it again.
At the end of spreadsheet in "PnP-Tuner" column i see "Default QCOM configuration".
It is explained in few places of original post, but not what it exactly is.
Could you please explain/expand it it a little more? Or it's just common name for 691/710/844 Hz? Because it sounds like something special))
dron39 said:
At the end of spreadsheet in "PnP-Tuner" column i see "Default QCOM configuration".
It is explained in few places of original post, but not what it exactly is.
Could you please explain/expand it it a little more? Or it's just common name for 691/710/844 Hz? Because it sounds like something special))
Click to expand...
Click to collapse
The default qcom configuration for CPU min/maxfreqs of sd888 is:
CPU Min 691/710/844 MHZ
CPU Max 1804/2419/2841 MHZ
Very interesting to hear this about the Advanced configurations, that they are all geared towards performance by default.
Do you really feel that your configuration for ultra durable mode, even though it has higher clocks, will save more battery just by disabling the prime core?
I would love to see some comparisons of battery life (Screen on times) with this module enabled and without it.
I still didn't root my phone (very root sensitive banking apps), that's why I can't try it out myself, but I would root my phone and go through the hassle of getting my banking apps to work if I saw that I would get better battery life etc.
assasss said:
I would love to see some comparisons of battery life (Screen on times) with this module enabled and without it.
I still didn't root my phone (very root sensitive banking apps), that's why I can't try it out myself, but I would root my phone and go through the hassle of getting my banking apps to work if I saw that I would get better battery life etc.
Click to expand...
Click to collapse
same can you please post battery life (total, screen on, idle) on durable & ultra durable modes?
This is Durable 100% down to 5%, then Ultra Durable 5% down to 1%.
Version 115
Rooted stock with this PnP tuner
Refresh rate locked at 90Hz
Force lower touch sampling rate: On
WiFi for perhaps 7hrs total, rest is 4G, 4G+, 5G
Adaptive brightness: On
Always On Panel: Off
A second run with identical settings as above.
But very different usage. A lot more heavy with video calls, YouTube, hotspot, etc.
WiFi around 9hrs, rest is 4G, 4G+, 5G.
P3aK said:
A second run with identical settings as above.
But very different usage. A lot more heavy with video calls, YouTube, hotspot, etc.
WiFi around 9hrs, rest is 4G, 4G+, 5G.
Click to expand...
Click to collapse
Awesome stats both runs. Other configurations that you apply to achieve that SOT? I use the same config (Kirisakura kernel, durable and PnP Tuner) and my average is 5 hours at best :/
5hrs? Yikes!
I'm still on stock kernel. I want to make 2 runs on slightly modified PnP Ultra Durable now and see what that yields. Then I plan on trying out the kernel together with PnP. I am secretly hoping on breaking 10hrs SoT with Kernel + Ultra Durable.
Not very viable for everyday use, for sure. But more like, when needed outside of civilization.
As for other configs:
(not sure anymore what is default or not, so I just list random things I think I might have changed, or could have an impact)
WiFi, Bluetooth, NFC, Location: Always off unless using/needed.
VoLTE on.
5G network on.
Auto 5G on.
Preffered network type: 2/3/4/5G
WiFi calling on
Calling preference: Mobile network
Roaming preference: WiFi
Disabled all Facebook apps/services. Using Facebook Lite instead.
Disabled Instagram. Don't use it.
Gboard disabled. Using SwiftKey instead.
Gmail disabled. Need Outlook for work.
Speech services by Google disabled.
YouTube Music disabled.
YouTube Vanced instead of original, but not disabled.
Dial pad sounds off.
Screen locking sounds off.
Touch sounds off.
Completely dark static Amoled wallpaper.
System color scheme Dark.
Always On Panel off.
Lift to check phone off.
New notifications off.
Auto rotate screen off.
Refresh rate 90Hz.
All Google location, history, ads, blah, blah off, except ELS and Google Location Accuracy.
Find my device off.
Fingerprint off.
Face recognition off.
Game genie off.
Twin apps off.
OptiFlex on (ca 10 apps that I use on "Speed up", rest off).
Everything on Gestures page off.
Pocket mode on
USB debugging on.
Verify apps over USB off.
WiFi scan throttling on.
Mobile data always active on.
Default USB configuration: File transfer
Everything else should be default settings. Might have missed the odd one somewhere.
banannerz said:
Very interesting to hear this about the Advanced configurations, that they are all geared towards performance by default.
Do you really feel that your configuration for ultra durable mode, even though it has higher clocks, will save more battery just by disabling the prime core?
Click to expand...
Click to collapse
Well the Prime core is purely made for performance since its the Cortex X1 and not just a A78 with more cache. So basically "disabling" it could yield quite some saving.
I am surprised they don't do this by default... (at least for modes when you want to conserve maximum energy)
Yeah, turning off the prime core entirely in ultra durable mode would make a whole lotta sense.
Freak07,
Hi! Is it still actual on latest FW's and your kernel?
Freak07 said:
In a soon to be released update for my kernel you can also combine these modes with the battery saver mode accessible via the CleanSlate config app, which also allows you to restrict the powerhal from boosting above the values predefined in Advanced Low CPU Slider (Level 1), Dynamic (Level 2) Durable (Level 3) and Ultra - Durable (Level 3). As of now the limits differ a little bit, but it can be still done this way.
Just enable the "Battery Saver"-Feature as well as "Battery Saver Touch Limiting" and set the desired level of saving like on the following screenshot:
Click to expand...
Click to collapse
Is there any other ways to control that instead of installing separate app?
Xiaomi™ is throttling performance on some popular third party apps and games including BGMI and PUBG.
DTS [Dynamic Thermal Scaling] is popular method to prevent overheating but here's OEM's are using it beyond it's purpose.
We Tested two different smartphones from different OEM's with same SOC (sm6225) varient 4+64 GB both charged to 100% at 27°C Room Temperature ]
1. REDMI NOTE 11 : When we test on some popular Apps and Games at 27°C Room Temperature the result was as expected.On "Xiaomi Redmi Note 11" the Clock-speed of A73 cores was Limited to 1.7 and 2.2 GHz and A53 cores to somewhat 1.19 and 1.50 GHz most of times on 3rd Party Apps and Games and as soon as we exit to Home screen and Randomly scrolled the Clock-speed of A73 was peaking from 1.09 to 2.4 GHz and A53 to some what 1.10 to 1.9 GHz.
2. REALME 9i : Same Test we run on "Realme 9i"at same Room Temperature to confirm is Xiaomi or Qualcomm™ is the factor to locked SOC peak clock speed on certain apps and games
and the result was shocking Realme 9i was letting apps and games to use full peak clock-speed aka A73 to 2.4 GHz and A53 to 1.9 GHz until it reaches 47°C and throttling it to 2.2 GHz on A73 and 1.8 on A53 cores respectively.
Result :"Realme 9i" doesn't limit cpu clocked speed on 3rd party Apps and Games like "Redmi Note 11" does and also the application and games were running much smother on "Realme 9i" compared to "Redmi Note 11"
Solution : Systemless Mounting of Blank Thermal Configs and Blank Thermal Drivers through (Magisk Module) solve the problem but upto a certain limit.OEM's like Xiaomi is using Application Optimization Libs and Game Optimation Libs, black listing CPU and GPU clock speed even after overiding thermals configs....
.
Cool