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...]
ok, nothing seemed to be making the touchscreen responsive with the ICS beta n its derivatives.
except one thing just did.
i changed the sampling rate from 200000(2 lak) to 20000 (20 hazar), n of course i had to change the up-threshold so i changed that to 95 (i did all these in rom-toolbox's kernel tweaks settings)
now everything is super-responsive (app startups, physical buttons, onscreen buttons, switching, yo name it) N while you are just lets say reading stuff on the screen, the cpu is generally at its lowest
what that means is : both responsiveness and higher battery.
please comment.
UPDATE : check the 7th post on this forum for more tweaks for snappy app launching n switching here http://forum.xda-developers.com/showthread.php?t=1570374#post24186676
UPDATE : ADDITIONAL TWEAK (more battery life) : in rom-toolbox change powersave bias to 35 (in rom toolbox) : saves a lot more battery by preventing the cpu from rushing to full-frequency while you are doing simple tasks like flicking the screen.
UPDATE : 3/31/12 : an interesting observation about "force gpu" 's causing poor performance on my post here : http://forum.xda-developers.com/showthread.php?t=1570374&page=2#post24266342
UPDATE : 4/7/12 : want even more battery life n smoothness?
add these to your build.prop save , reboot into recovery, clean dalvik-cache and /cache partition then reboot into system. things should be faster. and oh, underclock it.
ro.kernel.android.checkjni=0
dalvik.vm.execution-mode=int:jit
ro.ril.disable.power.collapse=0
ro.mot.buttonlight.timeout=1
dalvik.vm.verify-bytecode=false
dalvik.vm.dexopt-flags=v=n,o=v
you can also do a semi-odex using titanium backup's integrate system dalvik into rom thing, but then you won't be able to change any file in the rom (like applying patches, mods etc until you've either done undo integration thing in titanium backup or just used adb shell to delete *.odex from /system/apps n rebooted)
UPDATE : 4/28/12 : if you are using a derivative of the .562 ICS then you can change the kernel tweaks/sysctl settings to dirty_ratio = 80 dirty_background_ratio = 20 and vfs_cache_pressure = 20 to get snappy app startups up_threshold and powersave_bias can both be set to 90 and select ignore_nice_load. if you use lots of apps then raise the dirty background ratio and dirty ratio both by 15 points and reduce vfs_cache_pressure by 15 for low cpu usage while the apps are running. i've noticed that many of the custom roms have started getting my tweaks or similars preincluded , plus the official ics is much better than icsbeta in memory management. and oh, use arcknight kernel. its super awesome for both features and battery life. i switch my governor to interactivex or smartassv2 when i am recording using the 14mbps camcorder mod, and then back.
the android backup & restore under person in settings should be turned off. it takes a lot of cpu, battery, data n memory. its aweful.
if this works for you, press the thanks button.
How can this be done?
Duvel999 said:
How can this be done?
Click to expand...
Click to collapse
i used rom toolbox pro, its free version is available here - https://play.google.com/store/apps/details?id=com.jrummy.liberty.toolbox
anything else that can edit sysctl.conf (e.g. https://play.google.com/store/apps/details?id=com.jrummy.sysctl.config and https://play.google.com/store/apps/details?id=scd.atools ) will also work.
Gonna try it
system seems to be a bit snappier
thx mate
thnx mate.
for snappy app switching i discovered another bunch of settings
in rom toolbox's kernel tweaks under performance, change min free kbytes to [CORRECTION]8192[not 8096] (or [UPDATE] 6144 - whichever one you like), dirty ratio to 95, dirty background ratio to 70 and vfs cache pressure to 5 (n of course check the apply on boot option)
let me know how you like this additional tweak
UPDATE: some observations ; high dirty ratio causes lower cpu usage n faster app-switching, low dirty background ratio causes faster app startups but uses too much cpu, vfs cache pressure above 5 or 10 causes high cpu usage n lags. (i use lots of apps)
UPDATE #2 FURTHER IMPROVEMENTS (fast all around with acceptable cpu usage, super app switching, n decently fast launcher without sacrificing cpu-speed n battery life)
Kernel Tweaks :
reduce dirty background ratio to 50
check the OOM kill allocating task (if your device crashes after this, uncheck this, it may kill the android system n android os processes as well in some cases)
Auto Memory Manager :
foreground 6
visible 8
secondary 32
hidden 40
content 48
empty 120
Thnks
[white10char]
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
perhaps kickass kernel script
sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
check the 98kickasskernelizer (i'd find the respective values - especially min-free n change them in the script itself), there are two other not so popular scripts out there too that you may be using.
please share with us whatever was causing the overriding of rom toolbox's (or sysctl etc)'s settings.
Hey there thanks for the tip. Already tried it but I don't think there's any major improvement. In fact, antutu graphic score is down a bit. But don't know why. Maybe just my phone.
sent from my white ray using XDA App
hansip87 said:
Hey there thanks for the tip. Already tried it but I don't think there's any major improvement. In fact, antutu graphic score is down a bit. But don't know why. Maybe just my phone.
sent from my white ray using XDA App
Click to expand...
Click to collapse
the benchmarks dont tell you about usability. better responsiveness is due to faster cpu response to situations.
antutu's benchmark tests for continuous high performance (battery hogging w/lags) while running just one app.
my settings are for giving great experience (touch, app switching and app launching as well)
think of it as antutu being a mr. universe test, while mine are a gymnastics olympics tournament.
Well thanks. A lot less sluggish when scrooling..
Sent from my LT18i using XDA
darth5zaft said:
Well thanks. A lot less sluggish when scrooling..
Sent from my LT18i using XDA
Click to expand...
Click to collapse
thank you.
i just posted another slight tweak for higher battery life. its in the first post.
sunbriel said:
The up-threshold and powersave bias settings do not stick for some reason. They return to default values after a reboot even though Apply on boot is checked.
Sent from my LT15i (Xperia arc) on KA ICSony
Click to expand...
Click to collapse
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
i tried 6144, restarted n it sticks. try 8192 (i haven't tried restarting after that) : my 8096 was a mistake - i accidently doubled 1024 to 2048 n that to 4096 and then stupidly to 8096.
it is possible that numbers that are not multiples of 1024 are ignored if set on boot.
that occurred to me since init.d scripts are loaded much before rom-toolbox gets a chance to do its magic.
estuardo4 said:
It is the same for me. I guess we'll have to review each init.d script to see what is the one that is changing these values on restart.
Click to expand...
Click to collapse
Could it be that these settings are conflicting with Supercharger?
Sent from my LT15i (Xperia arc) on KA ICSony
hootnath said:
i tried 6144, restarted n it sticks. try 8192 (i haven't tried restarting after that) : my 8096 was a mistake - i accidently doubled 1024 to 2048 n that to 4096 and then stupidly to 8096.
it is possible that numbers that are not multiples of 1024 are ignored if set on boot.
that occurred to me since init.d scripts are loaded much before rom-toolbox gets a chance to do its magic.
Click to expand...
Click to collapse
I tried and it stuck after a reboot. It is working fine now. My battery is lasting more indeed, but wifi is always on, even after I made the suggested changes. I guess I'll have to reinstall Doomkernel v04 and JJ's ROM from scratch. But even with wifi always on, I'm having better battery life and less lag.
Thank you again.
estuardo4 said:
I tried and it stuck after a reboot. It is working fine now. My battery is lasting more indeed, but wifi is always on, even after I made the suggested changes. I guess I'll have to reinstall Doomkernel v04 and JJ's ROM from scratch. But even with wifi always on, I'm having better battery life and less lag.
Thank you again.
Click to expand...
Click to collapse
i found another interesting thing today.
the force GPU for 3d in the settings -> developer options actually uses a lot of the cpu and causes lags. i turned it off and have instead done the following
Get rid of CPU rendering:
Navigate to /system/lib/egl/
Open the file named "egl.cfg"
Delete the first line. It should say "0 0 android" or something similar
Go back into the egl folder and delete libGLES_android.so
What this does is remove the entire soft-rendering pathway from the OS.
source : http://www.ifans.com/forums/threads/ics-performance-tweaks.369959/ ;
now, i have changed the powersave bias in teh romtoolbox's kernel tweaks to 95 instead of {correcton}35{not]95. the cpu is spending more time @ 122mhz and deep sleep now without lags (which means more battery)
if this thing works for you, please press thanks.
Hi All,
Am I the only one that has to add the following files to the System/framework & system etc/permissions folders each time an update is applied?
com.google.android.maps.jar
com.google.android.maps.xml
************************************************** ************************************************** *************
Battery life & Performance
I have to say that all upates since 10/4 has seen a dramatic increase in battery usage when using the simplist app on the phone to the point that I can actually see the battery indicator dropping. There also is some serious lag as well overall as well. I've tried overclocking to 1200, setting to 1100. Governors set to Interactive at the moment but I've tried them all. I also tried a full system wipte, format the SD card as well but still see the same issue.
Anyone else having this, did have this & what was the fix (if any)?
I am not sure what MOD you meant, but when it comes to mods like CM9 or CM10, they are pretty demanding. What I always do to save my battery:
- keep number working widgets minimized as low as it's possible
- set the 2g instead of 3g
- I use a profile application to enter the flight mode during night
- set WIFI policy to never
I hope that helps somehow.
Here's my tweaks i have created and invented myself tweaks that are already out online will not be posted below
# Fps Properties
ro.fps_enable=1
ro.fps.capsmin=30fps
ro.fps.capsmax=60fps
Some of protocals for ipv4 and ipv6 are experimental but seems to work fine as time goes by the internet properties below will be revised. NOTE: feel free to modify the protocals, but not distribute them as your own, you must include me for full credit when releasing the modified properties, the only two protocals not owned by me is
persist.telephony.support.ipv6=1 persist.telephony.support.ipv4=1
Click to expand...
Click to collapse
And i do not know the creator who created them, the rest is mine as built thank you
# Internet Properties
persist.internet.support.ipv6=1 persist.internet.support.ipv4=1
persist.dns.support.ipv6=1
persist.dns.support.ipv4=1
persist.telephony.support.ipv6=1 persist.telephony.support.ipv4=1
persist.dhcp.support.ipv6=1
persist.dhcp.support.ipv4=1
persist.dnla.support.ipv6=1
persist.dnla.support.ipv4=1
persist.web.support.ipv6=1
persist.web.support.ipv4=1
persist.tcp.support.ipv6=1
persist.tcp.support.ipv4=1
persist.udp.support.ipv6=1
persist.udp.support.ipv4=1
persist.voip.support.ipv6=1
persist.voip.support.ipv4=1
persist.dns2.support.ipv6=1
persist.dns2.support.ipv4=1
Plwce this uner addtional build properties under tge dalvik heapsizemax line
What this does is helps the multithread line to tell the cpu to easily do more faster proccessing without overheating
persist.sys.dalvik.hyperthreading=true
Now we can we can focus on permently keep a certain fps speed to force the os to lock at that fps speed
BootAnimation build prop is like shown below:
# Bootanimation Properties
boot.fps=25 (value 25 is the default value for tge boot animation fps speed, the higher the value, tge faster tge fps will be permenetly until you chsnge the value if upping the value 30 is a great option to choose keeping system stability)
Now you want to keep your whole os at a top speed you want many devs havent invented this but until i did
Revision 1:
# System Properties
system.fps=30 (value 30 is tge default value but some devices cant handle it if they are high end devices 25 is a good value for low end devices but you csn keep 30 or upp the speed and this will lock the os to that desired fps, user can change this value if implemented in the roms build.prop if they desire)
Or
Revision 2
# System Properties
cpu.fps=30
gpu.fps=30
(The cpu and gpu lines allow you to decided what fps rate should each do for ex: say i want the gpu's fps rate to go a lil faster i change the default value 30 to 35 rasing the fps a bit higher, but say if i want to run both cpu and gpu fps run at the same rate i put both vslues the ssme number, remember chamging vslues beyond 30 is risky and can cause gpu or cpu stress and making them.not run together can cause instability but wont damage your cpu but could effect graphics speed and processing speed)
Revision 3:
# System Properties
cpu.fps=auto
gpu.fps=auto
(what the "auto" value tells the cpu and gpu to Automatically choose the best FPS Rate for the OS or every individual app or games you run as well and will give less stress on the cpu without losing the current top speed of your OS)
EX: say my os default runs at 25fps and i have the value above to auto the os will detect that the auro is on and will cap the cpu or gpu to any value like value 30 to ensur the best fps rate.
NOTE: some of these tweaks may vary of firmwares and devices
Hi, is anyone tried all the above tweak ?
Is there all really working ?
Thanks in advance.
This seems good to try. The IPv4/6, are they necessary? Doesn't Android automate that anyway in newer versions of Android DHCP?
Hi is anyone has tested all these tweaks ??
Is it working ?
Thanks in advance.
[null]
eladkarako said:
I prefer to disable IPv6 support,
to allow an easier ads-blocking using the HOSTS file.
Click to expand...
Click to collapse
Could you please tell me how you do that. I've found a shell command, which is working - until i get dis- and reconnected again. That's not really a permanent solution
ah! its 2021!
i hope the fps stuffs still works
Code:
#include "std/disclaimer.h"
/*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this software
* before using it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
What Is It
Subcore is an root daemon that utilizes various sensors in the device to systematically apply different usage profiles. The goal is to achieve a balance based on the user's workload, rather than relying on the CPU governor to make bias assumptions about the current workload.
How Does It Work
Subcore reads and writes to system files on the device to determine which profile to place the device into. These interfaces include:
• Active CPU load
• Available CPU cores
• Available CPU governors
• Available CPU frequencies
• Available GPU load
• Available GPU frequencies
• Current battery capacity
• Battery state (charging / discharging)
• Screen state
◦ State Notifier (primary choice)
◦ Power Suspend (secondary choice)
◦ Framebuffer interface (tertiary choice)
• Available device memory
• Max device memory
• Available IO schedulers
• Block readahead
• Block swappiness
• Block cache pressure
• Block dirty rations
• Random entropy
• Block overcommit
• Block page cluster
• Block dirty centisecs
• Block LMK
• Block laptop mode
• Block KSM
• Uniquely Generated Interactive Tunables
• Uniquely Generated Schedutil Tunables
User Prediction Algorithm
Without some form of user prediction, a game could begin to lag for a moment during a loading scene, where the load requirement dips. To counteract this, Subcore implements a user prediction algorithm that attempts to maintain fluidity in heavy applications, even during moments of low load. It works by determining repetitive load averages, and scanning less often when the load is consistent. This results in far less lag spikes when playing intensive games.
Power Aware Algorithm
Since Subcore is a low-level (yet userspace) tool, it has direct access to battery statistics. When charging (and screen on), Subcore will boost your performance to the highest performing profile to ensure the user experiences UI/UX conformity, disregarding the energy limitation. Additionally, when Subcore detects the device is at 15% battery or less, it will half the loadavg, which means it requires twice as much CPU load to enter the next profile. Likewise, at 5% battery or less, Subcore locks the device into the lowest profile, which is optimized for deep sleep or idle, sacrificing a chunk of performance to battery. This setting can be disabled by toggling "Disable Power Aware" in the Subcore GUI app.
RUPG - Realtime Unique Profile Generation
Subcore implements a new concept that I call RUPG. What makes Subcore special is the fact that it is compatible with essentially all devices. At runtime, Subcore initially gathers heaps of data to generate numerous device-specific profiles based on various factors. These generated profiles are heavily optimized for each device, so that each user achieves the most efficient software experience for the available hardware/software provided. These profiles are then saved in memory and are marked for deletion when Subcore exits. Some examples where RUPG is utilized is in the generation of device specific LMK offsets (minfree). Each device has a different RAM size, so Subcore must manually calculate the optimum LMK minfree sizes for each offset vector (VERY_LIGHT --> VERY_AGGRESSIVE). Subcore also utilizes RUPG in the production of the governor tunables. Each device has a different SOC CPU frequency table, which must be accounted for. These profiles are generated automatically by the binary, so the user doesn't need to tune anything themselves.
Race To Idle
Research proves that when completing a task, less resources are eaten when boosting to a slightly higher frequency for a short time, rather than a low frequency for longer. Subcore takes full advantage of this theory and applies special tunables for each profile. Each Subcore profile has a different goal to achieve. The UI/UX is the main profile that takes full advantage of RTI. This profile tunes the governor to stay at minimum frequencies until a small workload is requested. It then jumps up a frequency level to complete the task faster, then it instantly shoots back to minimum frequency if all other tasks are completed. If a heavy task comes up, but not quite heavy enough to trigger a profile change, the UI/UX profile will handle it by jumping another 1-2 frequency levels. Finishing the work requested, the loadavg will quickly shoot down and the governor will return to idle, saving battery yet increasing performance; it sounds impossible, but in practice, it works better than expected.
Performance == Battery
It sounds impossible. How can an app save power, but also make my device perform better? Here's why it works. Think about battery and performance as independent spectrums. Just because you have one doesn't mean you can't have the other. By working efficiently, Subcore can actually improve performance on some devices. This is because Subcore doesn't just tune your device for battery, it also applies VM tweaks, MM tweaks, Block tweaks, and much more. During my testing phase, many of my testers were telling me how Subcore strangely caused some tasks to perform better than usual. This included UI/UX smoothness, app start times, Camera HDR rendering, file IO (such as zipping a large file), and some other tasks. I realized that the tweaks that Subcore applies improve battery by improving performance in areas that don't affect battery as much. For example, something as basic as IO readahead will cause a marginal impact on battery, but the Block performance benefit that comes with a higher readahead can cause IO tasks to finish much faster. Applying the concept of Race To Idle, the disk performance benefit helps the device finish its current task faster, allowing the CPUs to reach deep sleep sooner, and in turn, providing better battery.
Hyper Optimizing
Subcore is written in native C++. In fact, the Android app for Subcore just forks the included binary based on the device architecture. Since Subcore is written in C++, it is light, fast, and pretty tiny. It is also entirely independent from Java code entirely. Once it's started, the Subcore app can be killed fully (even force quit), and the daemon will persist, since it is the parent of its own process. Using `top`, you can see Subcore isn't even on the list. Every single line of the C++ code is written to utilize the least amount of memory, and run as efficiently as possible. It utilizes C++11 inlines, uint*_t, -Ofast, --strip-all, custom built NDK clang toolchains from source, and far more optimization. Subcore includes C++STL in the binary as well, so it is portable and is contained all in one binary. Subcore is also compiled in ARM, ARM64, x86, x86_64. MIPS is not supported at this time.
Automatic Backup/Restore Algorithm
Since Subcore writes to a large portion of your sysctl, many of your kernel manager tweaks would be written over until they are reapplied on the next boot. Luckily, I spent the extra time to implement an automatic backup and restore algorithm to save the device's current settings on the start of Subcore. On sending a SIGINT or SIGTERM to Subcore, it will restore the user settings before exiting. This way, you don't need to reboot each time you stop Subcore. NOTE: If you toggle Start On Boot to Subcore, there is a high probability that it will start before your kernel manager's apply on boot will. This means that Subcore won't backup the proper data, so when you stop Subcore, your kernel manager tweaks won't be applied. To solve this, either reduce the timeout for starting on boot for your kernel manager, or start Subcore manually after each boot.
Results
When you start using Subcore, it'll feel too good to be true. But stats don't lie. I will provide quotes from my testers, along with screenshots of my testers and my battery life improvement. I urge everyone that tries Subcore to post your results, along with the device model you are using. If you have any questions about how Subcore works, or if you have any questions at all, please contact me. I'd be more than happy to address your concerns.
Testers
I'd like to personally thank all of my testers for sacrificing their phones to my code. Each and every one of them assisted in the stability of the program itself.
@SmallTarzan
@efranz
@kdrag0n
@ASHLEY117
@abhirams2020
@Mountaser_halak
Extra Notes
For Subcore to work properly, please ensure the following things are proper:
• Make sure Subcore is always granted root.
• Use Low-memory mode if the device does not have ZRAM or ZCACHE, or if you notice apps crashing / not opening.
Contact
I am always available for contact. Send me anything you want: questions, concerns, suggestions, comments, assistance, thank you messages, etc. I always appreciate messages from users
Gmail: [email protected]
Telegram: @tytydraco
XDA: @tytydraco
Donate
When I released System Mods, users were always asking how they could donate. So I thought I'd post a PayPal link so you can donate if you really enjoy my work
Those who donate can request to be put on the XDA thread and I'll add you to the list of donators here. You can also write a message to post here if you can fit it.
https://www.paypal.me/TylerNijmeh
--DONATORS--
none yet
Download
Google Play
VirusTotal report:
arm64 raw binary: https://www.virustotal.com/#/file/5...3074755f96e516f20bb1f6fb85c95abf95a/detection
XDA:DevDB Information
Subcore, App for all devices (see above for details)
Contributors
tytydraco
Version Information
Status: Stable
Current Stable Version: 1.0
Stable Release Date: 2018-09-05
Created 2018-09-06
Last Updated 2018-09-05
Here are some quotes from my testers:
"With subcore on image processes faster ?" ~ Franz
"But I'd say gcam is a bit slower when subcore is off" ~ Franz
"Sorry been quiet and lurking but tested on stock soldiers ROM S9, Phh treble aosp and havoc device specific. Results are pretty impressive! Getting 20% more battery life and faster operations on stock based and aosp based but not much difference noticed with treble GSI" ~ Ashley117
"Subcore on: 866/4543, Subcore off: 772/2527" ~ Franz
"@tytydraco I think you will like this ^^ *photo of Antutu*: 147987 (Subcore on) vs 142286 (Subcore off)" ~ Franz
"It has more IQ than some of my classmates." ~ SmallTarzan
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Edit: all the promo codes were used. Sorry guys ?
Amazing battery life with only a slight impact on performance. I watched this mature from a minimal C++ program to a full-on app that balances performance and battery very well. Good luck!
Hi, mum! I'm on YouTube!
tytydraco said:
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Click to expand...
Click to collapse
Took F836DQPKJ26RNW4Y49LAYEX. Thanks for the code.
senpaidev said:
Took F836DQPKJ26RNW4Y49LAYEX. Thanks for the code.
Click to expand...
Click to collapse
No problem! Let me know how you like it, and please share the thread if you want
Claimed 9YTQUQTFVZHNWXY3WT7S81M
Thank you! Will test it out and provide some feedback soon.
tytydraco said:
PROMO CODES
These are first come first serve. Here is 10 to start off. Enjoy!
0KKVAS9PEPU2X9JWP3Z2JXT
AW6VZ9WGPT3WSH0P9AUH40S
1FG32WUV2T02XBE8H0SRMKT
ECM1UY61V7V8295AFFZZ5QY
F836DQPKJ26RNW4Y49LAYEX
CZB08PFUV2MB3M8CP5J1RPK
8X8AHN7L5MCZ1KXVGW4B2W7
9YTQUQTFVZHNWXY3WT7S81M
JD8K4L46S40R61YWY0599JG
YCG4QQ36YXPF2LYXYPYG70K
Click to expand...
Click to collapse
Oops!!! All those codes were redeemed. Do you have more? Please?
arunv707 said:
Oops!!! All those codes were redeemed. Do you have more? Please?
Click to expand...
Click to collapse
I won't be releasing any more on XDA, but if Android Police or Android Authority choose to sponsor my app, they will give people up to 20 promo codes.
Pleasure to test and 1 of the 1st apps I install in my daily flashing routine ??
Improving performance on GSI ROMs now I've noticed but only on Phh releases. Thank you again
I fixed the issue where some devices would get incredibly laggy. The cause for this was that my algorithm for determining the screen sleep state was faulty. The system would deliver inaccurate information for the variable I was tracking, so I switched to a new (updated) variable (specifically measured_fps. It is 0.0 when the screen is off). This should fix the lag for the Pixel 2 XL as well as some other devices.
I sincerely apologize to those affected, and I ask that you give Subcore another chance. I am passionate about this project, and I want my users to be satisfied. If you'd like a refund, email me and I can try to figure something out. Thank you.
Credit to log comes from Reddit user u/faz712. Thanks so much
Reddit thread: https://www.reddit.com/r/androidapps/comments/9deihr/app_root_subcore_adaptive_daemon_v10/
I use it on a S8 . After enabling, governor is schedutil and device is underclocked From 2,3 Ghz to 1066 Mhz . Is this underclock normal ? https://drive.google.com/file/d/1BG8ZyNH6LojgquYVZCWxxzNIWY39VUEV/view?usp=drivesdk Logcat when i Start subcore. @tytydraco
Re¢o said:
I use it on a S8 . After enabling, governor is schedutil and device is underclocked From 2,3 Ghz to 1066 Mhz . Is this underclock normal ? https://drive.google.com/file/d/1BG8ZyNH6LojgquYVZCWxxzNIWY39VUEV/view?usp=drivesdk Logcat when i Start subcore. @tytydraco
Click to expand...
Click to collapse
That's perfectly normal. That setting will keep changing depending on what you're doing. Don't change the settings as Subcore will handle it for you
tytydraco said:
That's perfectly normal. That setting will keep changing depending on what you're doing. Don't change the settings as Subcore will handle it for you
Click to expand...
Click to collapse
I used it for different things like casual Apps and some gaming but the Frequenz is still 1066Mhz and some Times i had little lags and device get hot. But when you say its normal i will tryit out for longer . But on thing i can say battery is very nice
Hello,
I am using S8 (Exynos) with velocity kernel. Do I need to enable any other settings in the app too? Also it doesn't look like it changes all values such as LMK. I checked that with MTweaks but didn't changed settings there ofc.
Also I was wondering if disabling debugging and IO stats would break the algorithm.
SH4M3 said:
Hello,
I am using S8 (Exynos) with velocity kernel. Do I need to enable any other settings in the app too? Also it doesn't look like it changes all values such as LMK. I checked that with MTweaks but didn't changed settings there ofc.
Also I was wondering if disabling debugging and IO stats would break the algorithm.
Click to expand...
Click to collapse
No, you're good to go. LMK is not tuned when memory awareness is disabled (which should be on Samsung ROMs).
On the kernel side, disabling debugging and IO stats won't break Subcore. It doesn't use those.
kdrag0n said:
No, you're good to go. LMK is not tuned when memory awareness is disabled (which should be on Samsung ROMs).
On the kernel side, disabling debugging and IO stats won't break Subcore. It doesn't use those.
Click to expand...
Click to collapse
Thx ^^ Great App btw
I am not able to download this app in play store, the search also does not show up this app. Please can some one give me a download link
cphilch said:
I am not able to download this app in play store, the search also does not show up this app. Please can some one give me a download link
Click to expand...
Click to collapse
Absolutely! As long as your region supports paid purchases, you should be able to download the app. Enjoy!
https://play.google.com/store/apps/details?id=com.draco.subcore