UPDATED : Real fix for the "stalling/lagging" problem

[Guest DistortedLoop]

Sorry I am a compete noob at bash and terminal commands in linux.

If I wanted to flash a different firmware and not have mimocan's fix how would I go about undoing the changes made. I assume I would have move the database of the sd card back to where it was supposed to be.

What are the necessary commands to perform this?

Dude, I posted undo instructions right here in this thread a while back....search the thread, it's here. Search tool box at bottom of messages, search term undo should find it for you. Four or five results down. :)

[Guest twisted_mind]

Sorry I am a compete noob at bash and terminal commands in linux.

If I wanted to flash a different firmware and not have mimocan's fix how would I go about undoing the changes made. I assume I would have move the database of the sd card back to where it was supposed to be.

What are the necessary commands to perform this?

This might be helpful to you :

1. adb shell

2. su

3. busybox rm /data/data – removes the link

4. busybox cp -rp /disk/data /data/ – copies app data back to the phone from the SD partition

5. busybox rm /data/data.bak – deletes the backup file

I found this info here :)

[Guest morfic]

Isn't there an app for that...? LOL

Seriously, this looks like the kind of stuff you can set with SetCPU or something similar. If there's not an app, perhaps easy to write it as a script for use with the ASE to make implementing routinely easier than a few terminal commands.

Also, you're specifically addressing people who haven't tried the move fix, but I'm sure most reading this thread have, so with that in mind, I think this should be in it's own thread as it's something new and a lot easier for noobs to do without screwing up their phones.

Finally, do you think this would have a positive impact on a phone in addition to the /data/data move type fixes? Seems like it should. I'm willing to give it a try on my lag-fixed phone, but not sure there's an objective way to test it at this point, my phone feels pretty snappy anyways.

Ok, tinkered with ASE (now sl4a?) used the self promotion suggested on sl4a issue 184 and can now change my schedulers from within sl4a scripts w/o "permission denied"

The impact on someone who changed to /disk/data on mmcblk1p2 already? it's possible it's still helping if mmcblk1pe is still not fast enough, just faster than mmcblk0p2.

Picking anticipatory or even deadline is contradictory anyway, i know it helped my ram starved mt3g with better throughput to shorten stalls (On my desktop i would rather tweak cfq (where i also would dump cfs for bfs, so the real fix is not making the bottle neck wider, but building a kernel that does not have the bottleneck causing the stalls in the first place))

And yes, setcpu is a nice gui to do change cpufreq stuff, but it costs (i paid, but am not using it right now), so providing a solution that works, io scheduler stuff is not addressed by setcpu.

So, now who would be so kind to send me a pull of /system/bin/id (rather than fixing the script's id -u check to call busybox's id, i removed /system/bin/id (i have /system/xbin/id which is a link to busybox --> busybox install -s /system/xbin installs symlinks to all its tools in the dir specified, all tools in /system/bin/ "hide" them, since they are first in path, but i got tired of typing busybox on shell all the time, mv i removed since busybox's is better and shouldn't cause me headaches)

On second thought, if any std scripting relies on this different id output it might fail:

morfic@othris ~ $ adb shell

$ su

# id -u

uid=0(root) gid=0(root)

# which id

/system/bin/id

# rm `which id`

# which id

/system/xbin/id

# id -u

0

i'd rather put the normal id back and call /system/xbin/id from script.

What runs and works inside SL4A: (with direct busybox id call for people who did not install busybox links)

#!/system/bin/sh

if [ "$(/system/xbin/busybox id -u)" == "0" ]; then


for f in mmcblk0 mmcblk1 stl3 stl9 stl10 stl11;

do echo anticipatory > /sys/block/$f/queue/scheduler;

done


else

  echo -e "Getting root priveleges\n"

  su<$0

fi[/codebox]

Thanks for making me get SL4A, this will come in handy in the long run.

What this kernel needs aside from /disk/data is a call to say /sdcard/local.rc so this stuff has a place to be called from once SL4A testing ensured the changes work.

[Guest DistortedLoop]

morfic, I started another thread for this so we don't dilute the discussion on mimo's fix.

As for SetCPU, it's actually available for free to xda forum members. Those who don't have it, just search the forums there and grab the apk. I paid for it anyways, I like to throw a few coins at any dev who makes good stuff for us. :)

There's another fix that seems to be screaming fast & emerging now. It's on xda well-discussed, but someone has mentioned it in the thread I started, and now someone has started a thread here for it.

I still like the potential of this one if it does some good and does require all these symlinks and other hacks to get the phone lag-free.

On a final note, mimocan hasn't posted here in MoDaCo since July 15th...I think he's moved on to xda, where he's been seen more recently (about a week or so ago), but I don't think he's paying any attention to this particular thread any more. :D

Ok, tinkered with ASE (now sl4a?) used the self promotion suggested on sl4a issue 184 and can now change my schedulers from within sl4a scripts w/o "permission denied"

The impact on someone who changed to /disk/data on mmcblk1p2 already? it's possible it's still helping if mmcblk1pe is still not fast enough, just faster than mmcblk0p2.

Picking anticipatory or even deadline is contradictory anyway, i know it helped my ram starved mt3g with better throughput to shorten stalls (On my desktop i would rather tweak cfq (where i also would dump cfs for bfs, so the real fix is not making the bottle neck wider, but building a kernel that does not have the bottleneck causing the stalls in the first place))

And yes, setcpu is a nice gui to do change cpufreq stuff, but it costs (i paid, but am not using it right now), so providing a solution that works, io scheduler stuff is not addressed by setcpu.

So, now who would be so kind to send me a pull of /system/bin/id (rather than fixing the script's id -u check to call busybox's id, i removed /system/bin/id (i have /system/xbin/id which is a link to busybox --> busybox install -s /system/xbin installs symlinks to all its tools in the dir specified, all tools in /system/bin/ "hide" them, since they are first in path, but i got tired of typing busybox on shell all the time, mv i removed since busybox's is better and shouldn't cause me headaches)

On second thought, if any std scripting relies on this different id output it might fail:

morfic@othris ~ $ adb shell

$ su

# id -u

uid=0(root) gid=0(root)

# which id

/system/bin/id

# rm `which id`

# which id

/system/xbin/id

# id -u

0

i'd rather put the normal id back and call /system/xbin/id from script.

What runs and works inside SL4A: (with direct busybox id call for people who did not install busybox links)

#!/system/bin/sh

if [ "$(/system/xbin/busybox id -u)" == "0" ]; then


for f in mmcblk0 mmcblk1 stl3 stl9 stl10 stl11;

do echo anticipatory > /sys/block/$f/queue/scheduler;

done


else

  echo -e "Getting root priveleges\n"

  su<$0

fi[/codebox]

Thanks for making me get SL4A, this will come in handy in the long run.

What this kernel needs aside from /disk/data is a call to say /sdcard/local.rc so this stuff has a place to be called from once SL4A testing ensured the changes work.

[Guest DistortedLoop]

So, now who would be so kind to send me a pull of /system/bin/id

Posted the file in the new thread: http://android.modaco.com/index.php?s=&amp...t&p=1370720

[Guest morfic]

Posted the file in the new thread: http://android.modaco.com/index.php?s=&amp...t&p=1370720

Sends me to news.

[Guest DistortedLoop]

Sends me to news.

Really? Link just worked for me.

Did you find the file? The link just sends you to the new thread I started for your particular hack.

[Guest morfic]

Really? Link just worked for me.

Did you find the file? The link just sends you to the new thread I started for your particular hack.

Never found the file. (won't need it, phone is fine with busybox's version)

Tried the loop mount fix meanwhile, while it helps quadrant scores, it stuttered more than it had been since

S witching schedulers.

the userinit.sh is going to be a nice place to put this stuff permanently.

[Guest DistortedLoop]

Never found the file. (won't need it, phone is fine with busybox's version)

Tried the loop mount fix meanwhile, while it helps quadrant scores, it stuttered more than it had been since

S witching schedulers.

the userinit.sh is going to be a nice place to put this stuff permanently.

That's really weird, the file is right there in the other thread you've responded in. Post #12 in that thread. Right above the one where you post the SL4 script.

Re: stuttering, I may have noticed a little once or twice already, actually. In the big thread on xda for this, they mention a French forum that supposedly tried the loop mount fix a while ago and decided it actually made things worse in the long run as far as stuttering goes, despite the Quadrant results.

It will be interesting to see, but we're really off topic for this thread if we talk about too many different fixes.

I have a feeling if that fix doesn't work out well, people will flock back to the mimocan fix in this thread pretty quickly.

[Guest tschmidt84]

hi! I just have a quick question: I saw the undo-method for mimocan's fix on your website (h t t p ://hemorrdroids.net/speed-up-your-galaxy-s/); do I have to undo the "market fix" part of it as well? and if yes, how? cheers, thomas