A plethora of info on CPU governors (source):
CPU frequency and voltage scaling code in the Linux(TM) kernel
L i n u x C P U F r e q
C P U F r e q G o v e r n o r s
- information for users and developers -
Dominik Brodowski <[email protected]>
some additions and corrections by Nico Golde <[email protected]>
Clock scaling allows you to change the clock speed of the CPUs on the
fly. This is a nice method to save battery power, because the lower
the clock speed, the less power the CPU consumes.
Contents:
---------
1. What is a CPUFreq Governor?
2. Governors In the Linux Kernel
2.1 Performance
2.2 Powersave
2.3 Userspace
2.4 Ondemand
2.5 Conservative
2.6 Interactive
2.7 MinMax
2.8 SmartassV2
3. The Governor Interface in the CPUfreq Core
1. What Is A CPUFreq Governor?
==============================
Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.
How to decide what frequency within the CPUfreq policy should be used?
That's done using "cpufreq governors". Two are already in this patch
-- they're the already existing "powersave" and "performance" which
set the frequency statically to the lowest or highest frequency,
respectively. At least two more such governors will be ready for
addition in the near future, but likely many more as there are various
different theories and models about dynamic frequency scaling
around. Using such a generic interface as cpufreq offers to scaling
governors, these can be tested extensively, and the best one can be
selected for each specific use.
Basically, it's the following flow graph:
CPU can be set to switch independently | CPU can only be set
within specific "limits" | to specific frequencies
"CPUfreq policy"
consists of frequency limits (policy->{min,max})
and CPUfreq governor to be used
/ \
/ \
/ the cpufreq governor decides
/ (dynamically or statically)
/ what target_freq to set within
/ the limits of policy->{min,max}
/ \
/ \
Using the ->setpolicy call, Using the ->target call,
the limits and the the frequency closest
"policy" is set. to target_freq is set.
It is assured that it
is within policy->{min,max}
2. Governors In the Linux Kernel
================================
2.1 Performance
---------------
The CPUfreq governor "performance" sets the CPU statically to the
highest frequency within the borders of scaling_min_freq and
scaling_max_freq.
2.2 Powersave
-------------
The CPUfreq governor "powersave" sets the CPU statically to the
lowest frequency within the borders of scaling_min_freq and
scaling_max_freq.
2.3 Userspace
-------------
The CPUfreq governor "userspace" allows the user, or any userspace
program running with UID "root", to set the CPU to a specific frequency
by making a sysfs file "scaling_setspeed" available in the CPU-device
directory.
2.4 Ondemand
------------
The CPUfreq governor "ondemand" sets the CPU depending on the
current usage. To do this the CPU must have the capability to
switch the frequency very quickly. There are a number of sysfs file
accessible parameters:
sampling_rate: measured in uS (10^-6 seconds), this is how often you
want the kernel to look at the CPU usage and to make decisions on
what to do about the frequency. Typically this is set to values of
around '10000' or more.
show_sampling_rate_(min|max): the minimum and maximum sampling rates
available that you may set 'sampling_rate' to.
up_threshold: defines what the average CPU usage between the samplings
of 'sampling_rate' needs to be for the kernel to make a decision on
whether it should increase the frequency. For example when it is set
to its default value of '80' it means that between the checking
intervals the CPU needs to be on average more than 80% in use to then
decide that the CPU frequency needs to be increased.
ignore_nice_load: this parameter takes a value of '0' or '1'. When
set to '0' (its default), all processes are counted towards the
'cpu utilisation' value. When set to '1', the processes that are
run with a 'nice' value will not count (and thus be ignored) in the
overall usage calculation. This is useful if you are running a CPU
intensive calculation on your laptop that you do not care how long it
takes to complete as you can 'nice' it and prevent it from taking part
in the deciding process of whether to increase your CPU frequency.
2.5 Conservative
----------------
The CPUfreq governor "conservative", much like the "ondemand"
governor, sets the CPU depending on the current usage. It differs in
behaviour in that it gracefully increases and decreases the CPU speed
rather than jumping to max speed the moment there is any load on the
CPU. This behaviour more suitable in a battery powered environment.
The governor is tweaked in the same manner as the "ondemand" governor
through sysfs with the addition of:
freq_step: this describes what percentage steps the cpu freq should be
increased and decreased smoothly by. By default the cpu frequency will
increase in 5% chunks of your maximum cpu frequency. You can change this
value to anywhere between 0 and 100 where '0' will effectively lock your
CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.
down_threshold: same as the 'up_threshold' found for the "ondemand"
governor but for the opposite direction. For example when set to its
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased.
2.6 Interactive
---------------
The CPUfreq governor "interactive" is designed for latency-sensitive,
interactive workloads. This governor sets the CPU speed depending on
usage, similar to "ondemand" and "conservative" governors. However,
the governor is more aggressive about scaling the CPU speed up in
response to CPU-intensive activity.
Sampling the CPU load every X ms can lead to under-powering the CPU
for X ms, leading to dropped frames, stuttering UI, etc. Instead of
sampling the cpu at a specified rate, the interactive governor will
check whether to scale the cpu frequency up soon after coming out of
idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is very busy between exiting idle and
when the timer fires then we assume the cpu is underpowered and ramp
to MAX speed.
If the cpu was not sufficiently busy to immediately ramp to MAX speed,
then governor evaluates the cpu load since the last speed adjustment,
choosing th highest value between that longer-term load or the
short-term load since idle exit to determine the cpu speed to ramp to.
There is only one tuneable value for this governor:
min_sample_time: The minimum amount of time to spend at the current
frequency before ramping down. This is to ensure that the governor has
seen enough historic cpu load data to determine the appropriate
workload. Default is 80000 uS.
2.7 MinMax
---------------
The CPUfreq governor "maxmin" tries to minimize the frequency jumps by limiting
the selected frequencies to only two frequencies: either the min or the max
frequency of the current policy. The frequency is raised or lowered according
to the current load and the 'up_threshold' and 'down_threshold'.
Its parameters and implementation are similar to that of conservative.
It does not have the freq_step parameter as it jumps right from min to max
and vice-versa.
The sampling_down_factor, unlike conservative, will count the minimal number
of samplings since the last time we saw the 'up_threshold' load on the CPU.
Hence it is set to higher default and acts as a limiter not to do too many
frequency jumps without hurting the performance.
2.8 SmartassV2
---------------
The CPUfreq governor "smartassV2", like other governors, aims to balance
performance vs battery life by using low frequencies when load is low and
ramping the frequency when necessary, fast enough to ensure responsiveness.
The implementation of the governor is roughtly based on the idea of interactive.
The idle loop is used to track when the CPU has idle cycles. The idle loop will
set a relatively high rate timer to sample the load when appropriate, the timer
will measure the load since it was set and schedule a work queue task to do the
actual frequency change when necessary.
The most important tunable is the "ideal" frequency: this governor will aim
for this frequency, in the sense that it will ramp towards this frequency much
more aggresively than beyond it - both when ramping up from below this frequency
and when ramping down from above this frequency. Still, note, that when load is
low enough the governor should choose the lowest available frequency regardless
of the ideal frequency and similarly when load is consistently high enough the
highest available frequency will be used.
Smartass also tracks the state of the screen, and when screen is off (a.k.a
sleep or suspended in the terms of this governor) a different ideal frequency
is used. This is the only difference between the screen on and screen off
states. Proper tuning of the awake_ideal_freq and sleep_ideal_freq should
allow both high responsiveness when screen is on and utilizing the low
frequency range when load is low, especially when screen is off.
Finally, smartass is a highly customizable governor with almost everything
tweakable through the sysfs. For a detailed explaination of each tunable,
please see the inline comments at the begging of the code (smartass2.c).
Click to expand...
Click to collapse
I am writing this guide to help you make your own init.d scripts which you can use to set voltages and fine tune governor settings at boot.
Part 1: Creating a return to stock flashable zip
Part 2: Creating a flashable zip to set a default governor
Part 3: Setting default CPU frequencies.
Part 4: Tweaking voltages
General Information on the smartassV2 governor
Part 5: Setting ideal sleep and wake frequencies for smartassV2
Part 6: Understanding max and min cpu load
Part 8: Setting CPU thresholds and ramp steps
Part 9: Up rate us and down rate us
Creating a return to stock flashable zip
I do not have any background in programming or engineering. Editing scripts is something I realized I could do after reading through the thread on the LeeDroid ROM.
I had been using apps to adjust voltage levels of the processor, and the settings would not stick past reboot. LeeDroid's post showed me how I could adjust "vdd_levels" in a different way: by editing a file in the system/etc/init.d setting of your phone.
I started by manually editing files using Root Explorer. The new settings would take effect on reboot. I recommend that you edit using editor in an Android app designed for the purpose, like Root Explorer. Editing Android text files with Windows notepad could remove UNIX coding.
Of course, a bad edit could result in a phone which would not boot or enter into boot loops. So if you plan to do this I recommend that you first create a return to stock zip.
If you have a zip which would restore the stock zip file that you plan to edit, at worst a bad setting creates a problem that can be fixed by a simple battery pull, and flashing the return to stock file.
So lets learn how to create a flashable zip with a return to stock file.
The file that needs to be edited for setting and tweaking governors and clocks speeds is normally:
1. 01sysctl
2. 07sysctl
3. 00start
4. Something else :silly:A have created a blank template which you can edit and which you should download and edit as part of this tutorial.
DOWNLOAD THE ATTACHMENT (having dinner. feeding dog. will upload it after) .
1. After you download the attachment, unzip and lets start editing the files inside.
2. Open the folder returntostock-template and you will see two folders:
META-INF
system
3. First lets copy the file to plan to edit into the /returntostock-template/system/etc/init.d folder.
If you are planning to edit the system/etc/init.d/01sysctl file, copy 01sysctl and paste it in
/returntostock-template/system/etc/init.d/
When you flash the zip you are creating the contents of /returntostock-template/system/etc/init.d/ will be flashed into /system/etc/init.d/
4. No, go into the META-INF folder.
5. Open the file called CERT.SF with a text editor. It should looks something like this:
Signature-Version: 1.0
Created-By: 1.0 (Android SignApk)
SHA1-Digest-Manifest: UX+RVULxNdXlqI1RzwHfpVdI82E=
Name: META-INF/com/google/android/updater-script
SHA1-Digest: tVgqIpMRtv5B/PDrjuBV53KwFaE=
Name: system/etc/init.d/01sysctl
SHA1-Digest: ldESPD5zXoMgc1LeEoJzmQR64XI=
Name: META-INF/com/google/android/update-binary
SHA1-Digest: bgbIMYDdOmTgqY3FnKD5cRyGkrw=
Click to expand...
Click to collapse
I highlighted in bold the line you may have to change. If you are editing the 01sysctl file than you can leave it as is. If you are editing the 00start file you can change the line to read:
Name: system/etc/init.d/00start
Click to expand...
Click to collapse
6. Next, open the file called MANIFEST.MF. It should looks something like this:
Manifest-Version: 1.0
Created-By: 1.0 (Android SignApk)
Name: META-INF/com/google/android/updater-script
SHA1-Digest: buU2q9y9m+br7uS7p3pPrQBNAvs=
Name: system/etc/init.d/01sysctl
SHA1-Digest: vdvxtL6XYfchsrXx3EBnG+qNyXE=
Name: META-INF/com/google/android/update-binary
SHA1-Digest: lW3X0T93MyGESji9tYbY+94o+jo=
Click to expand...
Click to collapse
I highlighted in bold the line you may have to change. If you are editing the 01sysctl file than you can leave it as is. If you are editing the 00start file you can change the line to read:
Name: system/etc/init.d/00start
Click to expand...
Click to collapse
7. THIS LAST STEP IS OPTIONAL, BUT IT IS NICE TO PERSONALIZE YOUR WORK. Next, go into the com folder, and than the google folder and finally the android folder.
8. Open the file called updater-script with a text editor. What you should see should look like this:
#
# Updater-script
#
ui_print("Flashing process for NAME OF ROM HERE");
ui_print(">>>Mounting partitions");
assert(mount("ext3", "EMMC", "/dev/block/mmcblk0p25", "/system") || mount("ext4", "EMMC", "/dev/block/mmcblk0p25", "/system"));
ui_print(">>>Writing System");
package_extract_dir("system", "/system");
ui_print(">>>Unmounting partitions");
unmount("/system");
ui_print("Done!");
Click to expand...
Click to collapse
You can change the NAME OF ROM HERE to anything you like. It will be displayed when the script is flashed.
9. Okay, were almost done. You can rename the folder to returntostock-template to something which will remind you what it is like CoolICSROM-returntostock or anything else you like.
10. Zip the file, and it is ready to use.
Now lets make another flashable zip, this time to set a new default governor.
Creating a flashable zip to set a default governor
Having learned how to make a flashable zip from this post, we now have the tool to deploy the payload into you ROM from recovery. So lets deploy something :laugh: Lets make a flashable zip to set the governor.
1. Okay, lets unzip the return to stock zip you made. In our first guide we called it CoolICSROM-returntostock.zip. It will unzip into a folder of the name of your file. In our example the folder will be named CoolICSROM-returntostock.
2. Lets rename the folder boonkeat8-governortweak, or anything else you want.
3. Now, these scripts are really more like hidden settings. They do not add any functionality to your ROM, but allow to enable things already there. So first we should check what governors are supported by you ROM.
Browse to > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
You should see something like this
convervative interactive ondemand ondemandX lionheart lionheartX smartassV2
Click to expand...
Click to collapse
What you see listed is what is available.
4. In order to enable a governor as default, you have to write this line into the 01syscl (or 00start or other file depending on the ROM). Let's say we want to use the smartassV2 governor.
This is the line of code you need to write to enable it.
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
5. Lets go into the boonkeat8-governortweak and browse to /system/etc/init.d folder. Open the 01sysctl, 00start or other file you place in there with a text editor.
6. The typical 01sysctl file looks something like this:
#!/system/bin/sh
# - sysctl -p
Click to expand...
Click to collapse
7. So lets just insert the line so it looks like this:
#!/system/bin/sh
# - sysctl -p
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
8. Zip the boonkeat8-governortweak folder, and you now have a flashable zip to enable the smartassV2 governor.
xxxxxxxxxxxxxxxxx
The 00start start file in a ROM like TrickDroid looks more daunting.
#!/system/bin/sh
SCHEDULER=noop
echo $SCHEDULER > /sys/block/mtdblock25/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock26/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock27/queue/scheduler
echo $SCHEDULER > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/rotational
for i in 1 2 3 4 5
do
echo 0 > /sys/block/mtdblock$i/queue/rotational
done
sync
echo "3" > /proc/sys/vm/drop_caches
setprop dalvik.vm.execution-mode int:fast
Click to expand...
Click to collapse
But you just to the same thing. Insert the line of code.
#!/system/bin/sh
SCHEDULER=noop
echo $SCHEDULER > /sys/block/mtdblock25/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock26/queue/scheduler
echo $SCHEDULER > /sys/block/mtdblock27/queue/scheduler
echo $SCHEDULER > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/rotational
for i in 1 2 3 4 5
do
echo 0 > /sys/block/mtdblock$i/queue/rotational
done
sync
echo "3" > /proc/sys/vm/drop_caches
setprop dalvik.vm.execution-mode int:fast
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
Lets mode on to setting default CPU frequencies.
Setting default CPU frequencies
I really hope someone is reading all this.
Okay, having learned how to set the default governor, lets move on to default processor speeds.
Right now our init.d configuration script looks something like this:
#!/system/bin/sh
# - sysctl -p
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
In order to change the default processor frequency, we have to first find out what is available.
You can do this by opening the scaling_available_frequencies file located in /sys/devices/system/cpu/cpu0/cpufreq.
The contents should look something like this:
122060 245760 368640 768000 806400 1024000 1200000 1401600 1497600 1708800 1804800 1900800 2016000
Click to expand...
Click to collapse
245760 = 245 MHz
368640 = 368 MHz
768000 = 768 MHz
806400 = 806 MHz
1024000 = 1024 MHz
...and so on
REMEMBER, YOU ONLY NEED TO DO THIS IF YOU WANT TO CHANGE THE DEFAUL PROCESSOR SPEEDS.
To find out the the default processor speeds browse to:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - This tells you what the current maximum processor frequency is.
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq - This tells you what the current minimum processor frequency is.
The command to change the processor speeds are:
echo 'PROCESSOR SPEED HERE' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 'PROCESSOR SPEED HERE' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
So if we wanted to modify our current project to have a maximum speed of 1200 MHz, and a minimum speed of 368 MHz, we would modify our current file to look like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
If you only want to change the maximum frequency than just enter the line for that:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
Now, lets mess with voltages.
Changing voltages
Okay, we have learned how to make a flashable zip, change the default governor and change the default frequencies.
Before we get into how to adjust default voltages, one thing you should take into consideration is the most ROM's already have HTC default voltages for the Desire HD tweaked for efficiency.
HTC default voltages
245 MHz - 1000 vdd
422 MHz - 1025 vdd
806 MHz - 1100 vdd
1024 MHz - 1200 vdd
Source: LeeDrOiD HD Thread.
Typical stock voltage for most custom ROM's
245 MHz - 875-925 vdd
422 MHz - 900-950 vdd
806 MHz - 10125-1075 vdd
1024 MHz - 1050-1100 vdd
Given this situation reducing voltage is not all that important these days.
Anyway, lets discuss how to do it, and we can engage in discussions, and get feedbacks from users on the matter.
Checking your ROM's default voltages
Okay, lets fire up you file manager and browse to /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
{
"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"
}
Image of vdd_levels file from ARHD 6.3.3.
Image of vdd_levels file from Blackout ICS v.3.1.1 modified with Blackout-smartassV2-1GHz-c3.zip.
Changing the voltage
The command for changing voltage is:
echo 'FREQUENCY VDD' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
When running the 1200 MHz speed I find my phone can run this speed as low as 1100MHz. I learned this while running ARHD6.3.3.
In order to set that voltage you would need this command:
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
Adding it to our current project
Our current project looks something like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
Thats all there is too it.
Now lets go and tweak smartassV2.
General information on the smartassV2 governor
Governors are of all types generally to be based on one of two sources: ondemand and conservative.
smartassV2 for example is based on ondemand.
Other popular governors like lionheartX are based on the conservative governor.
Okay, lets start with smartassV2
General info:
SmartassV2 "has an 'ideal' frequency which it will quickly ramp up to, then more slowly ramp up once past it, and vice-versa for down-ramping. A separate "ideal" frequency is used when the screen is off."
Click to expand...
Click to collapse
(Source)
The most important tunable is the "ideal" frequency: this governor will aim for this frequency, in the sense that it will ramp towards this frequency much more aggresively than beyond it - both when ramping up from below this frequency and when ramping down from above this frequency. Still, note, that when load is low enough the governor should choose the lowest available frequency regardless of the ideal frequency and similarly when load is consistently high enough the highest available frequency will be used.
Smartass also tracks the state of the screen, and when screen is off (a.k.a sleep or suspended in the terms of this governor) a different ideal frequency is used. This is the only difference between the screen on and screen off states. Proper tuning of the awake_ideal_freq and sleep_ideal_freq should allow both high responsiveness when screen is on and utilizing the low frequency range when load is low, especially when screen is off
Click to expand...
Click to collapse
(Source).
Tunables (Source)
awake_ideal_freq
The "ideal" frequency to use when awake. The governor will ramp up faster towards the ideal frequency and slower after it has passed it. Similarly, lowering the frequency towards the ideal frequency is faster than below it.
sleep_ideal_freq
The "ideal" frequency to use when suspended. When set to 0, the governor will not track the suspended state (meaning that practically when sleep_ideal_freq =0 the awake_ideal_freq is used also when suspended).
sleep_wakeup_freq
The frequency to set when waking up from sleep.When sleep_ideal_freq=0 this will have no effect.
ramp_up_step
Frequency delta when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
ramp_down_step
Frequency delta when ramping down below the ideal freqeuncy. Zero disables and will calculate ramp down according to load heuristic. When above the ideal freqeuncy we always ramp down to the ideal freq.
max_cpu_load
CPU freq will be increased if measured load > max_cpu_load;
min_cpu_load
CPU freq will be decreased if measured load < min_cpu_load;
up_rate_us
The minimum amount of time to spend at a frequency before we can ramp up. Notice we ignore this when we are below the ideal frequency.
down_rate_us
The minimum amount of time to spend at a frequency before we can ramp down. Notice we ignore this when we are above the ideal frequency.
sample_rate_jiffies
Sampling rate, I highly recommend to leave it at 2.
Click to expand...
Click to collapse
Setting ideal sleep and wake frequencies for smartassV2.
Wake, sleep and deepsleep
Your basic governor is on demand and it runs your processor from the slowest speed to the fastest speed, depending on "need". With a HTC Desire HD, typically the slow speed for a ROM at stock settings is around 245MHz and the fastest is at about 1024 MHz.
Need is determined by something called the max_cpu_load setting. But we will get back to the in a later post.
What differentiates smartassV2 is the addition of two settings to your basic ondemand governor:
awake_ideal_frequency
sleep_ideal_frequency
You will find the smartassV2 settings in /sys/devices/system/cpu/cpu0/cpufreq/smartass
awake_ideal_frequency - This setting will influence processor behavior when screen is on.
sleep_ideal_frequency - This setting will influence processor behavior when screen is off. Basically, when the phone is working in the background.
Deep sleep - The kernel is in charge.
Speed brakes
So lest say, maximum cpu frequency is set to 1024 MHz. This is the fastest the phone will run.
Typically, awake_ideal_frequency will be set at 800000 (meaning 800 MHz). This is the speed which the phone will ramp up fast to. After this the processor will still speed up, but more conservatively.
So lets say the ROM we are using has the following frequencies available:
245 - 368 - 768 - 806 - 1024 MHz.
When the screen is awake, the phone will go from 245 MHz to 368 MHz to 768 MHz and 806 MHz "fast"... but will take more time before deciding to go to 1024 MHz. Think of it as a setting which starts to apply brakes to the CPU's and try to slow down the CPU's progress.
So basically the lower the awake_ideal_frequency the more conservative the processor behavior will be. This should result in better battery life, but also poorer performance.
sleep_ideal_frequency
sleep_ideal_frequency works the same way, but it replaces the awake_ideal_frequency when the screen if off,
Typical sleep_ideal_frequency is between 200000 to 400000 (200 MHz to 400 MHz) so it applies the brakes sooner.
This is based on the theory that while the screen if off, even if it is working, it needs less power.
Back to are project
We left our project looking like this in the previous post:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Click to expand...
Click to collapse
The command for setting awake_ideal_freq and sleep_ideal_freq are as follows:
echo 'FREQUENCY' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_ideal_freq
echo 'FREQUENCY' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
Now lets say we wanted to leave out awake ideal frequency at ROM default of 800 MHz, but wanted to make the sleep ideal frequency higher, to 368 MHz from 245 mHz. We could do it two ways.
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '400000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
Click to expand...
Click to collapse
You could also put the exact frequency:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '368640' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
Click to expand...
Click to collapse
Both will have the same effect.
TAKE NOTE OF THE ORDER, YOU MUST ENABLE SMARTASS FIRST, BEFORE TWEAKING ITS SETTINGS SO PUT THE LINE TO ENABLE SMARTASSV2 BEFORE THE CODES TWEAKING IT
Okay, lets move on to CPU load.
Understanding max and min cpu load
In the previous part of this guide we learned who to set the ideal wake and sleep levels.
Lets move on to another pair of important tunables:
max_cpu_load
min_cpu_load
max/min cpu load is set at a % figure.
For if example max_cpu_load is set at "55", than when the average processor usage is over 55% for a given period of time the processor will speed up. min_cpu_load is the figure that governs when the processor will slow down.
Before talking about how to do this, lets do that math since these two figures have to be set in a mathematically correct way.
A lot of popular ROM's these days have very few choices in terms of clock speeds:
122 MHz
245 MHz
368 MHz
768 MHz
806 MHz
1024 MHz
and so on.
Click to expand...
Click to collapse
These are the clock speeds on the Blackout ICS ROM and other ROM's based on the Virtuous Kernel. You can find the available clock speeds for a ROM by looking at the sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies. In that file you will see clockspeeds in Hertz rather than MHz so 122000 = 122 mHz.
The Blackoyr ROM also sets:
max_cpu_load = 55
min_cpu_load = 25
ramp_up_step = 200000
ramp_down_step = 300000
Click to expand...
Click to collapse
Ramp up and ramp down steps are also important to how this all works, and can be adjusted, but lets leave that to the next part of this guide.
Slowing down
Using the setting in the Blackout ROM, this is how min_cpu_load works
Okay, all this is a bit confusing (or at least I am having a hard time writing it) but let me see if I can explain it by example. Lets says you just completed a heavy task and the phone is running at full speed (1024 MHz be default). The phone will continue to run at this speed, until the average processor use is below min_cpu_load:
1024 x 0.25 = 256 MHz
Click to expand...
Click to collapse
So the processor goes down from 1024 MHz by 300 MHz (the ramp down speed) to 768 MHz. If processor use goes to below 256 MHz, the processor will ramp down to 768 MHz.
One at 768 MHz, the governor will compute again:
768 x 0.25 = 192 MHz
Click to expand...
Click to collapse
If the average processor speed is less than 192 MHz, is will continue to slow down. If greater than 192 MHz it will stay at 768 MHz.
Speeding up
With the phone now running 768 MHz, if the load goes higher the max_cpu_load than the processor will speed up. At 768 MHz the max_cpu_load is 422 MHz:
768 x 0.55 = 422 MHz
Click to expand...
Click to collapse
Logical values
When setting this two figures, it is important that:
cpu frequency x cpu_min_load for the higher speed
BE HIGHER THAN
cpu frequency x x cpu_max_load for the lower speed
Click to expand...
Click to collapse
Lets say we set:
max_cpu_load = 55
min_cpu_load = 45
Click to expand...
Click to collapse
Using the the new figures, we just completed another heavy task and the phone is again running at full speed (1024 MHz be default). The phone will continue to run at this speed, until the average processor use is below min_cpu_load:
1024 x 0.45 = 461 MHz
Click to expand...
Click to collapse
Lets say the average processor speed is at 450 MHz, so the processor scales down to 768 MHz.
If processor use remain continues at 450 MHz, the governor will compute again:
768 x 0.45 = 345 MHz
Click to expand...
Click to collapse
Since 400 MHz is higher than 345 MHz. The processor stays at 768MHz and the governor stops ramping down. But the governor is also checking if it should speed up:
768 x 0.55 = 422 MHz
Click to expand...
Click to collapse
Since average speed is over 422 MHz, the processor speeds up back to 1024 MHz. And when there, it will ramps down again.
In sum:
max_cpu_load = 55
min_cpu_load = 45
Are not good values when use with a ROM where the available frequencies are far apart like the ones on the Blackout ROM. The min_cpu_load it too close to max_cpu_load.
Before we set the max_cpu_load and min_cpu_load in our current project, we should also discuss ramp_up and ramp_down steps.
Setting max_cpu_load, min_cpu_load, ramp_up_step and ramp_down_step.
Previous post was on setting cpu thresholds.
Lets go back to our previous example:
CPU Frequencies:
122 MHz
245 MHz
368 MHz
768 MHz
806 MHz
1024 MHz
max_cpu_load = 55
min_cpu_load = 25
ramp_up_step = 200000
ramp_down_step = 300000
Click to expand...
Click to collapse
Ramp up
Starting at 245 MHz, with these settings when the CPU use hits greater than 55%, the processor will ramp up 200000 Hz or 200 MHz.
From 245 MHz to 445 MHz. Since there is no 445 MHz setting, it will go to the closest which is 368 MHz.
From 368 MHz it will ramp up to 568 MHz. There being no 568 MHz frequency it will go to 768 MHz.
From 768 MHz it will ramp up to 968 MHz. There being no 986 MHz frequency it will go to 1024 MHz.
Click to expand...
Click to collapse
Ramp down
Starting at 1024 MHz, with these settings, when the CPU use goes below 25%, the processor will ramp down 300000 Hz or 300 MHz.
From 1024 MHz to 768 MHz.
From 768 MHz it will ramp up to 368 MHz.
From 368 MHz it will ramp up to 245 MHz.
Click to expand...
Click to collapse
In computing you max_cpu_load and min_cpu_load, you should consider the settings to determine which speeds you should use to calculate:
cpu frequency x cpu_min_load for the higher speed
BE HIGHER THAN
cpu frequency x x cpu_max_load for the lower speed
Click to expand...
Click to collapse
Commands to set max_cpu_load, min_cpu_load, ramp_up_step and ramp_down_step.
The commands are:
echo '%' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo '%' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo 'HERTZ' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo 'HERTZ' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
Going back to our current project the settings could look like this:
#!/system/bin/sh
# - sysctl -p
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo '368640' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo '1200000 1100' > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo '400000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
echo '75' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo '30' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo '150000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo '200000' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
Click to expand...
Click to collapse
Next lets us go to up_rate_us and down_rate_us.
up_rate_us/down_rate_us
The up_rate_us setting dictates how much time the phone will stay at a frequency before ramping up. It only applies after reaching the awake ideal frequency when the screen is on, and the sleep ideal frequency when the screen is off.
To understand this better, let us assume the following settings:
CPU Frequency: 245 MHz to 1200 MHz
Available Frequencies: 245 > 368 > 806 > 1024 > 1200 MHz
Awake ideal frequency: 1024 MHz
Sleep ideal frequency: 368 MHz
Max CPU Load: 60%
Min CPU Load: 25%
Click to expand...
Click to collapse
If the processor is running a 245 MHz, and detects a load it will go from 245 MHz to 368 MHz to 768 MHz to 1024 MHz as soon as CPU load hits 60%. When it hits the awake ideal frequency of 1024 MHz it will not go up to 1200 MHz even if the CPU usage hits 60% unless it has spent as least X number of microseconds at 1024 mHz. This X number of seconds is the up_rate_us setting.
up_rate_us is set in microseconds. For example if, up_rate_us is set at 48000 (48,000 microseconds = 0.048 seconds).
In our example, the up_rate_us setting keeps the phone at 1024 MHz for at least 0.048 seconds before ramping up to 1200 MHz. The higher the setting, the more conservative the processors behavior will be.
down_rate_us works in the same way, but it reverse. If forces the cpu to stay at a frequency for a given number of milliseconds before ramping down WHEN BELOW THE IDEAL FREQUENCY.
Given out example. With the CPU at 1200 mHz. Once CPU use hits 25%, it will ramp down immediately. Once it hits 1024 mHz or lower, it will ramp down only after it has spent as least X number of microseconds at a frequency. The lower the down_rate_us setting, the more conservative the processors behavior will be.
Command to set up_rate_us/down_rate_us
echo 'MICROSECONDS' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_rate_us
echo 'MICROSECONDS' > /sys/devices/system/cpu/cpu0/cpufreq/smartass/down_rate_us
I have not spent much time experimenting with these settings.
thanks for your good work:
but it's seem you are wrong when mentioned: "You will find the smartassV2 settings in /sys/devices/system/cpu/cpu0/cpufreq/smartass"
actually its locaton will be /sys/devices/system/cpu/cpufreq/smartass
another question is what's about value : /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
mind it sets to 9999999, very strange
So, I made this script
68ioshcedinit:
Code:
#!/system/bin/sh
# - sysctl -p
echo "noop" > /sys/block/mmcblk0/queue/scheduler;
echo 'smartassV2' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor;
echo '1200000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
echo '245760' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
echo '245760' > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo '768000' > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo '806400' > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq;
echo '55' > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo '30' > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo '200000' > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo '300000' > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
Sorry, cpu0 is a typo. A bit too much cut and paste on my part.
9999999 basically tells it to ignore that setting. If you place a valid frequency in that setting, the processor will jump to that speed when you wake the phone.
Sent from my Desire HD using xda premium
Thanks a lot for this guide. I didn't want an app to control my kernel as it feels like it slows the phone down (maybe placebo) I made a script to set my Gov, CPU max/min and I UV all of my CPU freq all worked perfect. I didn't make a .zip I just made the file and copied into the init d folder and set permissions. One thing I did do wrong though was I didn't convert the file so it didn't work, I found this in another guide ''Edit-->EOL Conversion-->UNIX/OSX Format'' when I started notepad ++ it wasn't automatically set to this. Hope this helps someone and thanks a lot for this, now I just need to decide if I was a custom MM ROM or stock MM with xposed
Introduction:
Hey there, this thread is all about sharing profile setups for our beloved G3.
Feel free to share your settings too or PM me and i link it straight to the second post
A few things explained:
Android Modders Guide ( thanks to @gsstudios )
Explanation of LMK & Adj and Minfree settings ( thanks to @Papa Smurf151 )
What is ZRAM and how does it work??? ( thanks to @-CALIBAN666- )
How to apply Synapse Profiles:
Code:
- Unzip
- Move .tgz file to your Internal storage > Synapse > saved_profiles
- Profile > Profiles > choose .tgz file > press "check-mark" and not "X" > choose "restore profile"
- Synapse will restart and then press "X"
- Check all values and if you have to change something press "check-mark"
How to reset Synapse Profiles:
Code:
tools > clear synapse data > restart device > start synapse > choose "check-mark" = stock values
--= Android 5.x.x Profiles =--
gr3ud´s synapse profiles:
R21 Profile with EuphoriaOS & 777 Kernel ( thanks to @777jon )
--> Old/Experimental/Beta Profiles - Android 5.1.1 @ 777Kernel (R21)
--> Old/Experimental/Beta Profiles - Android 5.1.1 @ 777Kernel (R15 - R20)
--= Android 6.x.x Profiles =--
gr3ud.6.0.1.V1 - Alucard + Alucard Hotplug
http://pastebin.com/jEKAmYVZ
CPU:
- MSM Limiter: Disabled
- min: 300MHz
- max Freq: 2457 MHz
- Governor: Alucard
- CPU Tunables:
> cpus_down_rate: 4
> cpus_up_rate: 1
> freq_responsiveness: 2256
> sampling_rate: 50000
- Multicore Powersaving: Disabled
- CPU Boost: Interval: 0ms / Sync Threshold: Disabled / Input Interval: 1000ms / Input Boost: 1958 MHz
CPU Voltage (optional for extra battery):
- Global Offset: -25 (stable, tested with Antutu)
HOTPLUG:
- Alucard Hotplug
- Sampling Rate: 50%
- Prevent to Suspend: Disabled
- Minimum CPUs Online: 4
- Maximum CPUs Online: 4
- Max Cores Screen Off: 2
THERMAL:
(optional) Thermal Compound Cooling Mod -> https://www.youtube.com/watch?v=PH5wCeootNI
- Intellithermal Enabled
- Core Control OFF
- Freq Throttle Temp = 75°c
- Core Throttle Temp = 80°c
GPU:
- min. freq.: 330
- max. freq.: 547
- Governor: msm-adreno-tz
- Simple GPU Algorithm: Enabled
- Laziness: 10
- Ramp Threshold: 0
- Adreno Idler: Disabled
SCREEN ("personal preference/vibrant colors"):
- Saturation Intensity: 60
- Screen Value: 120
- Screen Contrast: 148
I/O:
- Internal Storage: ZEN (128 kB)
- Rotational Storage: Off
- Add Random: Off
- I/O Stats: Off
- RQ Affinity: 0
KSM:
- Disabled
LMK:
- Adaptive Low Memory Killer: Disabled
Virtual Memory:
- Laptop Mode 1 = more performance but can cause random reboots (use this only with stable builds)
- Z-RAM: Disabled
Misc Controls:
F-Sync: Disabled = more performance but can cause random reboots and data loss ( use this only with stable builds)
★ souler456´s profile - Slim + IntelliPlug ★
http://forum.xda-developers.com/showpost.php?p=66659439&postcount=343 ( thanks to @souler456 )
1st
gr3ud said:
List of shared profiles:
My profile with 777 Kernel (R21) + Euphoria-OS 1.1 (Android 5.1.1) (thanks to @777jon ):
- Performance Profile (aka " almost Nexus smooth")
- Not very battery friendly (~3h - 5h SOT with default 3000 mAh battery)
- I don't know how it works out for "Gamers" because i just run simple 2D games when i got the time for that.
- Please don't expect too much, this works for me and my daily usage.
- Enjoy
Setup Values:
CPU:
min: 345 MHz
max: 2457 MHz
MSM Limiter: Disabled
Debug Mask: OFF
Suspend Min Frequency: irrelevant but 345 MHz
Resume Max Frequency: irrelevant but 2457 MHz
Suspend Max Frequency: irrelevant but 2457 MHz
Suspend Defer Time: irrelevant but 0
Input Boost Frequency: 2457 MHz
Boost interval: 5000 ms
Min Input Interval : 100ms
Maximum CPUs Boosted: 4
Multi-core Power Saving: OFF
Arch Power: OFF
CPU Governor(0-3): Nightmare
HOTPLUG:
Msm Hotplug Driver: Enabled
min: 4
max: 4
boost: 4
Screen Off: 2
Boost Lock: 5000 ms
Down Lock Duration: 5000 ms
History Size: 1
Fast Lane Load: 0
Offline Load: 0
Suspend Defer Time: 0
Thermal: ( I use "thermal paste/copper shim mod" so you may choose higher values without)
Intellithermal: Enabled
Core Control : Enabled
Frequency Throttle Temperature: 80c
Core Throttle Temperature: 85c
I/O:
Read-ahead Size: 1024 KB
I/O scheduler: zen
CRC Control: OFF
MMC Clock Scaling Control: ON
Add Random: OFF
I/O Stats: OFF
Rotational: OFF
No Merges: All
RQ Affinity: Disabled
NR Requests: 128
GPU:
GPU min Frequency: 27 MHz
GPU max Frequency: 657 MHz
GPU Governor: Performance
All Add-on´s : Off
GAMMA:
Saturation: 270
Memory(experimental): (beta = ** stock values)
Z-RAM: 0 MB
Dirty Background Ratio: 80% (**5%)
Dirty Ratio: 90% (**40%)
Dirty Expire Centisecs: 200 cs
Dirty Write-back Centisecs: 500 cs
Drop Caches: ON
Extra Free KB: 49050 kB (**43200 kB)
Laptop Mode: ON
Swappiness: 60% (**10%)
VFS Cache: 10% (**100%)
Misc:
TCP: cubic - westwood or what you desire.
How to test:
Run net speed tests with each protocol at least 3 times to compare the average with this Speedtest App
Power Suspend Mode: LCD Hooks
FSYNC: ON
ADV:
Krait-C States: All ON
KSM: ON
Pages to Scan: 128
Scan Delay Interval: 750
Deferred Timer: OFF
Gentle Fair Sleepers: OFF
Adaptive LMK: OFF
Build.PROP:
Wifi Scan: 300 sec
VM Heapsize: 512 MB
Allow purging of assests: OFF
Tools:
SELinux Status: Permissive
--------------------------
Click to expand...
Click to collapse
Nice to see you made a thread bro
Well, this is the perfect place to share your "imagination". Great
Sent from my LG-D855 using Tapatalk
? ? ? much appreciated effort here ? ? ?
Thank you for creating a profile thread!
Got 40066 in Antutu yesterday on your 30th October set up.
Got this today with the 31st October.
Might not sell my G3 for a OnePlus X now.
johnnzey said:
Got 40066 in Antutu yesterday on your 30th October set up.
Got this today with the 31st October.
Might not sell my G3 for a OnePlus X now.
Click to expand...
Click to collapse
Hey mate glad to hear, i would personally wait for custom 6.x.x ROMs/Kernels for our device tho before moving on
To all others, thanks for your kind words i appreciate it
But without @m1trand1r and @metalgearhathaway motivating words + all the other dudes that dig my work, this thread would not exist :good:
Cheers.
Just applied your settings, great! Never had such a smooth G3! Thanks for the update!
What settings do you use for Marshmallow?
@6th_Hokage
Well since Synapse does not play nice for me and i generally have some weird issues with custom kernels on 6.x.x ROMs (Overheating,BSODs,Crashes,Random Reboots,etc) i decided to use the ROMs respective kernel.
I�´m trying Broken OS right now and they know their stuff pretty well.
They have Kernel Adiutor inbuilt so i basically switched just a few things...like:
- zzmove CPU gov with profile 8 and its inbuilt hotplug, changed the "punch freq" to 2457MHz
- CPU Boost/Interval 5000ms, Sync/Boost Freq. @ 2457MHz
- GPU min/max 587MHz with msm adreno gov
- I/O: row or zen @ 512kB
- Kernel Sampage Merging with 300 pages / 1000 ms scan
- I disabled Adaptive LMK
- Enabled Laptop Mode
- Entropy: Read 128 / Write 256
...and that's pretty much it, its not battery friendly but i don't care for battery life, still got 4hs of SOT with that setup... Lionheart works well too on 6.x.x also does smartmax , so yeah, its butter smooth as i like it for now, i miss KCAL stuff tho, but this ROM (BrokenOS) is still in alpha phase so there will be much more stuff added in the next releases from what i�´ve read on G+
I�´m also waiting for Eliminater74�´s own Kernel Manager, then i will play around with hes kernel i guess so stay tuned :good:
Also, some users mentioned that my 5.1.1 profile works very well for them on 6.x.x maybe give it a shot.
edit:
I forgot to mention that i also disable the default hotplug with Lionheart or smartmax to have all 4 cores permanent online for a little extra performance boost.
Thanks bro. Good job.
*Android 6.x.x update*
http://pastebin.com/jEKAmYVZ
Thank you for the excellent kernel setup for Marshmallow. My G3 is so much smoother than before. I give it a two thumbs up.
**Android 7.x.x Update**
CPU:
- MSM Limiter: Disabled
- min: 300 MH
- max Freq: 2457 MHz
- Governor: Nightmare
- Multicore Powersaving: Disabled
- CPU Boost: Interval: 0ms / Sync Threshold: Disabled / Input Interval: 2500ms / Input Boost: 2265 MHz
HOTPLUG:
- All Disabled
THERMAL:
(optional) Thermal Compound Cooling Mod -> https://www.youtube.com/watch?v=PH5wCeootNI
- Delete "Thermal-Engine" under system/bin
- Intellithermal Enabled
- Core Control Disabled
- Freq Throttle Temp = 75°c
- Core Throttle Temp = 80°c
GPU:
- min. freq.: 330
- max. freq.: 578
- Governor: msm adreno-tz
- Simple GPU Algorithm: Disabled
- Adreno Idler: Disabled
SCREEN ("personal preference/vibrant colors"):
- Saturation Intensity: 55
- Screen Value: 125
- Screen Contrast: 140
I/O:
- Internal Storage: bfq
- Read-ahead: 512 kB
- Rotational Storage: On
- Add Random: Off
- I/O Stats: Off
- RQ Affinity: 0
KSM:
- Disabled
LMK:
- Adaptive Low Memory Killer: Disabled
Virtual Memory:
- Laptop Mode = Disabled
- Z-RAM = 500 MB (16/2GB model only)
Misc Controls:
F-Sync = Enabled
gr3ud said:
**Android 7.x.x Update**
CPU:
- MSM Limiter: Disabled
- min: 300 MH
- max Freq: 2457 MHz
- Governor: Nightmare
- Multicore Powersaving: Disabled
- CPU Boost: Interval: 0ms / Sync Threshold: Disabled / Input Interval: 2500ms / Input Boost: 2265 MHz
HOTPLUG:
- All Disabled
THERMAL:
(optional) Thermal Compound Cooling Mod ->
- Delete "Thermal-Engine" under system/bin
- Intellithermal Enabled
- Core Control Disabled
- Freq Throttle Temp = 75°c
- Core Throttle Temp = 80°c
GPU:
- min. freq.: 330
- max. freq.: 578
- Governor: msm adreno-tz
- Simple GPU Algorithm: Disabled
- Adreno Idler: Disabled
SCREEN ("personal preference/vibrant colors"):
- Saturation Intensity: 55
- Screen Value: 125
- Screen Contrast: 140
I/O:
- Internal Storage: bfq
- Read-ahead: 512 kB
- Rotational Storage: On
- Add Random: Off
- I/O Stats: Off
- RQ Affinity: 0
KSM:
- Disabled
LMK:
- Adaptive Low Memory Killer: Disabled
Virtual Memory:
- Laptop Mode = Disabled
- Z-RAM = 500 MB (16/2GB model only)
Misc Controls:
F-Sync = Enabled
Click to expand...
Click to collapse
thank you,,with those do you get decent battery..
jlb1959.01 said:
thank you,,with those do you get decent battery..
Click to expand...
Click to collapse
It's okay, was not really my intention to save battery juice.
gr3ud said:
It's okay, was not really my intention to save battery juice.
Click to expand...
Click to collapse
thanks,looking for mid point settings,both perform and some kind of battery..thanks again..
jlb1959.01 said:
thanks,looking for mid point settings,both perform and some kind of battery..thanks again..
Click to expand...
Click to collapse
Hmm try my 6.x.x alucard profile then, had some good experience with it. No problem btw you welcome
gr3ud said:
Hmm try my 6.x.x alucard profile then, had some good experience with it. No problem btw you welcome
Click to expand...
Click to collapse
I will try it,,much appreciated..