[Tweak] Performance "Tweaks" (Updated 4/26/2011)

[franciscofranco]

That "sleep" function is awesome. I just tested your way (making a init.d file with sleep 5; sh /system/etc/myfile.sh) and all the tweaks get applied including the nr_requests and stuff. I'm gonna do that for my next update, probably tomorrow. Thanks for the idea.

 

[mmarz]

That "sleep" function is awesome. I just tested your way (making a init.d file with sleep 5; sh /system/etc/myfile.sh) and all the tweaks get applied including the nr_requests and stuff. I'm gonna do that for my next update, probably tomorrow. Thanks for the idea.

sweet!

 

[anon(235100)]

@denshigomi- what do you think our best option is to get aosp ROM to use all of the tweaks here?
I'm running into the same thing. With franciscofranco's 99tweaks file I get the following:

# sh 99tweaks
sh 99tweaks
/sys/blockl/mtdblock1/queue/scheduler: No such file or directory
/sys/blockl/mmcblk0/queue/scheduler: No such file or directory
[: bfq: unknown operand
[: cfq: unknown operand
[: bfq: unknown operand
[: cfq: unknown operand
Error: no such collation sequence: UNICODE
Error: no such collation sequence: PHONEBOOK

I get more errors with with mmarz's. Bunches of afterboot.sh:
cannot create /sys/block/mtdblock0/queue/iosched/(insert many entries): directory nonexistent

sry. I'm just dangerous enough to apply tweaks :/

Oh duh! My scheduler is noop.
It looks like that's the only scheduler available on my kernel (using aospCMod CM7).
It makes sense that iosched options wouldn't be available for noop.

cat /sys/block/mtdblock0/queue/scheduler
[noop]

As for the collation sequence errors, they seem to be related to custom sqlite collations that were added in Android 2.2, but aren't available in the sqlite3 binary we're using.
So in your case, that's just preventing sqlite3 from running the vacuum command on your contacts database.
Issue 2251 - cyanogenmod - sqlite3 binary does not include custom collations needed for Android 2.2 DBs - CyanogenMod Android ROM - Google Project Hosting

edit- I guess ungaze & franciscofranco addressed the noop portion in the original 99tweaks script

 

[mmarz]

@denshigomi- what do you think our best option is to get aosp ROM to use all of the tweaks here?
I'm running into the same thing. With franciscofranco's 99tweaks file I get the following:

# sh 99tweaks
sh 99tweaks
/sys/blockl/mtdblock1/queue/scheduler: No such file or directory
/sys/blockl/mmcblk0/queue/scheduler: No such file or directory
[: bfq: unknown operand
[: cfq: unknown operand
[: bfq: unknown operand
[: cfq: unknown operand
Error: no such collation sequence: UNICODE
Error: no such collation sequence: PHONEBOOK

I get more errors with with mmarz's. Bunches of afterboot.sh:
cannot create /sys/block/mtdblock0/queue/iosched/(insert many entries): directory nonexistent

sry. I'm just dangerous enough to apply tweaks :/



edit- I guess ungaze & franciscofranco addressed the noop portion in the original 99tweaks script

I added franciscofranco's changes and fixed his mistakes. I just uploaded the new script. It should run fine now.

The sqlite3 issues won't go away until it is recompiled with the correct collation sequences included.

 

[anon(235100)]

thanks. that looks better
# sh afterboot.sh
sh afterboot.sh
noop
noop
Error: no such collation sequence: UNICODE
Error: no such collation sequence: PHONEBOOK

 

[denshigomi]

The two nr_requests lines should probably be run even for the noop scheduler.

echo $SCHEDULER_MTD
echo $SCHEDULER_MMC

for a in $MTD
do

if [ "$SCHEDULER_MTD" == "bfq" ] || [ "$SCHEDULER_MTD" == "cfq" ]; then

echo 1 > $a/queue/iosched/low_latency;
echo 16 > $a/queue/iosched/quantum;
echo 1 > $a/queue/iosched/back_seek_penalty;
echo 0 > $a/queue/iosched/slice_idle;

fi

echo 248 > $a/queue/nr_requests;

done

for a in $MMC
do

if [ "$SCHEDULER_MMC" == "bfq" ] || [ "$SCHEDULER_MMC" == "cfq" ]; then

echo 1 > $a/queue/iosched/low_latency;
echo 16 > $a/queue/iosched/quantum;
echo 1 > $a/queue/iosched/back_seek_penalty;
echo 0 > $a/queue/iosched/slice_idle;

fi

echo 248 > $a/queue/nr_requests;

done

 

[mmarz]

The two nr_requests lines should probably be run even for the noop scheduler.

Added! Thanks!

 

[JerryScript]

thanks. that looks better
# sh afterboot.sh
sh afterboot.sh
noop
noop
Error: no such collation sequence: UNICODE
Error: no such collation sequence: PHONEBOOK

I get the exact same errors, running aospCM7 latest build. Should I edit anything, or leave it. Things really run better with these tweaks, even with the errors.

I did modify the read_ahead value to 1024, testing showed it best for my slow card. I also removed the build prop section since aosp has that covered pretty well.

Thanks again for the tweaks, and help using them!

 

[mmarz]

The first two lines just echo which scheduler you use. I left that in there from when I was testing because it is handy to see if it is being parsed correctly.

The last two are because sqlite3 wasn't compiled with all the custom collation sequences. Those erros are just telling you that it couldn't open those two databases. No damage is done. Until it is recompiled with the correct components, it will give that error.

I'm glad you are customizing it to your needs. This is exactly the reason I didn't make this a flash-able zip.

 

[anon(235100)]

something is screwy for me after a rom update. Something is not letting me update build.prop and I'm thinking the rest of the script isn't applying either.
aosp 4/27
tried doing
mount -o remount,rw -t yaffs2 /system /system
setprop wifi.supplicant_scan_interval 300;

and look in my \system\build.prop and it's still set to 180

/system/ folder permissions are set to drwxr-xr-x
/system/build.prop file permissions are set to -rw-r--r--

anyone see anything funny?

[edit] after googling I think something is borked with busybox. I'm looking into it further. It's funny, Titanium Backup comes with Busybox 1.16.0 and after updating to 1.18.4 and restarting my phone the ROM started fresh as in all my settings and apps went away. Either the older version Titanium uses was corrupted when it installed or something went screwy when I updated the ROM.

still having probs. I don't know if busybox is necessary to run scripts but I guess I'm going to reinstall my ROM or at least do some wipes to see if it clears anything up

 

[mmarz]

It's not supposed to change your build.prop. Your build.prop is a file that is read only once during boot. After you are booted up, changes to build.prop only take effect on the next boot. If you want to see what values your system is using, type "getprop" into terminal emulator or adb shell.

If you want a single value, type "getprop setprop wifi.supplicant_scan_interval".

setprop changes the values loaded into your system. It does not change your build.prop file.

 

[anon(235100)]

thanks. I'm glad it wasn't as difficult as I thought it'd be.
I was thinking of making some sort of verification script to make sure settings get applied for testing tweaks

 

[mmarz]

thanks. I'm glad it wasn't as difficult as I thought it'd be.
I was thinking of making some sort of verification script to make sure settings get applied for testing tweaks

Here you go, this will test the value of windowsmgr.max_events_per_sec and assumes the tweaks were installed if it is 260. It does nothing else besides notifying you that the value is correct.

TestScript.rar

 

[JerryScript]

something is screwy for me after a rom update. Something is not letting me update build.prop and I'm thinking the rest of the script isn't applying either.
aosp 4/27
tried doing
mount -o remount,rw -t yaffs2 /system /system
setprop wifi.supplicant_scan_interval 300;

and look in my \system\build.prop and it's still set to 180

/system/ folder permissions are set to drwxr-xr-x
/system/build.prop file permissions are set to -rw-r--r--

anyone see anything funny?

[edit] after googling I think something is borked with busybox. I'm looking into it further. It's funny, Titanium Backup comes with Busybox 1.16.0 and after updating to 1.18.4 and restarting my phone the ROM started fresh as in all my settings and apps went away. Either the older version Titanium uses was corrupted when it installed or something went screwy when I updated the ROM.

still having probs. I don't know if busybox is necessary to run scripts but I guess I'm going to reinstall my ROM or at least do some wipes to see if it clears anything up

When you use the setprop function, it doesn't re-write the build.prop items, it just sets the property in the currently loaded system settings. Once you reboot, the build.prop takes back over till you call setprop again.

If you want the changes to be permanent, edit build.prop and then reboot.

 

[anon(235100)]

anyone got this running through Tasker? I'm trying to set it up through there but I don't think Tasker can run at root privileges when running scripts.

 

[mmarz]

anyone got this running through Tasker? I'm trying to set it up through there but I don't think Tasker can run at root privileges when running scripts.

You need to install this: android-scripting - Scripting Layer for Android brings scripting languages to Android. - Google Project Hosting

Tasker uses it to run the scripts. Than you add the "sush" file to your /system/bin/ directory and set the permissions: sl4a_scripts.zip

I included a sample script to show how it works. If you want to run "realscript.sh" as root, you create a script, lets call it "pointerscript.sh", and in the pointer script you write:

sush "sh /sdcard/sl4a/scripts/realscript.sh"

When you have tasker run pointerscript.sh, it will run realscript.sh as root. It's a hackish work around but it works.

 

[anon(235100)]

thanks for the tip. I've tried the sl4a app when testing and it was giving me the same issues. I guess I need to get the sush command going. It's strange because I can run the scripts from adb shell just fine which makes me curious why Tasker limits itself even though the rest of the device can use higher privileges.

For Tasker-
install sl4a
download this file and save it to c:\ (or somewhere)
go to adb shell and type
mount -o remount,rw -t yaffs2 /system /system
exit
adb put c:\sush /system/bin
chmod 6755 /system/bin/sush

create another pointer script named sush_afterbooth.sh in my example and drop it there too
with the command
sush "sh /sdcard/sl4a/scripts/afterboot.sh"

adb push c:\afterboot.sh /sdcard/sl4a/scripts/
adb push c:\sush_afterboot.sh /sdcard/sl4a/scripts/

test in adb shell
sh "/sdcard/sl4a/scripts/sush_afterboot.sh"

launch sush_afterboot.sh script in your Tasker task
test the task with something like
getprop wifi.supplicant_scan_interval

to see if tasker is working

 

[mmarz]

thanks for the tip. I've tried the sl4a app when testing and it was giving me the same issues. I guess I need to get the sush command going. It's strange because I can run the scripts from adb shell just fine which makes me curious why Tasker limits itself even though the rest of the device can use higher privileges.

I think is it a security issue. The way we are setting it up, any "virus" or malware could add a single line to our scripts (which wouldn't take root privileges), and then it would be able to run anything it wants. I is a far fetched idea consider how few users use such apps, but it is still a risk. I'm sure if this was a work phone, you'd be fired for doing this. I know I would be.

 

[anon(235100)]

The thing is I've already rooted my phone and the su command in /system/bin/ is at the same privilege level so I'm guessing I already breached the security in that regard. From what I've read the Tasker dev didn't design his app for root permissions out of the box so others have tweaks.

I think I've seen scarier things on the phone than this. While digging one day in an app data file I saw some random credentials I had entered saved in plain text.

You must work with the security geeks. I'd be more scared that they would know what you were doing with your phone and care that much

 

[mmarz]

The thing is I've already rooted my phone and the su command in /system/bin/ is at the same privilege level so I'm guessing I already breached the security in that regard. From what I've read the Tasker dev didn't design his app for root permissions out of the box so others have tweaks.

I think I've seen scarier things on the phone than this. While digging one day in an app data file I saw some random credentials I had entered saved in plain text.

You must work with the security geeks. I'd be more scared that they would know what you were doing with your phone and care that much

Yeah, lots of the apps keep your passwords unencrypted. That's the drawback to letting anyone write an app.

Luckily, the Optimus V is my personal phone. My work phone has obvious monitoring software on it. They don't joke around.