Related
With all these new "hero" builds coming out/updates for them, it is important to have optimal settings. Many people are not sure how to do this so I thought I would take my time to write a quick how to.
I have also attached a user.conf that is setup with comp cache and backing swap, swappiness of 80. I set the cpu scaling from 384 to 528 Mhz. You may edit this with notepad++ if you would like swap instead. Just open the user.conf with notepad++ and make the changes you want (the file is pretty self explanatory) Just be sure to set compcache to 0 along with backing swap
Place the "user.conf" on your sd root, and use the commands mentioned below
P.S. I apologize in advance to the moderators if you feel this is not in the appropriate place or not necessary, just trying to make things a little bit easier
In Terminal type:
Code:
$su
#sh /system/bin/rwsystem
#cp -f sdcard/user.conf /system/bin/user.conf
*If your ROM does not support "rwsystem"* use:
Code:
mount -o remount,rw /dev/mtd/mtdblock3 /system
Once again, I have attached a user.conf along with the JAC kernel that includes the script which allows you to use "rwsystem" (If your ROM supports the kernel)
Here is the link to the JACSki kernel with ttc_smokee's gps fix and Soul Life's script which will allow you to use "rwsystem"
http://www.4shared.com/file/133261717/84fd2884/JACHEROSki_Kernal-_Update.html
*Just like anything else on this site, I am not responsible for you bricking or damaging your device*
CHeErs
Post here if you would like any kind of walkthrough for "dummies" reguarding user.conf's or user.init's or
kingklick said:
*If your ROM does not have a kernel that supports "rwsystem" use
Code:
mount -oremount,rw /dev/mtd/mtdblock3 /system
Click to expand...
Click to collapse
You missed the space between -o and remount...
cx92001 said:
You missed the space between -o and remount...
Click to expand...
Click to collapse
works as-is
some progs accept arguments like that
some don't
mount happens to be one that does
alapapa said:
works as-is
some progs accept arguments like that
some don't
mount happens to be one that does
Click to expand...
Click to collapse
Good to know. Thanks
alapapa said:
works as-is
some progs accept arguments like that
some don't
mount happens to be one that does
Click to expand...
Click to collapse
yah it does work without the space, thanks, but i edited the space in anyway to prevent more posts like that
Are these edits needed/beneficial for those not interested/using hero ROMs?
I recall MikeTaylor had a file, but i know so little on what these can do. Thanks for doing this man.
s15274n said:
Are these edits needed/beneficial for those not interested/using hero ROMs?
I recall MikeTaylor had a file, but i know so little on what these can do. Thanks for doing this man.
Click to expand...
Click to collapse
Not needed, however I'd say most would argue they are beneficial changes for most ROMS... ie) cyanogen uses comp cache on his builds.
and no problem man my pleasure. My way of giving back to this great site
If you do not know how to edit these files post here and ill make you a user.conf to your liking
kingklick said:
With all these new "hero" builds coming out/updates for them, it is important to have optimal settings. Many people are not sure how to do this so I thought I would take my time to write a quick how to.
I have also attached a user.conf that is setup with comp cache and backing swap, swappiness of 80. I set the cpu scaling from 383 to 528 Mhz. You may edit this with notepad++ if you would like swap instead. Just be sure to set compcache to 0 along with backing swap
P.S. I apologize in advance to the moderators if you feel this is not in the appropriate place or not necessary, just trying to make things a little bit easier
In Terminal type:
Code:
$su
#rwsystem
#cp -f sdcard/user.conf /system/bin/user.conf
*If your ROM does not have a kernel that supports "rwsystem" use
Code:
mount -o remount,rw /dev/mtd/mtdblock3 /system
Once again, I have attached a user.conf along with the JAC kernel that will allow you to use "rwsystem" (If your ROM supports the kernel)
Here is the link to the JACSki kernel which will allow you to use "rwsystem"
http://www.megaupload.com/?d=K39IKK7A
*Just like anything else on this site, I am not responsible for you bricking or damaging your device*
CHeErs
Click to expand...
Click to collapse
Rwsystem is not kernel dependent, its a script I wrote that made its way into a few other builds. Just a script which resides in bin or xbin directory, nothing more or less.
soulife said:
Rwsystem is not kernel dependent, its a script I wrote that made its way into a few other builds. Just a script which resides in bin or xbin directory, nothing more or less.
Click to expand...
Click to collapse
o ok kool. I was mislead by a few others saying it was in the new JAC kernel silly people.... Anyway thanks for the fix soul life
you did a great thing by adding that script
Just changed the "kernel file" to the kernel with gps fix.
cheers!
More Detailed HOW-TO
Thanks for the post. I am in middle of (will take about a year, LOL) writing a HOW-TO on user.conf settings so that it will be easier to understand what needs editing and what settings are best. Currently, I am using a 64MB linux-swap with compcache and have been playing around with tweaking the settings to make my phones run "perfectly." This is much more difficult than it sounds when you take into account the various options such as backing swap, linux swap, swap files, compcache and swappiness settings. This all, of course, is system and user dependent. I use my G1 and my myTouch differently and have different apps installed on each so therefore, my settings are different for both. I still haven't come up with the perfect strategy but I am pretty close.
How about expanding this out (I don't mind actually posting it) to include more details on what each setting means and what the possible benefits/problems are with each. I use this (http://forum.xda-developers.com/showthread.php?t=542899) userinit.sh file along with the user.conf. I wrote one script to pull the user.conf from system/sd to my SD card and one that pushes it back to system/sd when I'm done with it. I use "Text Edit" to edit the user.conf right on my phone so I do not need to use ADB and Notepad++. This takes the PC out of the picture so I can tweak the settings wherever I happen to be.
I don't think there is ONE user.conf file that is good for everyone. It all depends on what the user's intentions are with his or her phone. Your default swappiness is set to 80 but that can vary. I am up in the air on that one testing between 30 and 100. But like I said, user dependent.
AndroidAppCritic said:
Thanks for the post. I am in middle of (will take about a year, LOL) writing a HOW-TO on user.conf settings so that it will be easier to understand what needs editing and what settings are best. Currently, I am using a 64MB linux-swap with compcache and have been playing around with tweaking the settings to make my phones run "perfectly." This is much more difficult than it sounds when you take into account the various options such as backing swap, linux swap, swap files, compcache and swappiness settings. This all, of course, is system and user dependent. I use my G1 and my myTouch differently and have different apps installed on each so therefore, my settings are different for both. I still haven't come up with the perfect strategy but I am pretty close.
How about expanding this out (I don't mind actually posting it) to include more details on what each setting means and what the possible benefits/problems are with each. I use this (http://forum.xda-developers.com/showthread.php?t=542899) userinit.sh file along with the user.conf. I wrote one script to pull the user.conf from system/sd to my SD card and one that pushes it back to system/sd when I'm done with it. I use "Text Edit" to edit the user.conf right on my phone so I do not need to use ADB and Notepad++. This takes the PC out of the picture so I can tweak the settings wherever I happen to be.
I don't think there is ONE user.conf file that is good for everyone. It all depends on what the user's intentions are with his or her phone. You default swappiness is set to 80 but that can vary. I am up in the air on that one testing between 30 and 100. But like I said, user dependent.
Click to expand...
Click to collapse
o ok very kool. Although, I did mention in my OP the HEro ROMs and what not, so I figured most people interested would be in the HEro scene. These settings seem to work best for me on 75% of the hero ROMs Ive flashed. DOesnt mean its "right" just whats worked for me. Just wanted to give back to this great site, and help the new comers because we have all been there at some point
P.S. PM me what you think I shoulld change/add to this thread to make it offical. Thank you in advance
ChEerS
Yeah, I just noticed the Hero thing. I suppose that I would like to see (somewhere on XDA either here or a new post) a very detailed explanation of all the possible settings, what they do and how they may or may not affect each other. When I was first trying all of this out I had to search very long to find explanations. If a noob wanted to know what swappiness was, for example, they would have a difficult time finding a good explanation. Even the experts can't agree so how is a novice supposed to understand it.
Perhaps this would be a good place for people who know to informally contribute and it can eventually be moved to its own thread, a sort of compache, linux-swap, backing swap, swappiness manual. A one-stop shop for all things memory related with links to the various XDA threads that can help them accomplish what they want to do.
My G1 and myTouch fly right now with next to no lag but it took me quite some time to get all the settings the way I like it (sort of, still perfecting them). I want the same for everyone.
AndroidAppCritic said:
Yeah, I just noticed the Hero thing. I suppose that I would like to see (somewhere on XDA either here or a new post) a very detailed explanation of all the possible settings, what they do and how they may or may not affect each other. When I was first trying all of this out I had to search very long to find explanations. If a noob wanted to know what swappiness was, for example, they would have a difficult time finding a good explanation. Even the experts can't agree so how is a novice supposed to understand it.
Perhaps this would be a good place for people who know to informally contribute and it can eventually be moved to its own thread, a sort of compache, linux-swap, backing swap, swappiness manual. A one-stop shop for all things memory related with links to the various XDA threads that can help them accomplish what they want to do.
My G1 and myTouch fly right now with next to no lag but it took me quite some time to get all the settings the way I like it (sort of, still perfecting them). I want the same for everyone.
Click to expand...
Click to collapse
Yeah I agree cuz when I was trying to root my phone and stuff around fiveish months ago... and I had to do the whole runaround because there was not any good organized information like now it is pretty close. But we definitely have a ways to go to get some good stuff for n00bs... lets get it done.'
AndroidAppCritic said:
Yeah, I just noticed the Hero thing. I suppose that I would like to see (somewhere on XDA either here or a new post) a very detailed explanation of all the possible settings, what they do and how they may or may not affect each other. When I was first trying all of this out I had to search very long to find explanations. If a noob wanted to know what swappiness was, for example, they would have a difficult time finding a good explanation. Even the experts can't agree so how is a novice supposed to understand it.
Perhaps this would be a good place for people who know to informally contribute and it can eventually be moved to its own thread, a sort of compache, linux-swap, backing swap, swappiness manual. A one-stop shop for all things memory related with links to the various XDA threads that can help them accomplish what they want to do.
My G1 and myTouch fly right now with next to no lag but it took me quite some time to get all the settings the way I like it (sort of, still perfecting them). I want the same for everyone.
Click to expand...
Click to collapse
yah for sure bro. Maybe you and me should put a detalied one together... This was intended to be a crude easy guide for pure n00bs who just want a "faster" phone. Most n00bs are not too concerned with what "swappiness" is and the technical difference between CC or linux-swap. Thats just my opionion though brother
Sorry if this is a stupid question but what exactly do I do with the two files? Do I rename the kernal update as update.zip and run that after I'm done installing the Hero ROM of my choice (I was looking at doing drizzy's)? Then what do I do with the user.conf file?
markdt098 said:
Sorry if this is a stupid question but what exactly do I do with the two files? Do I rename the kernal update as update.zip and run that after I'm done installing the Hero ROM of my choice (I was looking at doing drizzy's)? Then what do I do with the user.conf file?
Click to expand...
Click to collapse
Ima change the OP thanks anyway, if you have recovery 1.4 you can actually flash "any" zip meaning it does not need to be renamed. MOst ROMS now have this kernel built in, however MOdaco 2.2 DOES NOT, so if you plan on using modaco 2.2, flash this kernel. FLash MOdaco (or whatever ROM is missing this kernel) THEN flash the kernel right after without rebooting.
as far as the user.conf goes, put it on your root and use the commands i provided in the OP.
ChEeRS
ok its simple we all know the benefits of more ram. we all know that android slices up the ram into static addresses within the kernel. i would like to change that as we are in 2009 almost 2010 and we still rely on static ram allocation for the camera, gpu, sensors, radio. the g1 has 192mb of ram. yet we only get 97 for programs to use. i would like to place the camera, gpu, etc into dynamic addresses that we can change within the os without flashing a new kernel. a service, kernel code, module, or any other method could do this. we just have to make it happen. we could do it three ways i see.
1. a system managed ram allocation using a service to detect the percentage used and increase ram on the go.
2. a kernel script or service that only activates and allocates ram when needed. such as once a 3d program is loaded the 8mb magically comes back.
3. a virtual device ram allocation service that makes the device think it has the ram all along, but only actually gets it when it needs it. kinda like the way apps2sd works.
4.(by IConrad01) run perl scripts through ase and use ksplice to patch the gpu1 memory in kernel. one script on and one for off.
any other methods to implement this proper are very welcome and encouraged.
the idea behind this is a proper way to get back more ram for our programs. the idea is simple when 3d is not in use we can used the 8mb it would have used for something else. this applys to everything that has its own ram. camera, etc. say we did this and only got 120 free. thats almost 25% more ram. plus we could go the extra step and let the user choose how much each thing gets(gpu settings 4mb,8mb,12mb. camera on, off. etc) so when it needs it thats what it gets. great if you like/dislike 3d games.
on another note this is the kind of work that gets you noticed. the kind that gets you hired or gets you respect. google would be proud and might implement it and you and i know it. i hope we are successful and google uses it mainstream.
so lets debate a way/ways to do this
provide alpha tests of different ways to do this
and finally lets post a beta so everyone can enjoy.
atm ksplice with perl scripts is where we are going will update as this progresses.
Doesnt Jacs update to his hero rom have this, im probably mistaken
jad011 said:
Doesnt Jacs update to his hero rom have this, im probably mistaken
Click to expand...
Click to collapse
No. The current implementation of this basically cuts the graphics memory in half.
This would dynamically allocate the memory as needed. Much more efficient way of doing it.
he has a static change that takes the ram away from the gpu by a kernel edit. this is to have both more ram but still give the gpu what it needs to perform properly but only when it needs it or you chose to give it.
Are you referring to RAM or storage space? You say RAM in the title but then it sounds like you're talking about storage space before making me think it's RAM again later on. I'm confused :/ I'd really like additional free RAM, anything that helps reduce swapping to SD card is good but storage space I have plenty of.
all of this would apply to ram only. swap and compcache could use the same idea to dynamically allocate swap but that is still a cache for programs. sorry if its confusing. simple way to explain. i want all the ram i can get but still use everything the phone has properly, like games and the camera.
Gotcha and understood. I see so many people say RAM and memory when they're referring to storage space sometimes that I want to scream but extra RAM on the G1 would be more than welcome. Hopefully others with the brains to make it happen can do it
actually anyone with a basic knowledge can help. mostly there are a couple things to developing a good idea.
first the concept.
then ideas on how to do it.
next a map or guide to what does what.
coding different parts
putting them together
debug and test
even if all you do is photoshop the ui or provide ideas it helps. once some different people get aboard this should be working sooner than you think.
Of the three options listed, the kernel script (via ksplice) seems like it would be the shortest route to functionality, but frankly it also seems a bit... well, hackish -- when compared to the virtual device allocation scheme. It would take a hefty re-write of the kernel, I suspect, to accomplish; but being able to resize various devices on the fly would be a good thing. Shrinking CompCache based on real RAM usage for example would probably speed up the phone under light loads.
Just thinking in text here.
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
jokersax11 said:
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
Click to expand...
Click to collapse
The only problem with this is when the ram is divided, everything in it is cleared, thats why it is set at boot in the kernel. Think of it like repartitioning your SD. Now it would probably be possible have everything mapped to ONE big RAM table & then build something similar to a scheduler like BFS for RAM that would allocate it as necessary. This is messy though.
Just my $.02
well yes but it is possible to create shared memory through c++ http://www.go4expert.com/forums/showthread.php?t=8461
however i think the vm heaps has either a 6 or 16mb limit. anyways the service would basically do a memory patch over the kernel in realtime(like overclock) telling the gpu the memory is there all the time. meanwhile it allocates dynamic shared memory from the application memory for the gpu to read and write. meanwhile an app tied to a script would set the parameters and settings.
Okay -- I know ksplice works with perl; and I know that we can run perl scripts using the ASE .apk.
So... it seems to me that it /should/ be possible to use a patch that reverts the patched kernel back to the previous state, and a patch that switches the original state to the GPU1=0 MB state. From there, we could set up two scripts; one for GPU1-off and one for GPU0-on. Each would simply be an invocation of ksplice to input the specific patch (which would have to be stored on the sd card. [it would be safer if in the ext partition]).
We'd have to set up a secondary RAM device, rather than just adding it to the standard RAM pool... something like establishing it as a /dev/block/shm.
The point of all the above is that when you click on the GPU1-off script, it "reclaims" that RAM and gives you a device that's standard RAM. When you click on the GPU1-on script, it disables that device (forcing the reload of all programs using that RAM) and re-enables the GPU1 device.
Even better yet, the Android Scripting Environment program, much like GScript, supports desktop icons.
So -- very initially speaking, assuming we can get ksplice working on Android (which just requires a static binary, IIRC), we can get a simple pair of icons; one of which frees up the GPU1's RAM; and the other of which re-enables the GPU1.
Since the only times it's going to be "called up" are when a game is actively being played, or something similar, this should be a mostly-satisfactory route to begin with, before we can get into the whole scheduled/scaled script running as a daemon in the background.
Once we get /there/, then we can start looking at true virtual device allocations and shared memory and the like.
Although, I do have to say that I'm not entirely sure how comfortable I am constantly repatching the kernel. Definitely, we're going to want to recommend that people back up their original, unpatched, boot.img files!
IConrad01 i added your method to first post as it was a great start to this project. if you want me to rephrase just post what you want and ill change it. the only issue i might see is what geniusdog254 said it might unallocate the wrong thing and create a reboot. but some clever coding should prevent this.
Nah, that's all good.
There's an easy way to prevent it from becoming a reboot-able issue. Enable the GPU-space device as "swap". This could be done one of two ways; tell the phone that the new 8 MB RAM "device" is to be considered the /first/ swap device to be used, and just leave it "as is". The r/w times would be for true RAM. The other option assumes we have the latest CompCache (0.6+) -- as it allows for multiple instances of CompCache. The theme here should be obvious.
Either way, the result is that only swappable pagefiles would be lost when the device is turned back into GPU memory. No system-vital memory would get tossed. Seems simple enough to accomplish, perhaps. But then again, I Am Not A Programmer.
ok so what are the alternatives to ksplice for the swap device change. since we could make it swap/compcache anyways is it possible to change on the fly like the way overclocking widget does?
Ksplice allows you to make kernel updates and have them implement themselves without having to reboot the device. The swap device stuff would have to be implemented on a script-level. Two different things: I.e.; the script invokes ksplice to install a specific patch, which causes the kernel to recognize the newly freed-up RAM as a specific device (I.e.; such as /dev/ram1 as opposed to /dev/ram0). I am not sure I'm saying/thinking of this properly here: I'm operating on the edge of what I know about Linux.
Anyhow -- the trick is, when we get the kernel to disable the GPU's memory, we enable a new RAM-disc swap partition with its swappiness set to the maximum rating so it picks up everything first. Since it is /actually RAM/, it'll perform like real RAM. We're only 'declaring' it as swap in order to prevent forced reboots when turning it off.
The above wouldn't just be a ksplice thing; ksplice is just to implement daproy's kernel patch and thus free up the devoted memory to the GPU1. This memory would then be allocated to a new device (thus preventing the RAM-dump forced reboot) and /that/ would be set to swap status to ensure no "mission-critical" files go on it.
Then, once we get that built up, we just build it in "reverse" -- turn off swap (dumping its info back to the system, where CompCache / linux-swap would pick up the load) and re-enabling the GPU1.
Once we get /those/ built, we can then create a daemon script, include an invocation of it into the latest userinit.sh, and have that script basically monitor GPU0's load levels. If they go above a certain threshold (scaling, just like with the CPU), it would invoke the second script above, patching the kernel and re-enabling GPU1. This would then monitor the GPU, and once //its// memory load falls back down to where GPU0 can handle it all, turns GPU1 off and frees that RAM back up for individual use.
I can already foresee a complication where turning GPU1 off "on the fly" would cause a reload of all graphics, but... considering how rare it is to even pull a load above what GPU0 can handle in ordinary use, this isn't much of an issue. It'd take some tweaking and beta-testing (which I'm pretty much set to be a tester of at this point, apparently ) but that would be about it.
Now, //ideally// we could create an alternative solution which wouldn't rely on constantly patching the kernel. As I said; that can get... well, "messy".
I just don't know enough to know what that alternative path would be. Virtual shared memory space seems like it would be a good idea. An alternative solution could be something along the lines of enabling GPU1 at all times and simply having it call to a swapfile which is located in /tmp (I.e.; a non-compressing swap-file which is actually located in RAM). Said swapfile could be resized freely according to need and would thus be no issue at all.
Frankly, I can already see one reason why that would be a superior solution to all the ksplice shenanigans above: said swapfile could be made to be /larger/ than 8 MB, and thus actually provide for an increased performance due to higher available memory for the graphics side of things. We'd want some way to make sure that the swapfile itself wouldn't get pages dumped onto an actual swap partition. This seems like a much more elegant solution than the ksplice routine. I simply have no idea if it's even feasible. The swapfile would have to be mounted into /tmp (or it's Android equivalent) //at the time the GPU1 was enabled//. Is that even /possible/ at boot? Could we simply enable the device very late in the boot stage?
Quickly! Someone with /actual programming expertise/, rescue me from my aimless mental tinkering!
Since it seems there's little activity in this thread, I thought I'd share:
There is a debian armel package for ksplice.
( http://packages.debian.org/squeeze/ksplice )
This is ARM-compiled. We would simply need to cobble together a script which invokes ksplice properly. I myself know nothing of how this would be done.
Usage example of ksplice here:
http://www.ksplice.com/example-update
Looks pretty simple. You just need a working kernel build environment. Anyone got one of those laying around? I have wanted to do that for awhile but am too lazy to set up a linux VM, lol.
Hell yeah!!
Im not much good for this project other then willingness to try betas and give feedback, but I'm excited to see where this goes.. It would be great to reclaim the ram being used from the system when you aren't using anything that needs it and use it for what you are using. Has anyone contacted one of the devs that have been modifying the kernels and ask them if they could try building it with the ksplice functionality?? I would think one of them would be happy to build it so you can start playing with it. Wish I could help more on it, but this is a little above my head, but I will be following this thread and learning what I can as i go.. Good Luck!!
Hi there,
I am on MIUI GB (2.4.13) and I noticed the same issue on CM7, so I guess this is kernel related as I already tried to uninstall every app on my phone.
After 3 or 4 days of use, I can feel the phone waking up slower and having more lags during sweeping home pages or even typing sms.
I use setCPU with no overclock and tried smartass, ondemand and interactive governors, each time having the same issue.
I think this is related to memory usage because after a fresh boot, my phone is about 450 mb free, if I launch successivly all my apps i reach about 400 mb and the phone is still flying.
But after some days of use the available memory drops to 300 mb and lower, and each time I notice this comes with the lags.
Does anyone experience the same issue, or better, knows a way to fix it ?
I don't post really ofter so I will also thank Nexx and superkid for their work on the early stage of the Desire S developpement.
Anyone on this ?
Just to confirm that I am not alone >.<
Maybe a thread somewhere already talks about this...
A few things you could try:
1) V6 Turbocharger by Zeppelinrox HERE
If your new to this you can look here
Using SuperCharger Starter Kit
Click to expand...
Click to collapse
near the bottom of the thread.
Using script manager to open the *.pdf, set as su save then run it you will have many options including 'quick engine flush' and 'detailing' which will help your particular problem. These actions and others can run from your home screen too via widget as a short background process. Once you've ran the script with script manager, exit script manager, choose SM widget from home-screen and find the particular script you ran before. Then you can flush whenever you experience lag building up.
2) Various Cache cleaning programs such as SDMaid etc...
3) A start-up manager to limit which programs boot on start-up. System Tuner Pro is a good all-round program you can try, that is feature rich.
Good Luck
Many thanks, I'll try V6 stuff, the developper is a good seller.
I'll install it on monday and tell my feedback here after 4 or 5 days.
I'm still struggling with my Tab's lags and hickups (see my other post).
I've tried various build prop tweaks without any effects.
I've seen that some have zipalign on boot. To my understanding zipalign is only useful on deodexed Roms but I'm on an odexed one. Can anyone tell me if zipalign has any effect on odexed Roms?
Many tweaks require an etc/init.d folder, but I don't have any. And when I flash a zip that contains an etc/init.d folder with some files in it then none of them appear in my system after I rebooted.
I tried to manually add an init.d folder and then manually copy the zip files into it (with rwx rx rx perms), but it doesn't seem to improve anything.
So I definitely missed something, and I hope that someone amongst you guys will tell me what it is that I missed
Thanks in advance!
unclefab said:
I'm still struggling with my Tab's lags and hickups (see my other post).
I've tried various build prop tweaks without any effects.
I've seen that some have zipalign on boot. To my understanding zipalign is only useful on deodexed Roms but I'm on an odexed one. Can anyone tell me if zipalign has any effect on odexed Roms?
Many tweaks require an etc/init.d folder, but I don't have any. And when I flash a zip that contains an etc/init.d folder with some files in it then none of them appear in my system after I rebooted.
I tried to manually add an init.d folder and then manually copy the zip files into it (with rwx rx rx perms), but it doesn't seem to improve anything.
So I definitely missed something, and I hope that someone amongst you guys will tell me what it is that I missed
Thanks in advance!
Click to expand...
Click to collapse
have you tried this?
https://play.google.com/store/apps/details?id=com.mclaught.mctweaker&feature=search_result
it helped me a lil with stock rom.
Thanks for the tip, I'll try it tomorrow.
To be honest I don't expect too much, I've just spent the whole evening trying various tweaks like supremacy tweak, adrenaline etc. and didn't get any results apart from a bootloop (fortunately I've got a nandroid backup).
I think what I may need for the video lags are scripts like:
ro.media.enc.vid.h263.bps=90000,77000
or:
ro.media.enc.vid.height.min = 144
I took these ones from my galaxy mini (there are plenty of such scripts in the mini's build prop) and I may try to adjust them to the tab.
Anyway, thanks again for the apk, I'll let you know tomorrow...
Ok so I tried, but the apk FCs...
What I need are the right scripts, and some understanding about init.d (see op)...
unclefab said:
Thanks for the tip, I'll try it tomorrow.
To be honest I don't expect too much, I've just spent the whole evening trying various tweaks like supremacy tweak, adrenaline etc. and didn't get any results apart from a bootloop (fortunately I've got a nandroid backup).
I think what I may need for the video lags are scripts like:
ro.media.enc.vid.h263.bps=90000,77000
or:
ro.media.enc.vid.height.min = 144
I took these ones from my galaxy mini (there are plenty of such scripts in the mini's build prop) and I may try to adjust them to the tab.
Anyway, thanks again for the apk, I'll let you know tomorrow...
Click to expand...
Click to collapse
those apps modified the build.prop improperly, which, for our device, causes a bootloop. mctweaker create the init.d folder, then uses their script to modify it on boot. since i'm back on stock, i'm using it again now, and it's working great.
Thanks a lot, I downloaded the latest version and it worked!
No more lags, and as you said it created the init.d folder, with the proper perms rwx rwx rwx (I didn't know, I thought it was rwx rx rx and that's probably why it had failed).
One reason why the tweaks I tried before didn't work is that some of them conflict with each others. For exemple, debug.sf.hw and video.accelerate.hw shouldn't be set both with a 1 value coz it causes lags. The proper values are:
debug.sf.hw=0
video.accelerate.hw=1
I wish I had known this apk before, instead of struggling on my own with all those scripts...
Thanks again mate, I love XDA!!!
unclefab said:
Thanks a lot, I downloaded the latest version and it worked!
No more lags, and as you said it created the init.d folder, with the proper perms rwx rwx rwx (I didn't know, I thought it was rwx rx rx and that's probably why it had failed).
One reason why the tweaks I tried before didn't work is that some of them conflict with each others. For exemple, debug.sf.hw and video.accelerate.hw shouldn't be set both with a 1 value coz it causes lags. The proper values are:
debug.sf.hw=0
video.accelerate.hw=1
I wish I had known this apk before, instead of struggling on my own with all those scripts...
Thanks again mate, I love XDA!!!
Click to expand...
Click to collapse
i found the app by accident too. glad that it works, it helped to simplify a lot of manual typing/copy pasting works. to be honest, before this, i didn't know build.prop allows so much tweaks. some of them i have only seen on the app.
gingerboy92 said:
i found the app by accident too. glad that it works, it helped to simplify a lot of manual typing/copy pasting works. to be honest, before this, i didn't know build.prop allows so much tweaks. some of them i have only seen on the app.
Click to expand...
Click to collapse
Yep, it has some very nice ones...
Actually some of this apk's tweaks can be found in scripts like v6, adrenaline etc., but the good thing with this apk is that it allows fine tuning and sets everything with the right perms.
A little gem, highly recommended!
There.s not a lot you are going to get from these apps or build prop mods. The Samsung developers are not idiots or evil.
I always wonder what people are doing to their tab to get such poor performance. I mean after all, this tab has a fast processor, gobs of memory and the stock firmware is pretty lite and smooth. There's nothing you can do to fix any tab or phone if you load up 500 active widgets and live wall papers and then try to play some non-hardware acceleration supported off beat video. Check which apps or widgets you are running. Some of them are really poorly written. Use a good CPU / battery analysis app off the market to find out whats going on.
DigitalMD said:
There.s not a lot you are going to get from these apps or build prop mods. The Samsung developers are not idiots or evil.
I always wonder what people are doing to their tab to get such poor performance. I mean after all, this tab has a fast processor, gobs of memory and the stock firmware is pretty lite and smooth. There's nothing you can do to fix any tab or phone if you load up 500 active widgets and live wall papers and then try to play some non-hardware acceleration supported off beat video. Check which apps or widgets you are running. Some of them are really poorly written. Use a good CPU / battery analysis app off the market to find out whats going on.
Click to expand...
Click to collapse
Waow, nice arrogancy mate...
So you assume I have 1 zillion widgets, use ****ty apks and don't know what I'm doing with my tab?
Sorry to disappoint you, and with all respect due to your 100000000 posts, but I use 0 widgets (I don't like that useless battery consuming stuff), I don't use live wallpapers (same story), the video player I use is mx, I have skinned my rom as much as possible (I removed all the bloat and even more, only 30 system apks are remaining) and I don't play games.
So you see, maybe next time you should think twice before assuming this or that.
This said, I agree with your signature...
Remember to have the screen turned ON while you apply the script!!!
Hi guys!
Today i want to share with you a script i specifically tailored for our 4C, to decrease high battery drain just by tuning parameters of the interactive governor.
As many of you know, on the Nexus 5X forum there is a huge post about different profiles created to achieve the same purpose, and almost all of them works with our device (personally tested)
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!
I raccomed to read it!
One of them in particular was extremely good battery wise but i felt some lagginess here and there (talkin about HawkTail 1.2)
So i decided to make a script myself and share it with you, the idea behind it is to force the CPU to scale better with loads and making the Big cores in use more frequently by tuning some of the kernel parameters.
Plus we will have the GPU idling @ 180MhZ instead of 300MhZ (like in the Nexus 5x) and a switch to noop scheduler.
Performance wise and taking in example the latest stable ROM from Xiaomi.eu (8.0.5) we will have a decrease of about 5k point in Antutu (I'll attach two screenshots, the 71K was the result without tweaking, plus just by switching back to CFQ scheduler you'll get 2K points back but NOOP is more battery friendly)
So here you go, this is my script TAO.
Using it is pretty simple and you have a couple of options: [ROOT IS NEEDED]
Since it's a script, if your rom have INIT.D folder support, you can just move the file under /etc/Init.d and reboot the device. The script will make a log file under /sdcard/TAO.log that you can check if anything went wrong.
The second option, if your rom doesn't have Init.d folder support, just use Kernel Auditor and a text editor.
Open the downloaded file in a text editor, select all and copy the text.
Then open Kernel Auditor, and in the menu look for init.d, enable the "Emulate Init.d" and then click the "+" symbol. It will ask to add a name (let's set it to TAO for coherence), then OK. It will open a new window where we have to paste all the text previously copied, save it by pressing the icon on the top right. Now we can just reboot the device or click the newly created item and select execute.
Third option is to run it manually from terminal.
Plus, i'll add my Thermal-engine-8992.conf that you guys can use to change the thermal throttling values. Download it and replace it in /system/etc/ , set it with permission 644 and reboot.
This modded thermal will move up the limits, long story short, your device will continue to perform even if it gets hot.
Enjoy! & report back for feedback
Remember to have the screen turned ON while you apply the script!!!
P.S.
Files are zipped, extract them!!!
UPDATE
Minor update - use_sched_load set to 0 for both cores
Correction made for the log file
UPDATE 0.7
Since @solis_f is having some problem with the big cores, and this could be a common problem to many others too i've decided to add something in the script that will force the big core online so you should not have any more problem executing the script. Let me know
UPDATE 0.8 - Experimental
Updated Target_loads for both Little and Big cores.
Little core min freq. to 384 MhZ.
Input boost @ 787 MhZ instead of 600 MhZ.
hispeed_load disabled for both cores.
Updated values for UpMigrate.
Enabled core_ctl for big cluster:
With this update, you'll have your big cores Offline most of the time, but they will comes online when needed.
Yours perfd (/data/system/perfd/default_values) with this version have to look like this:
Code:
ihf;787200
iahd;38000
ighl;200
itl;39 460800:5 600000:62 672000:10 787200:81 864000:90 960000:99
gpu_default_pwrlvl;5
sst;33
smil;20
sminr;3
sitl;65
sum;66
sdm;54
cbmf;1525
cbhdr;90
cbhip;16
ihf0;787200
iahd0;38000
itl0;39 460800:5 600000:62 672000:10 787200:81 864000:90 960000:99
imst0;0
ighl0;200
imf0;0
itr0;30000
its0;-1
iiib0;1
intb0;0
ibd0;0
ihf4;1248000
iahd4;38000
itl4;53 768000:64 864000:72 960000:79 1248000:99
imst4;0
ighl4;200
imf4;20000
itr4;30000
its4;-1
iiib4;1
intb4;0
ibd4;0
P.P.S.
Over two hundred downloads, but not even half of you gives me feedback...
UPDATE 0.9
Sorry for the delay, many things to do IRL.
This version is what i'm using now, should be smoother then v0.8, hope you like it.
nice one, will try this
Did you try to run Antutu several times in a row, so we can see is the result of 66k almost constant. Since as we all know, results can degrade towards 44k because of overheating..
predragiPredrag said:
Did you try to run Antutu several times in a row, so we can see is the result of 66k almost constant. Since as we all know, results can degrade towards 44k because of overheating..
Click to expand...
Click to collapse
I did not, but degradation of score is dictated by the thermal config. That's why i modded that too, and pushed the standard limits...
Let me show you with an example:
Code:
[SS-SKIN-XO-THERM-PERF]
algo_type ss
sampling 250
sensor xo_therm_buf
device cluster1
set_point 43000
set_point_clr 37000
time_constant 0
device_max_limit 800000
This is taken from the original file, and it covers the big cluster... when it reach 43° celsius, the thermal throttling will limit the max frequency of the cluster to 800MhZ
Code:
[SS-SKIN-XO-THERM-PERF]
algo_type monitor
sampling 5000
sensor quiet_therm
thresholds 46000 48000 50000
thresholds_clr 44000 46000 48000
actions cluster1 cluster1 cluster1
action_info 1632000 1248000 960000
This is the same part but modified by me, i've added more step... as you can see thermal throttling for big cluster will work once the big cluster reach 46° and it will cut the max frequency to 1632MhZ, then at 48° 1248MhZ and at 50° at 960MhZ
The hot-plug, that put the cores offline, on the original file for the big cluster is marked at 42° for core 4 and 45° for core 5.
On my config file both cores will be hot-plugged once they reach 52°.
TL;DR if you use my thermal-engine conf file, you will get more consistent score on several runs.
Nice to hear that will try this when I have more time to play with my phone and report back.
Great work and thanks for sharing this
GoldGanja said:
Hi guys!
Today i want to share with you a script i specifically tailored for our 4C, to decrease high battery drain just by tuning parameters of the interactive governor.
As many of you know, on the Nexus 5X forum there is a huge post about different profiles created to achieve the same purpose, and almost all of them works with our device (personally tested)
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!
I raccomed to read it!
(...)
Enjoy! & report back for feedback
P.S.
Files are zipped, extract them!!!
Click to expand...
Click to collapse
Hi,
I can not apply root because of he problem between pokemon go and root, (I am playing pokemon go with my 8 years old son a father-son activity and he loves it)
I am using a dev miui rom and i did tune my thermal-engine and remove the input boost using the TWRP file manager to apply the files.
This rom does not have init.d folder could i call your script from init.qcom.post_boot.sh? if so, do you know how to?
best regards,
John
You should look for some sort of systemless root, and magisk to masquerade root and be able to play Po Go on a rooted phone. I don't think you can chain load the script within post_boot.sh and by the way to modify it you should have super user permissions. Anyway keep up the father and son activity, is way more important!
Sent from my Mi-4c using Tapatalk
GoldGanja said:
You should look for some sort of systemless root, and magisk to masquerade root and be able to play Po Go on a rooted phone. I don't think you can chain load the script within post_boot.sh and by the way to modify it you should have super user permissions. Anyway keep up the father and son activity, is way more important!
Sent from my Mi-4c using Tapatalk
Click to expand...
Click to collapse
thanx, my son does not talk about anything else...
About the chain load the TS rom does that with ts_power.sh file.
Code:
# ts power scripts permissions
chown -h system /system/etc/ts_power.sh
chown -h system /data/ts_power.sh
Code:
# Call ts_power.sh, if found
if [ -f /data/ts_power.sh ]; then
logi "Call /data/ts_power.sh set_profile $profile"
sh /data/ts_power.sh set_profile $profile
elif [ -f /system/etc/ts_power.sh ]; then
logi "Call /system/etc/ts_power.sh set_profile $profile"
sh /system/etc/ts_power.sh set_profile $profile
fi
I will try to see if it works using your script.
About systemless root, i don't want to be in the middle of the cat and mouse thing. Today google update and tomorrow there is another hide root.
I did replace the thermal engine using the twrp file manager. It works.
Nice share bro. Thermal engine + init.d script is good battery backup for mi4c.
Hello,
could you make patched files available and the place where they should be placed ?
I don't want to root my phone but I want to give your optimisation a try. It is possible with TWRP to replace the files in the file manager. More work but it can be done without root. Therefore however I will need the allready patched files....
A little more "complicated" even... might it not be possible using TWRP to flash these files ? I have no idea how that would work exactly but I can imagine it would be possible to create a flashable zip that replaces these files... It currently goes beyound my abbilities though unfortunatly but maybe someone can help with that.
Thanks for your share @GoldGanja , looks interesting.
But i think the thermal-engine.conf would cause more overheating as it is already (for me reduce overheating is the most important), but i like the way to reduce the clockspeed step by step. Maybe i will try it with lower values.
The modified governer looks great. I think this will help with heating too. But on this there aren´t laggings ?
Thank you! i hope this fix my battery drain and the heat, i'll report if i see changes
@nachtwacht
Even if i make a zip file to use with twrp, this will only be useful for the thermal-engine conf file...because the other one is a script i've created and so there is no other file to replace. As stated ROOT is needed, i'm sorry.
@Danny94
thermal-engine.conf per se will not increase or decrease over-heating, of course one could make a conf file to be more restrictive on the temps and brutally decrease the performance but i don't see the need of this because i don't have any over-heat problem within my device with the script i've made. A major cause of over-heating is the input-boost frequency that by default is set to 1248MhZ, while if you run my script it will be 600 MhZ. Farther i have no lags at all...give it a try and report back. More feedback I have about it, the better I can adjust some parameters.
@HYBRIDEMON
Thanks!
@GoldGanja
Yeah i will try tomorrow if i get some free time.
Wich Rom do you use ? I have at almost all roms overheating problems. After 10 min+ of 3d gaming i have ~55°c + (On my old phone Thl 5k i could play the same game hours, don´t get over 45 °c and no lagging or something - and yeah its not the best phone).
With your thermal config the device throttles later. So it will heat higher, until it shut down big core etc. As hotter it becomes as more difficult its to cooldown. Sure if you won´t reach 52°c would be perfect one. But maybe i will replace the values with lower, else it looks very good.
I can't find tao.log at sdcard.
Script is applied or not?
I copied to etc/init.d and set 755 permissions.
Edit:
Finally I applied manually and I have 2 errors with big cluster settings.
Enviado desde mi Mi-4c mediante Tapatalk
@dany94
I'm using last stable from xiaomi.eu (8.0.5). Anyway, if you get to know how the gears of the thermal engine works, do what is best for your usage. Feel free to change the numbers on my file if needed
siba01 said:
I can't find tao.log at sdcard.
Script is applied or not?
I copied to etc/init.d and set 755 permissions.
Edit:
Finally I applied manually and I have 2 errors with big cluster settings.
Enviado desde mi Mi-4c mediante Tapatalk
Click to expand...
Click to collapse
I think you are using a CM TS rom, right? well, for that you have to do two things.
First, set the battery mode to QUICK, because on BALANCE there is the hotplug of the BIG cores. Then re-run my script.
If that's not the case, maybe the device was just a bit hot, and the hotplug kicked in by the thermal-engine...let it cool down first or use my thermal-engine conf.
Second, rename my file to userinit.sh and place it under /data/local if you want the settings to be applied at each boot.
GoldGanja said:
Even if i make a zip file to use with twrp, this will only be useful for the thermal-engine conf file...because the other one is a script i've created and so there is no other file to replace. As stated ROOT is needed, i'm sorry.
Click to expand...
Click to collapse
Maybe I was not clear or, more likely I do not completely understand which is a fact for sure
Let me clear up the first part, then hopefully in the end I will also better understand
Your script chances several files if I understand correctly ? scaling_min_freq for example is the first one you change in the script ?
Could we not update all the files that you change using TWRP ?
My guess is, (that's just me trying to understand better.....) that I think that using TWRP it is possible to change these files without root, but in reality it is not because the phone is not rooted ? Maybe because only the complete system can be changed and not single files ? (without root)
I do know that in the end, for me it is possible to root my phone, apply the settings, and then unroot it again.... which hopefully have my phone working like it never was rooted... it's just a risk I would like to avoid if in any way possible, therefore I am investigating and trying to get it all clear for me, sorry for that
GoldGanja said:
@dany94
I'm using last stable from xiaomi.eu (8.0.5). Anyway, if you get to know how the gears of the thermal engine works, do what is best for your usage. Feel free to change the numbers on my file if needed
I think you are using a CM TS rom, right? well, for that you have to do two things.
First, set the battery mode to QUICK, because on BALANCE there is the hotplug of the BIG cores. Then re-run my script.
If that's not the case, maybe the device was just a bit hot, and the hotplug kicked in by the thermal-engine...let it cool down first or use my thermal-engine conf.
Second, rename my file to userinit.sh and place it under /data/local if you want the settings to be applied at each boot.
Click to expand...
Click to collapse
I'm using Resurrecction Remix.
Thanks for your answer.
Enviado desde mi Mi-4c mediante Tapatalk
I was pretty sure you will do such a good job for Mi4c! Well done!
Edit: btw big cluster values are not getting applied
solis_f said:
I was pretty sure you will do such a good job for Mi4c! Well done!
Edit: btw big cluster values are not getting applied
Click to expand...
Click to collapse
What ROM are you using?
Sent from my Mi-4c using Tapatalk