Related
{
"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"
}
SysTune
Optimize under the hood of your system!
** Root Rights required!!! **
This is a system tuning and tweaking tool for advanced users with root access. It allows you to change various system settings to optimize your system.
This is my very first App on the Market. I am open for feedback and try at my best to solve any requests if possible.
It is very advised to properly inform yourself about those settings as i do not take any responsability for any damamge to your device.
NEW FEATURE
Changing priority of processes allows you to prevent lagging or other issues e.g. when a back ground process slow down your phone or you forground app has struggles to do its fluently.
See Help Tab for more informations before using this feature! More Informations and a small Guide will be available in the second or third post in the next days.
Note: The background service for monitoring processes to renice them causes no increased battery drain!
Features:
Changing min/max CPU frequency
Changing cpu governor
Changing advanced governor settings
Voltage Control (SVS and HAVS supported)
Block device settings like IO-Scheduler
Kernel (Scheduler) Tweaks
VM Tweaks
Changing priorities of active processes (renice)
Apply on Boot
Mulit-Core / -CPU support
Realtime CPU Clock Speed and "Time in State"-View of each Core/CPU
Save and load settings individually for each tab (press Menu).
Multi-Core/-CPU supporting CPU Stress Test (New)
Safe Mode ( see in-app Help for Informations )
..... more to come!
NOTE: The availability of the features depends on your system. E.g. if your installed kernel does not provide access to VDD Levels voltage control than it won't be available.
After installation take your time and read the informations on the Help-Tab.
Download on Market
************************************************
If somethings is not working as expected on your device
please post here or email me so that i can fix it for you!
I don't own every device out there
************************************************
The zip file for toggling Safe Mode that can be saved on your SD Card via the button in SysTune can also be found here attached to this post.
Thanks to...
Grzesiek Baran for the new Market Feature Image and his Status Bar Icons!
"The Unknown Noob" aka Daniel S. for his Status Bar Icons!
Download User Settings
This is a section with user contributed settings files for SysTune. Anyone can submit their settings via attachment to a post.
Though i beg to follow some basic rules:
Tell which device, rom (version) and Kernel used
IMPORTANT: Date (and optinal a version number) of your settings. So we now if there was a modification meanwhile!
Short but clear explenation why you use this values
What you did to come to the conclusion to use them
[OPTIONAL] What you changed over the default values of your rom/kernel. (note which were the default values before the change!)
Please follow the rules to make it easier for others to judge if your settings are usefull for them.
A user's settings for CM 10.1 for DHD rom:
Device: Desire HD, Rom: [ROM][UNOFFICIAL] CyanogenMod 10.1 Nightlies / M-Series - nightly from 20.02.2013
Date: Feb., 20, 2013
No renicing used anymore
Using stock clocks and ondemand governor.
Ondemand Governor settings
Misc settings
A user's settings:
Device: Desire HD, Rom: SCI MIUI 1.11.25v1.0, Kernel: lordmod 8.5 cfs
Date: Nov., 30, 2011
Smoother and more battery friendly then default values.
I am using several benchmark apps to test different aspects. Also i am testing overall daily usage. For reliable tests i have some things i repeat to see how the impact of changes of the settings is. Benchmarks used are: NenaMark 2, An3DBenchXL, Quadrant (not very good though), AnTuTu, TAP Benchmark (for internal flash memory), SD Tools (for sd card).
CPU Settings: ondemand
Governor settings
Misc settings
For BFS kernel version use set rr_interval=2 in the misc tab under kernel settings. But for my Rom i stick to CFS currently.
Renice Settings
Some general tips:
The priorities influence the behaviour when two processes that want to do some work at the same time. It influences which process will get more cpu time, thus it may cause lags for the lower priority process.
So in general the default priority of 0 is the one you should keep for most of the processes. But there are some processes that maybe you are not using all the time, but when you want them to use you want them fast and lag free.An example for this is the "phone" process but also the systemui process can improve the behaviour of your GUI in general.
On the other side there are processes that need to do some work in the background. Such process could slow down or cause lags on your currently used app / foreground process. An example for this is the media scanner "android.process.media". Think of reducing its priority to prevent slowing down other things. You won't care if the media scan in the background would need a minute longer to finish if you get a more fluent foreground app
I also got user reports for apps like media players that since they increased their priority now work flawless.
A User's Renice Settings 12 Dec. 2011 (see used rom etc. above!)
Notess:
I increased the the priority for processes that need to respond fast when they actually are needed, like the phone process.
I also increased the priority of my keyoard app to improve its pop upp in some seldom but annoying situations. If you use more than one keyboard app just set an increased value of all of them. As you never will use two at the same time you do not need to decrease the priority of one of them
Beside of other stuff i also increased the priority of my used launcher, adw ex. Add your launcher or replace my entry with one for your launcher. I think com.android.launcher is the process name for the standard launcher. But as you are using it you can see its process in the list of the "add" dialog.
strange, where has the reply of user sergeybrin gone?
anyway, am open for suggestions and reports of issues. if anybody has tried it found that something is not working for their phone i would be thankfull to know what so i am able to fix that.
Optimal settings for LordMod 7.2BFS kernel
Hi a user thanks for the great app.
I'm on Alienmod's CM7 (nightly 208) with LordMod's 7.2BFS kernel and was wondering what the optimum settings are in the "Governor" tab?
I looked at your MIUI thread and saw that you have:
suspend_freq @ 614400
down_differential @ 15
sampling_down_factor @ 50
ignore_nice_load @ 0
up_threshold @ 85
powersave_bias @ 50
sampling_rate @ 80,000
io_is_busy @ 1
so I am using these settings and everything seems ok.. (im using ondemandX 230400min and 1152000max).
Are these settings ok to use for my ROM or are there better settings?
Also i'm currently -50mV undervolted.
Thanks!!
this are still the settings i use and i think they pretty much optimal for aosp roms for the dhd. edit: except that my max fre is 1075MHz
regarding undervolting: carefull and you should only undervolt one freq at a time then test that extesively (e.g. by setting min and max freq to it and running something stressing the cpu for a longer time).
in general it is only needed to undervolt the freqs close to your set max freq as undervolting only makes a significant difference on consumption if there is high load. and on high load your phone switches to higher freqs
p.s. glad you are happy with the app.
I recently discovered due to a nice customer that despite googles license code documentation the licensing server do not provide validation timeout infos. hence some customers may observed that the app failed licensing on connection issues.
Google documentation on this claimed it should work as i expected but it doesn't. Hence i just fixed this now myself and want to apologise for any issues caused by this. I will improve this further in the near future.
Great App
thank you!
@all: There are many roms out there with broken busybox installations. i already have some workaround built in to handle that. i just discovered that one of my workaround had a typo. so if someone tried the app and saw it not working as it should it probably got fixed with the most recent update to 1.2.6.
i would like to see why some people are cancelling the purchase as it is already possible to see exactly what it does on the screen shots. If something is not working as it should i can't fix it without feedback. too many roms and devices out there to have them all and being able to test against.
I've tested unsuccessfully on the tmo g2x running EaglesBlood latest (cm7 based) and the dragon kernal. By testing I mean the drop downs for CPU Max and min show a thin white bar with nothing selectable.
Edit: tested with another kernal, and my guess is they don't support your method for accessing the processors... but I've been wrong before.
thank you for the feedback. But i need the info provided by the feedback button. Please use the feedback button on the help tab to collect some information and send it via email.
if you do not want to send me an email you canstill use that button. it will collect some infos and save them on your sdcard as "systune.inf". cancel the email that opens up. the file will still remain on your sdcard.
attach it here to your next post (maybe you need to rename its extension to .txt). without that info there is nothing i could do.
p.s. you can look into that file to verify that nothing confidential is collected. it is plain text.
EDIT: i saw your edit. does this mean with the other kernel it worked? basically your guessing seems right. but the thing is that my method to acces this values is the ONLY one possible. it is done through the kernel exported values in the sysfs. this is basically the only way to access kernel values at runtime. this custom kernel(s) you are using are either not exporting these stuff or they are doing wrong (by convention).
in the latter case at least i could do a workaround to compensate for their wrong placement of the stuff.
The Load Settings dialog box is not working on BlackIce, same problem as I had on Hydr0g3nmod before. Box just displays Cancel and nowhere to select a file to load. Not critical but would be nice to have. Probably due to the super dark theme. Thanks!
Sent from my Desire HD using Tapatalk
cold y verify that it is indeed only due to the theme? i mean try pressing in the middle of the box where normally the entry of a file to load is located and see if it loads.
if it is just a theme issue, dark text on dark background, then you should inform paradoxx or alienmind about this as this is a bug on their rom. i am simpy using system default theme.
usefull for them to know is that the items to load are listed in a ListView using "android.R.layout.simple_list_item_1" for the items. With these infos they should be able to fix their theme.
p.s. new version with new features coming very soon.
a user said:
cold y verify that it is indeed only due to the theme? i mean try pressing in the middle of the box where normally the entry of a file to load is located and see if it loads.
if it is just a theme issue, dark text on dark background, then you should inform paradoxx or alienmind about this as this is a bug on their rom. i am simpy using system default theme.
usefull for them to know is that the items to load are listed in a ListView using "android.R.layout.simple_list_item_1" for the items. With these infos they should be able to fix their theme.
p.s. new version with new features coming very soon.
Click to expand...
Click to collapse
Thanks, no luck in finding the hidden dialog box but no big deal.I'll wait until the BlackIce theme fix is done, or who knows perhaps I'll be back on sci miui by then
Sent from my Desire HD using Tapatalk
New version with new features available.
Now it supports various kernel tweaks (cfs scheduler tweaks) and vm tweaks. You can find them in the Misc Tab. Also saving/loading is now available for the Misc Tab.
Hi my8,
Do you think that it could be useful to discuss our findings about the tuning of some parameters here or in another section?
Thanks for your VERY useful app.
normally i would say this should be in a device specific thread. but because i wont be allowed to open up a systune thread in each device subforum i think we could do it here.
so feel free to be the first.
as basic rules i think one should always include infos about device/rom/kernel to make the post actually usefull.
new version 1.3.2:
added tunable paramter for BFS kernels in the Kernel settings section under the Misc tab.
a user said:
normally i would say this should be in a device specific thread. but because i wont be allowed to open up a systune thread in each device subforum i think we could do it here.
so feel free to be the first.
as basic rules i think one should always include infos about device/rom/kernel to make the post actually usefull.
Click to expand...
Click to collapse
Ok thanks for that and also for v1.3.2.
I think also that here could be a good place for the discussion of some of the tunable parameters via systune app. Indeed, I think that there should be no such big difference from ROM to ROM (but probably more from device to device...).
This offers also the possibility to give (and get) some information about the parameters that are tunable via Systune.
Among the different group of parameters, due to personal interest, I want to focus on scheduler ones (CFS and now BFS (since v1.3.2)).
And first of all, some theory, because before tuning anything, it is EXTREEMELY IMPORTANT TO UNDERSTAND the meaning of these parameters: here below is a partial copy of http://doc.opensuse.org/products/opensuse/openSUSE/opensuse-tuning/cha.tuning.taskscheduler.html about CFS in opensuse distribution.
NB: I am not an expert in Android, but IMHO I thing that even if Android runs on linux, it must be a lot of difference between running a phone and a desktop. It is why, it is interesting to have this kind of discussion here.
The comment are personal and are there just to start the discussion....
My phone is a HTC Desire HD, with blackIce ROM with LordMod UE kernel v8 CFS.
sched_child_runs_first
A freshly forked child runs before the parent continues execution. Setting this parameter to 1 is beneficial for an application in which the child performs an execution after fork. For example make -j<NO_CPUS> performs better when sched_child_runs_first is turned off. The default value is 0.
OK default value seems logical for me.
sched_compat_yield
Enables the aggressive yield behavior of the old 0(1) scheduler. Java applications that use synchronization extensively perform better with this value set to 1. Only use it when you see a drop in performance. The default value is 0.
OK default value seems logical for me, but Dalvik being a Java VM, 1 could also be logical ?????
Expect applications that depend on the sched_yield() syscall behavior to perform better with the value set to 1.
sched_migration_cost
Amount of time after the last execution that a task is considered to be “cache hot” in migration decisions. A “hot” task is less likely to be migrated, so increasing this variable reduces task migrations. The default value is 500000 (ns).
If the CPU idle time is higher than expected when there are runnable processes, try reducing this value. If tasks bounce between CPUs or nodes too often, try increasing it.
In case of single core processor, IMHO I think that this value must be set high....
sched_latency_ns
Targeted preemption latency for CPU bound tasks. Increasing this variable increases a CPU bound task's timeslice. A task's timeslice is its weighted fair share of the scheduling period:
timeslice = scheduling period * (task's weight/total weight of tasks in the run queue)
The task's weight depends on the task's nice level and the scheduling policy. Minimum task weight for a SCHED_OTHER task is 15, corresponding to nice 19. The maximum task weight is 88761, corresponding to nice -20.
Timeslices become smaller as the load increases. When the number of runnable tasks exceeds sched_latency_ns/sched_min_granularity_ns, the slice becomes number_of_running_tasks * sched_min_granularity_ns. Prior to that, the slice is equal to sched_latency_ns.
This value also specifies the maximum amount of time during which a sleeping task is considered to be running for entitlement calculations. Increasing this variable increases the amount of time a waking task may consume before being preempted, thus increasing scheduler latency for CPU bound tasks. The default value is 20000000 (ns).
For a phone running with a processor > 1GHz I thing that 5000000 is a good value (to be discussed further)
sched_min_granularity_ns
Minimal preemption granularity for CPU bound tasks. See sched_latency_ns for details. The default value is 4000000 (ns).
Same as above with a suggested value of 1000000
sched_wakeup_granularity_ns
The wake-up preemption granularity. Increasing this variable reduces wake-up preemption, reducing disturbance of compute bound tasks. Lowering it improves wake-up latency and throughput for latency critical tasks, particularly when a short duty cycle load component must compete with CPU bound components. The default value is 5000000 (ns).
Same as above with a suggested value of 1000000
sched_nr_migrate
Controls how many tasks can be moved across processors through migration software interrupts (softirq). If a large number of tasks is created by SCHED_OTHER policy, they will all be run on the same processor. The default value is 32. Increasing this value gives a performance boost to large SCHED_OTHER threads at the expense of increased latencies for real-time tasks.
IMHO must be sed = 0 for single core processor....
[To be continued later.....]
I know this article already but good you posted it here.
Based on my understanding an tests i have the following suggestions:
Sched_compat_yield set to 0 seems to improve performance. Note this is not a java virtual machine. This is only based on my tests
Sched_latency_ns : I recently am testing very low values. Currently using 390000 and 130000 for the two granularity parameters.
It seems smoother without losing raw throughoutput performance.
Regarding the migration parameters.... we are running a single core device. hence I think it simply doesn't matter what values we have set there as no task will ever switch the CPU it is bound to.
But a test if set to 0 can reduce some overhead could be a worth try.
Sent from my HTC Desire HD using XDA App
a user said:
I know this article already but good you posted it here.
Based on my understanding an tests i have the following suggestions:
Sched_compat_yield set to 0 seems to improve performance. Note this is not a java virtual machine. This is only based on my tests
Sched_latency_ns : I recently am testing very low values. Currently using 390000 and 130000 for the two granularity parameters.
It seems smoother without losing raw throughoutput performance.
Regarding the migration parameters.... we are running a single core device. hence I think it simply doesn't matter what values we have set there as no task will ever switch the CPU it is bound to.
But a test if set to 0 can reduce some overhead could be a worth try.
Sent from my HTC Desire HD using XDA App
Click to expand...
Click to collapse
Ok and thanks for your answer even if I don't totally agree with your proposal.
Indeed, I think that going down to so small value could be a little bit risky in term of CPU load and throughput for processor bounded task (I know that they are quite unimportant in a phone). Nevertheless, I am now testing Sched_latency_ns 1000000 and 250000 for the two granularity parameters...
Now some words about BFS ( Brain **** Scheduler) introduced recently by M. Kolivas (see article here: http://ck.kolivas.org/patches/bfs/sched-BFS.txt).
"It was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. ie it is a desktop orientated scheduler, with extremely low latencies for excellent interactivity by design rather than "calculated", with rigid fairness, nice priority distribution and extreme scalability within normal load levels."
Here the only tunable parameter is rr_interval that is roughly equivalent to the latency [in ms]. The default value = 6 [ms] that seems ok for me (possible values 1 -> 1000).
[to be continued...]
I have read somewhere that there is a cap of 30 FPS in android devices. Also, that higher fps will lead to more smooth transitions etc. Is this correct?
Moreover, even if the above is right or wrong.. is there any way to change fps value in android?
You can increase UI smoothness with app called AutoKiller Memory Optimizer. Open it and go to Advanced system tweaks and turn the UI optimization tweak on. Not sure if this increases FPS? But it still gives smoother UI.
V07A4ER said:
You can increase UI smoothness with app called AutoKiller Memory Optimizer. Open it and go to Advanced system tweaks and turn the UI optimization tweak on. Not sure if this increases FPS? But it still gives smoother UI.
Click to expand...
Click to collapse
This'll just help in having a certain amount of RAM free at all times so that phone doesn't become laggy.. it doesn't increase FPS value...
I always have 70-80+ MB RAM free so this won't help much..
AFIK windows phone and Iphone have an FPS of about 60 and android has an FPS of 30.. that's why those phones have much smoother UI ..
I want to first thank Hashcode, Jonpry, and everyone else that has worked to get Kexec working on our phone (props for Kholk too). I decided to add some tweaks to the build prop to enhance my experience with a rom. Please note that there are no magical tweaks that would make your phone perform even better but my tweaks seem to have a positive effect on a thing here and here. My build prop is attached to the forum below. I have also included in this post what additional tweaks I've added, and what they do. If you have any good tweaks, I will add them to the list! At this moment this is CDMA only, you will have to add GSM tweaks to this build prop for those using GSM.
Code:
ro.telephony.call_ring.delay=1500
My Tweak: Originally set to 3000ms I halved to 1500.
Reason: This reduces the lag while dialing out.
Code:
wifi.supplicant_scan_interval = 180
My Tweak: The scan interval was originally set to 90. I upped it to 180.
Reason: This determines when our phones will scan for remembered access points. The higher the number, the longer the interval of scans. This is important if you often forget to turn off your wifi, like me.
Code:
ro.max.fling_velocity=11750
ro.min.fling_velocity=7500
My Tweak: Faster scrolling
Reason: Faster and Furiouser.
Code:
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
ro.config.nocheckin=1
My Tweak: Disables Error checking and sending of usage data.
Reason: In the basics of computers there are 1's and 0's. 1 means on or yes and 0 means no or off, an interesting fact is that most power button symbols show a 1 inside a 0. I disabled all error checking because it would likely use a little less resources and add some stability for some apps. Some people have been reporting issues with Angry Birds and other games kicking them back to the desktop. If an app that worked before this tweak constantly does not work (after a reboot), remove the first two lines. ro.config.nocheckin just sends usage data.
Code:
persist.adb.notify=0
My Tweak: Disables notification for debugging
Reason: My phones is always set to USB debugging, I don't need to be reminded. This just disables the notification in the notification bar.
Code:
dalvik.vm.dexopt-flags=m=v,o=y
persist.sys.purgeable_assets=1
My Tweak: More aggressive but reasonable RAM management
Reason: Your phone will be less likely to think that something is still in use when it is actually not being used. This will free up more ram but it will force the phone to use a little bit more of the processer from time to time. Our phones actually have a decent processer but they lack ram. I've noticed some RAM heavy apps perform a little better after this tweak. persist.sys.purgeable_assets=1 is an option I found in CM9 roms seems to be used quite often (will remove if problems occur).
Tweaks that either do not work in ICS or do nothing at all.
Code:
Stagefright
Myth: Better media management and perfomance
Reason: While it is possible that this is true, Stagefright has been known to cause audio issues on Motorola phones. This may not be true on our ICS build but it's not needed due to the way ICS works. If you have a good reason to add it, I am willing to change my mind.
Code:
Heap sizes greater than 64
Myth: The bigger the heapsize the better, allowing apps to process faster and to improve multitasking.
Reason: Google's ICS default is 64 for devices that have 1024 ram or lower, anything higher will not do anything. Developers will never need more than 64 for their apps, unless they need to improve their coding.
Code:
ro.media.enc.jpeg.quality=90
ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000
Myth: A fair amount of people believe this will make our pictures, videos, and sounds load faster, stronger, and better.
Reason: It's already there! It would be redudant
Code:
dalvik.vm.execution-mode
Myth: Enables the execution of JIT, which makes the phone faster
Reason: JIT execution is enabled by default on ICS and some people say this is useless anyways.
Code:
windowsmgr.max_events_per_sec=##
Myth: Allows for inputs such as screen touches to be read faster
Reason: Google's default setting is 90. Android maxes out at 60fps, setting max_events too high could slow down the UI making it process way to many things that it shouldn't.
Code:
Magikarp uses Splash!
Myth: Splash is a water based attack so it should be super effective against the right opponent types
Reason: It does 0 damage, and just wastes time. Teach Magikarp a TM and use it until Magikarp evolves.
-------------------------------------------------------------------TESTING----------------------------------------------------------------------------------
The following code has not fully been tested, or I know little of it's effectiveness. I am in the process of testing.
Code:
debug.sf.hw=1
persist.sys.ui.hw=1
debug.performance.tuning=1
video.accelerate.hw=1
debug.egl.profiler=1
debug.egl.hw=1
debug.composition.type=gpu
Supposedly this will force the system to use the GPU for 2D frames in applications and make things smoother. I'm almost positive that this is built into the rom.
-----------------------------------------------------------------Install--------------------------------------------------------------------------------
***There are three build.props. builds.prop is Stable. BuildT.prop is my test build. Try it out at your own risk! Be sure to back up your original build prop. I have added it to the post as BuildO.prop just in case you need it. XDA will not allow extension .prop so I changed it to .txt****
To install it:
I am not responsible for anything that happens to your phone, you do this at your own risk.
1. Open your root explorer
2. Navigate to the very root of your phone
3. Go to System, and copy your original build.prop somewhere else or change the extension to .bak
4. Naviate to the build.prop you downloaded and copy it
5. Navigate back to root -> system and paste
6. Rename it to build.prop
7. Reboot.
* If problems occur, you can delete it and rename or replace it with the original but a build.prop has to be in there for it to reboot!
waiting for the gsm BUILD.prop
I will be looking into a downloadable GSM build.prop. In the mean time whatever method used to get GSM working on the stock Kexec build can be used on this build prop.
Sent from my XT862 using xda premium
I made an 883 prop thread in the General section if you want.
Sent from my XT883 using xda app-developers app
Hey guys and girls,
I don´t have time to maintain 2 threads. Look in the Pixel XL forums.
Link is here: https://forum.xda-developers.com/pi...kernel-0-1-t3554330/post70974321#post70974321
So this post will be dedicated to information about EAS in general.
here is a good summary which also goes into detail regarding sched and schedutil.
Another amazing write up about alucardsched by a talented new dev @joshuous:
This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.
Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.
Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.
How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.
Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.
Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):
This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.
As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.
AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.
This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.
helix_schedutil explained by @Kyuubi10
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity
Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.
Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:
"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load
"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.
Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.
The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8
If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".
Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.
Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.
Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.
Update to the explanation:
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.
The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)
The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50
Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.
correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.
While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.
As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.
The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.
Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core
here is some Information about pwrutil governor:
This new governor is based on schedutil.
A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.
Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).
UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
how to gather logs:
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Freak07 said:
Well it was confirmed working before.
Did anybody else flashed it successfully? And please follow my instructions in the op.
Click to expand...
Click to collapse
It worked for me by following instructions in the OP
Followed the instructions from OP, works fine for me!
Thanks for your works, try it out now
ne0ns4l4m4nder said:
Attemped install on Pixel, ended up with black screen after white "unlocked booloader screen" had to reinstall system and custom rom.
Click to expand...
Click to collapse
Working fine here following OP, thanks for another Kernel brotha!!
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Make sure to use supersu and not the inbuilt lineage superuser.
On rr it should run without an issue. At least it was reported in the xl thread.
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
TheBurgh said:
Currently rooted on 7.1.1 and haven't ventured away from stock. It should be good just to follow instructions and flash?
Click to expand...
Click to collapse
yes. Make a backup just in case. And use the latest supersu zip.
abunhyan said:
so idoes this kernal work better in lineage ROMS like hexa and Resurrection Remix v5.8.1 Roms ???
Click to expand...
Click to collapse
Running great on RR with latest SU ?
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
abunhyan said:
Running great in RR here also with 10% battery drain in 10 hour !!! thats great result
one thing tho double tap to weak function not working from lock screen at all!!!!
Click to expand...
Click to collapse
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Freak07 said:
What exactly is your problem?
You can enable dt2w in exkm. But the one that is in the rom will be overwritten as the kernel one works more reliable.
Click to expand...
Click to collapse
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
abunhyan said:
its Dt2w not functioning after installing the kernal and its was working well before that
can u explain how i can enable it?
and regard the sound control app can u advice which app i can use to enhance sound quilty by using Bluetooth headset
Thanks for ur great help:good:
Click to expand...
Click to collapse
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
hey guys and girls,
I have a new kernel now in testing. If I have no Issues I will post it in a few hours.
I added the possibility to use sdcardfs. big thanks to @DespairFactor here, he provided some help.
you just have to add ro.sys.sdcardfs=true to your build.prop
I tested it for two days now and encountered no issue. Using it may improve I/O performance.
here is some reading, in case you are interested:
https://www.xda-developers.com/divi...les-fuse-replacement-will-reduce-io-overhead/
I also added two new governors developed by @alucard_24, called alucardsched and darknesssched.
They are both based of on EAS. You may use them as an alternative to sched and schedutil.
I think alucardsched is more battery friendly. But I had quite a few stutters with it. Maybe you guys can give feedback on this.
shindiggity said:
Running great on RR with latest SU ?
Click to expand...
Click to collapse
Do you have I/0 options in your kernel manager? And are you using supersu, or the SU baked into the ROM?
Freak07 said:
For controlling dt2w use this app.
https://play.google.com/store/apps/details?id=flar2.exkernelmanager
You can find the option in the sector gestures. Just enable it and you are set.
Audio options are under sound.
The sound for bluetooth can only be altered via software mods like viper4android.
If you really care about sound quality you should use wired headphones. But the quality for bluetooth may be enhanced by default.
Click to expand...
Click to collapse
by dt2w, he means the stock android implementation where you double tap into the ambient display I think
Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz 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 710Mhz/864Mhz rates, 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 "710000" 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.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
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.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:
UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.
Is it valide for stock rom (6.0)?
lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.
Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.
New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.
I don't use SD card so what do I do?
razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.
Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
I will give this a try. Hope it works well...
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk
justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?