Related
Ever since I first released an undervolted kernel (can you believe that it actually used to be a new idea? Seems so normal now), its been a mad dash to see how much further down the voltage can be pushed. In light of recent events, there has been controversy regarding whether or not dropping below ~925mV actually begins to negatively impact battery life.
Without getting into the technical details behind why I believe that going that low actually does affect battery life, I'm conducting a blind study. I'm going to produce 3 kernels at three different voltages. I'm then going to send these kernels randomly to people that sign up on the attached spreadsheet in order to collect data for 7 days.
I know that this won't be 100% accurate, but I feel that if we get a large enough sample size, over 7 days, the general trend should emerge.
What I ask for you to do if you want to participate is sign up on the attached spreadsheet and try not to change your rom/usage patterns within these 7 days. Just go about your day and record your values at the end.
You will not know what the voltage of the kernel you are receiving is, so there will have to be a certain degree of trust. I promise I will do my best to not blow up your phone
This truly has to be a community effort. The more people we have, the better. Once the study has been concluded, I will reveal which kernel had the best battery life for the most amount of people.
Please spread the word about this, the more it is on blogs and the like, the greater the sample size and the more accurate the results.
Link: http://bit.ly/9YjM5X
UPDATE:
The kernels have all be emailed to people that gave me an email address. Tues-Sat, please run the kernel that is labeled CONTROL. Do not alter your day to day usage from what you always do. At the end of each day please record how long you were off charger and your percent battery left. Use your best judgement for giving statistics. The more detailed, the better.
Sunday-Thurs we will run the TEST kernel. Again do the same thing and record your usage daily.
It is VITAL that you record the statistics at the end of the day every day.
As an added bonus, I included the memory modification by coolbho3k because I know you all want the latest and greatest
Will it matter what battery we have? Or is stock battery required?
Four Fourty Four said:
Will it matter what battery we have? Or is stock battery required?
Click to expand...
Click to collapse
doesn't matter as long as you post your previous results so we have something to base it against.
This is a fantastic idea. Might actually help me recover from my kernel flashing compulsion. Prolly not though....
Persiansown, what do you mean by "record your values at the end"? Are we to take a log of battery usage or just writing down on the sheet what the usage was like each day?
thanks
jblazea50 said:
Persiansown, what do you mean by "record your values at the end"? Are we to take a log of battery usage or just writing down on the sheet what the usage was like each day?
thanks
Click to expand...
Click to collapse
Its going to be subjective but I'm trying to figure out the best way to record them right now. I don't need any feedback values until I actually send out the kernels though
persiansown said:
Its going to be subjective but I'm trying to figure out the best way to record them right now. I don't need any feedback values until I actually send out the kernels though
Click to expand...
Click to collapse
yeah, i understand that it's not needed until after we start using the kernel; just wanted to know what you were actually looking for, and if it wasn't subjective
thanks and looking forward to this
im really interested in this. would it also be possible to give feedback on reception? because as of late my signal has been worse with all the uv kernels...
How are we going to set the baseline? The best way to eliminate the potential for usage differences to skew the results is for us to all run the exact same kernel for X amount of time to set a baseline, then do the blind test of the 3 different kernels, and compare the difference between before and after.
pjcforpres said:
How are we going to set the baseline? The best way to eliminate the potential for usage differences to skew the results is for us to all run the exact same kernel for X amount of time to set a baseline, then do the blind test of the 3 different kernels, and compare the difference between before and after.
Click to expand...
Click to collapse
Yeah I've been trying to think of a way that would take less time, but I think that way would be best. Anyone have a better suggestion?
persiansown said:
Yeah I've been trying to think of a way that would take less time, but I think that way would be best. Anyone have a better suggestion?
Click to expand...
Click to collapse
We could also look at time spent "running" in spare parts... but that would be much more complicated and less accurate (I would hate to do the statistical break down on that)... but it would be much quicker and would provide some nice info as well... ie 5 hours spent running and 7 hours sleeping used 80% battery... where as 1 hour running and 11 hours sleeping used 50%... but we would also have to factor in so many other aspects and track those to get a truly accurate picture, ie WiFi or 3G or 2G... what is your screen brightness... and so forth.
Hey persian, this is a great idea!!! to get to the bottom of all this.
Can I suggest something though, and hope I don't get flamed for it, or hope you wont take it the wrong way. But will you include, an AVS kernel running 800mV as well? There have been discussions about this also. Thanks!
Each tester would have to test all three kernels and try to maintain roughly the same useage. Was this your plan?
pjcforpres said:
How are we going to set the baseline? The best way to eliminate the potential for usage differences to skew the results is for us to all run the exact same kernel for X amount of time to set a baseline, then do the blind test of the 3 different kernels, and compare the difference between before and after.
Click to expand...
Click to collapse
This is a good approach. But I think for it to be even more standardized one would need to run this completely app and theme free. THe interaction between certain apps and usage is an unknown variable. For example, how much does K-9 mail draw? It goes without saying that themes have some sort of affect on behavior. So IMO, to be as objective as possible you would need to remove all sources of ambiguity to have this test mean something. Just my two cents
pjcforpres said:
We could also look at time spent "running" in spare parts... but that would be much more complicated and less accurate (I would hate to do the statistical break down on that)... but it would be much quicker and would provide some nice info as well... ie 5 hours spent running and 7 hours sleeping used 80% battery... where as 1 hour running and 11 hours sleeping used 50%... but we would also have to factor in so many other aspects and track those to get a truly accurate picture, ie WiFi or 3G or 2G... what is your screen brightness... and so forth.
Click to expand...
Click to collapse
That would be pretty complicated and I think Kmobs would need a grant to run the statistics. I think there would have to be a baseline established like GPS off, brightness set to x percent, bluetooth off etc. And I think as Kmobs knows, each chip was not created equally.
Persiansown, I don't think you need to start with a baseline in order to compare. Once you send out the kernel and we use it for 1 week with normal usage for each user. At the end of the week, you can send out another kernel, exactly the same this time for everyone, and we can use it for few days and we will be able to notice the difference.
Correct . This is how I thought he was gonna do it. And what I think is best.
jblazea50 said:
Persiansown, I don't think you need to start with a baseline in order to compare. Once you send out the kernel and we use it for 1 week with normal usage for each user. At the end of the week, you can send out another kernel, exactly the same this time for everyone, and we can use it for few days and we will be able to notice the difference.
Click to expand...
Click to collapse
pjcforpres said:
How are we going to set the baseline? The best way to eliminate the potential for usage differences to skew the results is for us to all run the exact same kernel for X amount of time to set a baseline, then do the blind test of the 3 different kernels, and compare the difference between before and after.
Click to expand...
Click to collapse
persiansown said:
Yeah I've been trying to think of a way that would take less time, but I think that way would be best. Anyone have a better suggestion?
Click to expand...
Click to collapse
I was trying to think of a good way to get a baseline to compare to for every one and this is my sugestion. Make three kernels at 850, 925, and control/stock. Send everyone on the list two kernels, one of the two UV kernels and one stock/control. Allow them to run the first kernel for a certain number of days, record data, then send everyone the second kernel and do the same. Randomize who gets the control first or the UV first and keep it blind. (Don't tell them which of the two is the control obviously.) This way half test the 850, half test 925, and all test the control/stock, giving you an accurate baseline for everyone's individual phone usage and battery size.
Scientific Method FTW!!!
awesome idea.
Count me in...I will sign up when I get home from work tonight. This is an excellent idea. Ideas lke this is what make xda the number one source for android information.
I have around a strange persistant problem.
I have around 250MB of internal app storage space left and used about 650Mb of storage of apps on my external 32Gb SDHC card.
I am using autostarts and task manager to manage the start up of apps and stop things running which works really well at prolonging battery life to the point where I reach a good 14 hours with heavy use on battery (I have five e-mail accounts pushed all sorts of widgets and use the phone fairly heavily on an average day, admittedly I get a little less if I use multimedia to any extent) I am using a stock 2.3.5 build from which I have removed some bloat stuff so I have about 35MB of rom storage left. It's rooted and has CWM installed etc.
In total I have something approaching 650 app elements in Titanium Backup depending on what I do or dont have installed at any given point.
Without the SD card the phone boots fine everytime. With the SD card in depending on the amount of .asec files in the .android secure folder the phone will often boot up and then during the processes after boot semi crash. By this I mean it will boot up then about 2-5minutes during the afterboot it will stop working and drop in a loop where it is still trying to run after boot process like scanning for media and stuff but loses connection with the carrier and then loops. Removing the sdhc card and moving some of the .asec files out of the the .androidsecure folder usually fixes this. It does not come up with safe mode or anything like that.
Has anyone else experienced this? Have I simply reached the limits of what the phone can do? My guess is that the problem lies with the process of copying/unpacking the .asec files into the /mnt/asec structure?
Can anyone offer any useful advice the 32Gb SDHC card is only class 2 (all that was available when I got it) I am thinking a faster one MIGHT solve the issue but that seems only a possibility and investing in a new card simply to find out it doesnt fix the issue would be a relatively expensive mistake. Has anyone else found similar limits?
You realise that's intimidatingly long to read right? Please write in shorter forms.
Sent from my GT-I9100 using XDA App
ionious said:
You realise that's intimidatingly long to read right? Please write in shorter forms.
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
Not exactly helpful... Its far better to have a decent descriptive long post than people who writes "I have tons of apps but I get problem with connection".
@op I also have a tons of apps, fairly close to the amount you have, but still have quite a bit of space left, do you make a lot of backups and such? Check your SD card, because I remember a post here saying that deleting files within the lost folder can save space. (some people lost GBs, some just a few MBs) Best if someone here can confirm its safe to delete the files within though.
A known problem with some phones is 32GB cards some work well others dont some phones play up others dont .64GB even worse .
jje
Hmmmm seems like you are stressing the filesystem's/IO scheduler's timeout limit to the max with a class 2 card.
I would recommend you doing two things:
a) You have your phone rooted, try installing SiyahKernel, Voltage Control and change the I/O schedulers - thru set on boot -> init.d script (try alternating between noop, sio, bfq and VR), if that still doesn't help, try adding Thunderbolt Scripts as well - especially the remount script via script manager (links in my sig).
b) Try a different rom perhaps? Stock ROMs are not the most optimized things under the sun in terms of SGS2... back up your media to your PC, do a nandroid/titanium backup to your external sdcard and try flashing another rom. If it doesn't work, you can always restore the nandroid.
Hope it helped somewhat ^^
Thanks for the advice guys, think I might see if I cant test a faster card off a mate see if that helps.
Otherwise I will try that syrah kernel and scripts, not too keen to go for custom roms my experience of them with the galaxy s was they all seemed to have a major bug that I couldn't live with I always ened up back on stock with mods. Haven't really tested any on the s2 but if I were to I would need to be very stable with very few bugs. I also kind of like some of the samsung stuff? for example I'm using a hack versions (fragg0rs) of TW4 with it I can run the buddies now widgit from the original galaxy s and I love that. nearest thing I can find to the carosel I used to get on the samsung omnia i8910 (great phone badly let down by symbian)
To the guy that criticised the length of the original post on top of what else that has already been said, do you have the first clue about troubleshooting? especially an issue that is not referenced anywhere else? The golden rule is the more information the better. This is an issue I have been working around now for several months, I have been searching for similar (on and off not obsessively) issues posted anywhere and found nothing that helps but thanks for your rather pointless input stick to helping with the noob posts eh?
This is known problem. I have this problem too.
Several threads already talked about this since long time ago.
Here are some of threads exactly describing same problem with OP:
http://forum.xda-developers.com/showthread.php?t=1285844
http://forum.xda-developers.com/showthread.php?t=1102920
http://forum.xda-developers.com/showthread.php?t=1328191
http://forum.xda-developers.com/showthread.php?t=1446961
That last one is the thread I created last month and still active until now.
So here is the summary:
- This problem is side effect since ROM version 2.3.5.
- Version 2.3.4 and earlier does not have this problem.
- This problem still exists in ICS LPB leak
- It seems that Samsung does not know about this problem.
The only workaround solution:
- Downgrade to version 2.3.4 or below
For us who have this problem, please add your post to the thread I created above (http://forum.xda-developers.com/showthread.php?t=1446961) and rate high to keep the thread alive so it will get attention from many users and hopefully from Samsung.
you just saved me money buying a new card thanks for that.
Hi all,
I was looking into overclocking and underclocking the hummingbird processor withing my galaxy player 5.0
The overclocking is obviously for fun (I know the risks to the CPU and battery), the uderclocking is more so for power management.
I so far have not been able to go past the 1 GHz on the stock kernel.
Has anyone else tried this on stock/custom kernel and gotten any descent results?
I'm intrested in your expierences.
---------------------------------------------------------------
I'd upload the 5.0 compatible kernel and ROM into my device to use it and try it out; I found it on this sight, but I have been stuck on attempting to backup my current Kernel and ROM, as I do not want to loose it.
(I'm trying to do it "manually" with a program that was meant for something totally different, its interesting on the parts of data I could dump, but nothing is usable).
But aside from that, I have been trying different things with just the root on stock kernel and ROM, and I have found a few things that were fun to play with like the droid wall and an SD speed up...
-----------------------------------------------------------------
honestly I do not see anything else I need/can use the root for right now...
An I missing something? Is the android that open...?!
(This is coming from someone who worked and worked to unlock an iPod touch and turned it into an iPhone and partially into a pocket PC)
I remember the kernels name: Entrophies Kernel (idk how to spell it)
(Its on this forms sight in a different category somewhere)
-I'd use it, but first I'm putting back the stock charging and battery management, I personally do not like the settings he has, Li-Ion Polymer batteries like a complete charge, and a steady charge with a taper at the end...
-----------------------------------------------------------------
Any thoughts and experiences on anything I had not asked about is also welcome.
Everywhere I look for information about this device, I keep finding random one posts with questions and never any answers.
Also, people seem to not know about this device, and also not know how to modify and back its data up, including me with my failed atempts... o_o
Ultimately, if I can figure enough out about this device, because everything I have found so far is scattered about online, I'd like to make a post and dedicate it to the galaxy 5 player eventually, with up-to-date (or as close as possible) info on many things. Because thats the biggest problem I see, nothings ever centralized.
If you have root then This should work on your 5.0 player. I just installed it (stock) to try after seeing your post and i already have my 5.0 overclocked to 1.1ghz
Tegrak Overclock is a great utility to over and under clock your CPU.
[root]How to back up your current kernel U.S 5.0 YP-G70
Download MDump Partition dumper v0.02: link in signature!
Open MDump on your device and select "mmcblk0p11"
Rename the file: mmcblk0p11.mdump -> zImage
Touch "Start Dump"
Move the file to a linux machine and put it in a tar ball. (example command: tar -H ustar -c zImage > kernel.tar)
You now have a backup of your stock kernel which you can reflash using odin! (kernel.tar)
Update: I just noticed that you wanted the ROM too, it's mmcblk0p13. You can just dump that as well; rename it "factoryfs.rfs" and include it in the tar ball.
I plan on eventually adding support for clocking at 1.2 GHz and voltage control - I've just been busy with some issues with my I777 kernel (SoDs... ) and busy with real life in general.
I won't be just grabbing rumirand's patches as his use a slightly different approach than the netarchy-style code I prefer.
wow thanks everyone for the fast replies, I'm replying to each post in order, I added quotes to show which ones I am replying to.
murph5525 said:
If you have root then This should work on your 5.0 player. I just installed it (stock) to try after seeing your post and i already have my 5.0 overclocked to 1.1ghz
Click to expand...
Click to collapse
Thanks for the link, I added the app to my device, and overjoyed, I clicked on the 1.3 GHz setting and applied it!
I do not see much of a difference as my device never lagged, if that, before.
I tried a few benchmark utilities, and it seems to surpass almost all the single core CPU phones I looked at...
dunca123 said:
Tegrak Overclock is a great utility to over and under clock your CPU.
Click to expand...
Click to collapse
I was playing with the underclocking features, and my already 2-2.5 day battery looks like it will last another day...lol
Meticulus said:
Download MDump Partition dumper v0.02: link in signature!
Open MDump on your device and select "mmcblk0p11"
Rename the file: mmcblk0p11.mdump -> zImage
Touch "Start Dump"
Move the file to a linux machine and put it in a tar ball. (example command: tar -H ustar -c zImage > kernel.tar)
You now have a backup of your stock kernel which you can reflash using odin! (kernel.tar)
Click to expand...
Click to collapse
I was not expecting this... Thank you very much, you just saved me a lot of trouble!
I'm trying this in a few days, I've got a couple tests to study for this week...
Entropy512 said:
I plan on eventually adding support for clocking at 1.2 GHz and voltage control - I've just been busy with some issues with my I777 kernel (SoDs... ) and busy with real life in general.
I won't be just grabbing rumirand's patches as his use a slightly different approach than the netarchy-style code I prefer.
Click to expand...
Click to collapse
I really like your kernel, you have done a nice job with it!
I was just wondering if you are keeping a single serries of the kernel or one with the modified power management, and one without?
Reason asking, is that I'm an EE, and I know a few people who work with battery management, and they all tell me the Li-Ion Polymer batteries like to be fully charged. I'm just curious as to your approach/reason behind stopping the charge just short of the top?
I like your selections for the custom charging with the kernel for quicker charge times... when I eventually get your kernel onto my device, I'm going to see if I can change settings while its installed, kinda like a power charge for when needed, and a regular charge for over night for less stress...
-------------------------------------------------------------
idk, I'm new to android, I've been stuck in i-Devices lingo for a long time and I'm slowly figuring this android stuff out...
So far, the only real thing I actually needed root for is overclocking and underclocking, droidwall, and tor... I like how open the system is (aside from the kernel/boxroom seeming to be locked when my friend tried a program called adb on it the other day).
Just curious, anything fun I can do with a custom kernel/rom? the only thing I see it can do so far from searching a few links is themes? idk, i need to look into it more...lol
I came across running ubuntu linux on the device through a vnc, even though its installed on the device... I was thinking of trying that if it looks like its ok...lol
I'm just a bit excited, I have this thing that can do so much, but idk what to do with it other than using it as a free wifi phone so far...lol
zBusterCB87 said:
I really like your kernel, you have done a nice job with it!
I was just wondering if you are keeping a single serries of the kernel or one with the modified power management, and one without?
Reason asking, is that I'm an EE, and I know a few people who work with battery management, and they all tell me the Li-Ion Polymer batteries like to be fully charged. I'm just curious as to your approach/reason behind stopping the charge just short of the top?
I like your selections for the custom charging with the kernel for quicker charge times... when I eventually get your kernel onto my device, I'm going to see if I can change settings while its installed, kinda like a power charge for when needed, and a regular charge for over night for less stress...
Click to expand...
Click to collapse
I'm an EE myself. That's odd - all information I've ever seen says that Li-Ion and Li-Po batteries do NOT like to be fully "topped off" or "trickle charged".
I'll try to dig up my sources later, but, from memory:
Overcharging them can result in metallic lithium plating out, which leads to permanent capacity loss. This is why all Li-Ion chargers stop charging once current drops below a certain rate in the constant-voltage phase. In the case of almost every Samsung I've ever used, CPU/power usage counts against the charge current limit - so I'm REALLY paranoid about the charger terminating properly, which is why I make it cut off earlier, as a way of offsetting some of the stress on the battery that the charging rate bump creates.
Also, Li-Ion batteries stored at maximum charge will lose capacity far faster than ones stored at around 50% charge. (This is why almost all new devices have batteries only 50% charged or so.)
I may eventually add a feature to disable the increased charging rate at runtime, however, in the case of the Galaxy Player:
It has a 2500 mAh battery, so 800 mA is actually still less than C/3 charge rate for the battery, whereas on most Galaxy S phones, they charge at 600 mA for an (approximately) 1650 mAh battery, making charge rate slightly more than C/3.
I also reduce charge rate below stock near the top - the technique is inspired by this: http://www.engadget.com/2011/02/20/apple-patent-application-points-to-denser-batteries-improved-ch/
idk, I'm new to android, I've been stuck in i-Devices lingo for a long time and I'm slowly figuring this android stuff out...
So far, the only real thing I actually needed root for is overclocking and underclocking, droidwall, and tor... I like how open the system is (aside from the kernel/boxroom seeming to be locked when my friend tried a program called adb on it the other day).
Just curious, anything fun I can do with a custom kernel/rom? the only thing I see it can do so far from searching a few links is themes? idk, i need to look into it more...lol
I came across running ubuntu linux on the device through a vnc, even though its installed on the device... I was thinking of trying that if it looks like its ok...lol
I'm just a bit excited, I have this thing that can do so much, but idk what to do with it other than using it as a free wifi phone so far...lol
Click to expand...
Click to collapse
Well, on many Android devices, root is needed to kill carrier bloatware. It happens that wifi-only non-carrier-branded devices tend to be less mangled and require less debloating. (Often none...) I've frequently run stock system firmware with custom kernels on wifi-only devices for long periods of time - but carrier-mangled devices almost always need an immediate debloat.
Has anyone gotten the supercharger v6 script to work with the Galaxy Player 4.0? Every time I run it it says error "unterminated quoted string" and "busybox: not found." I have tried reinstalling busybox different versions, but it still shows the errors. When I choose to continue it says that I'm not running the script in root mode, when I actually am.
Sent from my Galaxy Player 4.0 (YP-G1)
Weird, It woked for me, but I wasn't imppressed with it and uninstalled it.
V6 Supercrapper is awful... The author is constantly throwing random crap in with no clue what he's doing. For example, at one point he disabled the panic reboot timeout, which on a mobile device can permanently damage your battery by putting the kernel in an inifinite loop until the user catches it and reboots manually. (It disables the kernel's low-battery shutdown safeties, leaving only the battery's own protection circuit as the ONLY line of defense against permanent battery damage.)
His script is hundreds of kilobytes of echoes and printouts with all sorts of hype and marketing and very little substance. It's interesting that he uses the car analogy, because in the United States, gearheads have a term for the sort of stuff he does - that term is "ricer".
In my opinion, comprehensive tweak scripts should be avoided at all costs - pick and choose clearly documented tweaks, don't just trust someone to throw a bunch of crap together for you, because 90% of the time it is just that - crap.
Also, this does not belong in Development, it belongs in General.
Entropy512 said:
V6 Supercrapper is awful... The author is constantly throwing random crap in with no clue what he's doing. For example, at one point he disabled the panic reboot timeout, which on a mobile device can permanently damage your battery by putting the kernel in an inifinite loop until the user catches it and reboots manually. (It disables the kernel's low-battery shutdown safeties, leaving only the battery's own protection circuit as the ONLY line of defense against permanent battery damage.)
His script is hundreds of kilobytes of echoes and printouts with all sorts of hype and marketing and very little substance. It's interesting that he uses the car analogy, because in the United States, gearheads have a term for the sort of stuff he does - that term is "ricer".
In my opinion, comprehensive tweak scripts should be avoided at all costs - pick and choose clearly documented tweaks, don't just trust someone to throw a bunch of crap together for you, because 90% of the time it is just that - crap.
Also, this does not belong in Development, it belongs in General.
Click to expand...
Click to collapse
Ohhh.. Thanks for the info. I was skeptical about it at first, but I just wanted to try it to see if it was really all the hype he brings on it. But now I know it shouldn't be used
Sent from my Galaxy Player 4.0 (YP-G1)
Entropy512 said:
V6 Supercrapper is awful... The author is constantly throwing random crap in with no clue what he's doing. For example, at one point he disabled the panic reboot timeout, which on a mobile device can permanently damage your battery by putting the kernel in an inifinite loop until the user catches it and reboots manually. (It disables the kernel's low-battery shutdown safeties, leaving only the battery's own protection circuit as the ONLY line of defense against permanent battery damage.)
His script is hundreds of kilobytes of echoes and printouts with all sorts of hype and marketing and very little substance. It's interesting that he uses the car analogy, because in the United States, gearheads have a term for the sort of stuff he does - that term is "ricer".
In my opinion, comprehensive tweak scripts should be avoided at all costs - pick and choose clearly documented tweaks, don't just trust someone to throw a bunch of crap together for you, because 90% of the time it is just that - crap.
Also, this does not belong in Development, it belongs in General.
Click to expand...
Click to collapse
Thanks for the feedback.
As you know, I accept suggestions and make changes if needed.
Nobody reported such an issue in the 840+ page thread but after gary brought it my attention the potential for it happening, I was more than willing to change it BEFORE he had a hissy fit.
I'm sure he combed through it and if he had only found that one, single parameter to be bad, then it's now perfect.
Feel free and check it out thoroughly yourself before throwing around general statements like you just did without ever installing it.
I'd be interested in knowing your opinion after you actually had first hand knowledge of it - which you don't as of yet.
But if you do, what else do you have an issue with? (apart from the echo's and printouts, of course, which actually inform the user of what's going on and what to do. Unless you think it better to have confused users and ugly output. So that's just a subjective opinion which means nothing - unless you're cramped for kilobytes. If that's the case, run the database vacuum script to optimize your .db files and get some kilobytes back )
If you want a real ram optimizer that works, try ram optimizer pro; I can get 200mb+ of free ram using this! Very handy for Gameloft games (I like the "balance, more free memory" and "hard multitasking" best, not "hard gaming" so much)
I agree with entropy512, btw. I installed the script, but didn't notice any improvement, so I uninstalled it, but it left strange files all over my /system/ directory.
Oh you mean the app that copied my now outdated (due to ICS) grouping limits and erroneously calls it non killable launcher?
Try latest version with calculated values based on your actual usable ram.
It kicks everything's ass with multitasking.
I won't dipute that one person out of about 200,000 downloads got a hot battery since that user's device is plagued by sods right off the bat and the most common fix is a replacement device LOL
Regardless I changed that single setting anyway so it doesn't even matter anymore.
Oh and all that free ram means nothing.
You only need enough so that it doesn't lag - roughly ~20% of your RAM on the high end devices.
Any more than that brings 0 benefit with apps getting killed often with minimal multitasking.
If you only want to do 1 thing at a time, all the time, an iApple would suit you better
Yes, I only need enough so that it doesn't lag, and I think you must not own any gameloft games like mc3 because it will easily eat 150mb of ram! Ram manager pro clears up that ram easily for me, your script does not, you lose. End of story. I will use whatever program that works for me, and NOT one that doesn't.
And what is the whole apple comment about? If I wanted to be a lame person with no imagination, why do you think I bought a galaxy player instead of an ipod touch in the first place?
you miss the point.
its easy to crank minfree values so that you have nothing else running.
a monkey can do that.
Besides, I'm sure you used an old version that didn't have the 768 or 1000 HP settings or else you wouldn't be so happy with a very pale imitation and bad implementation.
Edit: For example, fire up autokiller memory optimizer (or whichever minfree tweaker suits you - but not your preferred ram app since it has no customizing - surprise) and set the 6 values to:
10,16,150,250,300,350.
Oh look at all the free ram.
/me removes monkey suit
Well, I'm just following your script that recommends 512hp settings since my device only has 342mb. Actually I used your latest beta...
And if a monkey can do this, what the heck is with all the hype you put out about your script and how "no other program can do this"!
iJimaniac said:
Well, I'm just following your script that recommends 512hp settings since my device only has 342mb. Actually I used your latest beta...
And if a monkey can do this, what the heck is with all the hype you put out about your script and how "no other program can do this"!
Click to expand...
Click to collapse
Because the minfrees is actually a secondary feature.
Getting free ram is easy.
The OOM grouping fixes and priorities is #1 and is what sets it apart from anything else.
That was a tad difficult figure out and do - especially for ICS... that was a pain having to mod services.jar but it was worth it.
The other difficulty is finding a good level of free ram for any particular device depending on how much ram that device has.
A device with alot of ram can afford to have a higher percentage of it free (and still multitask) whereas a lower ram device would need a smaller percentage free... closer to 10% of total ram as opposed to 20% for higher end devices.
That's actually a rough idea of how the minfree calculation works.
NVM please delete this post.
zeppelinrox said:
Because the minfrees is actually a secondary feature.
Getting free ram is easy.
The OOM grouping fixes and priorities is #1 and is what sets it apart from anything else.
That was a tad difficult figure out and do - especially for ICS... that was a pain having to mod services.jar but it was worth it.
The other difficulty is finding a good level of free ram for any particular device depending on how much ram that device has.
A device with alot of ram can afford to have a higher percentage of it free (and still multitask) whereas a lower ram device would need a smaller percentage free... closer to 10% of total ram as opposed to 20% for higher end devices.
That's actually a rough idea of how the minfree calculation works.
Click to expand...
Click to collapse
But do you know why the script isn't working on my player? I just want to try it out and see the results for myself, but I just can't seem to get it to work.
Sent from my Galaxy Player 4.0 (YP-G1)
Oh... hehe...
Well start with installing wraithdu's busybox from my OP.
Run the script and if it don't work, post the actual errors or screenshot.
zeppelinrox said:
Oh... hehe...
Well start with installing wraithdu's busybox from my OP.
Run the script and if it don't work, post the actual errors or screenshot.
Click to expand...
Click to collapse
I did that, and here are my results:
Hope you could help me.
Sent from my Galaxy Player 4.0 (YP-G1)
For some reason, the system is lookin for:
/system/xbin/busybo
It's missing an x at the end.
I guess a cheesy fix would be to make a copy of busybox, rename it to busybo, and put it in system/xbin.
Don't ask me why the hell it's lookin for that tho
zeppelinrox said:
For some reason, the system is lookin for:
/system/xbin/busybo
It's missing an x at the end.
I guess a cheesy fix would be to make a copy of busybox, rename it to busybo, and put it in system/xbin.
Don't ask me why the hell it's lookin for that tho
Click to expand...
Click to collapse
Lol I get this when I rename busybox to busybo
Edit: when I keep both busybox and busybo in xbin, I get the second picture.
Sent from my Galaxy Player 4.0 (YP-G1)
klin1344 said:
Lol I get this when I rename busybox to busybo
Edit: when I keep both busybox and busybo in xbin, I get the second picture. (10:17pm)
Sent from my Galaxy Player 4.0 (YP-G1)
Click to expand...
Click to collapse
Sent from my Galaxy Player 4.0 (YP-G1)
Ok.. delete the busybo copy
type in terminal...
Code:
which busybox
This is what I get:
$ export PATH=/data/local/bin:$PATH
$ su
# which busybox
B: error 22
which: X/system/xbin/busybo: not found
#
Sent from my Galaxy Player 4.0 (YP-G1)
I found this today on reddit, thought I'd share it with everyone. All credit goes to Lambgx02
I'm running this on CM10 and I've noticed a difference.
Link to OP & Download
Hey everyone,
So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.
After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).
Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.
Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? I have never used an Android device this fast.
It is literally five times faster in many cases. Chrome, maps, and other heavy applications load in about 1/2 a second, and map tiles populate as fast as I can scroll. Task switching is instantaneous. You know how sometimes when you hit the home button, it takes 5-10 seconds for the home screen to repopulate? Yeah. Blocking on read of /dev/random. Problem solved. But don't take my word for it .. give it a shot!
Update!
I've built a very simple Android app that bundles the binary, and starts/stops the service (on boot if selected). I'll be adding more instrumentation, but for now, give it a shot! This APK does not modify /system in any way, so should be perfectly safe.
This is my first userspace Android app, so bear with me!
Note that this APK is actually compatible with all Android versions, and all (armel) devices. It's not at all specific to the Captivate Glide.
Caveats
There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge).
This may adversely affect battery life, since it wakes every second. It does not hold a wakelock, so it shouldn't have a big impact, but let me know if you think it's causing problems. I can add a blocking read to the code so that it only executes while the screen is on. On the other hand, many of us attribute lag to lacking CPU power. Since this hack eliminates almost all lag, there is less of a need to overclock, potentially reducing battery consumption.
If you try it, let me know how it goes.
ROM builders - feel free to integrate this into your ROMs (either the .apk / application, or just the rngd binary called from init.d)!
If anyone's interested, I've launched a paid app on the Play store for non-xda users. As I add features I'll post the new versions here as a thanks to you guys (and xda community at large for being such a great resource). But if anyone's interested in the market's auto-update feature, just thought I'd mention it
Click to expand...
Click to collapse
Thank you OP. ...
I'm going to get the playstore version for support purposes ...regardless of the xda report.
The developer worked hard on this. ...g
Tried it out, noticed an immediate, significant improvement!! If that was a placebo, the OP must have played it up to be a damn good one
I might be crazy (and I'm sure it's just a coincidence) but I seemed to notice an actual IMPROVEMENT in battery life after installing this.
Thanks for sharing!
I'm not sure if I've noticed any major improvement myself, but it has been a little zippier. I keep a very close eye on my battery, so I should be able to report any battery improvements. Hopefully I didn't waste a 1.50 on this app
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
CPA Poke said:
Tried it out, noticed an immediate, significant improvement!! If that was a placebo, the OP must have played it up to be a damn good one
I might be crazy (and I'm sure it's just a coincidence) but I seemed to notice an actual IMPROVEMENT in battery life after installing this.
Click to expand...
Click to collapse
If you're using the apk method, it's literally impossible to have better battery life as mentioned by the guy who made it. It keeps your device awake a lot more often to refill the entropy. The difference may be small enough that it won't affect you but it can't actually increase your battery life.
I've been trying the apk method as well as the other ones without really seeing any concrete difference. Currently running the sysctl method since it's "free" and doesn't use any system resources.
http://www.xda-developers.com/android/entropy-seed-generator-not-all-its-hacked-up-to-be/ just a heads up
ChronoReverse said:
If you're using the apk method, it's literally impossible to have better battery life as mentioned by the guy who made it. It keeps your device awake a lot more often to refill the entropy. The difference may be small enough that it won't affect you but it can't actually increase your battery life.
I've been trying the apk method as well as the other ones without really seeing any concrete difference. Currently running the sysctl method since it's "free" and doesn't use any system resources.
Click to expand...
Click to collapse
Haha yeah, that's why I said it was probably a coincidence Said battery "improvement" has since gone away, but my device still seems to be much snappier.
Been on it since its release and it has improved my phone. I will say, don't subscribe to the main thread though, omg notification every 2 secs....its crazy....well it has slowed down slightly but wow
Well. ..
Based on the report by arcee, whom I trust as being a top tier development expert, Im going to shut down the application.
His report is accurate in disecting the hack.
The resources used to run the hack, obviously outweigh the benefits.
It's a near placebo effect modification with no tangible performance advantage beyond what the CPU can already produce with governors and clocking tweaks.
None the less, I do believe the developer to be honest in his attempt in bringing us a well executed application with sincere intentions.
That being said, a thank you is still in order, and a small price of $1.50 is certainly not to high a price considering the work and coding involved. ...g
NO. This does NOTHING. Stop it, people.
Its been a night and day difference on my phone.
Sent from my SAMSUNG-SGH-I717 using xda premium
Another tweak is always great. Thanks for the contribution.
Sent from my SAMSUNG-SGH-I717
Tasty placebo... Seriously, people are still doing this? I thought all the threads were closed as nonsense.
Agreed ..please close this thread...
The mod does nothing...and has been confirmed by XDA ..g
Edit: reported ....people, don't waste your money.
As stated on XDA: http://www.xda-developers.com/android/entropy-seed-generator-not-all-its-hacked-up-to-be/
As is always the case, anything you use here on XDA is done at your own risk, and you assume all liability for your actions. That said, there are times we pass on inaccurate information, and this is one of those times. We do applaud all of our developers for working to find fixes for the things that nag at them. However, we jumped the gun on this, without letting adequate discussion and testing take place.
Click to expand...
Click to collapse