[[Speed Improvements]] Brainstorming & Testing Thread!!

[auburnham]

Originally Posted by arrrghhh

For more aggressive settings, look at his beta versions. Grab the newest - and set it really aggressively! I have mine on the middle 512mb setting, and it seems to work very well.

Even better! I used the most aggressive 512mb setting and I'm starting with 80-90mb+ free! Outstanding!

[auburnham]

After a few days of use, I've been very pleased with the performance improvement. I've had no 'mini-resets', even with two major app update cycles, so the SD card setting must be good, or it could be a combination of that setting and increased memory.

The only issue I had was two instances of the device 'sleeping to death'. I was running an app in the foreground in both instances and let it sit long enough to turn the screen off. In one instance the device went to sleep (green LED) and would not wake up. In another instance, the screen turned off, but the LED was orange, and the screen would not turn back on. I gave the device over 5 minutes to respond in each case before pulling the battery. I will change my V6 SuperCharger Update 9 beta script setting to the mid-512 Mb level to see if that resolves the problem.

Another strange issue that I discovered is that when I switched from the 9/14/11 rootfs.img to the 10/19/11 rootfs.img my initial free memory dropped from ~81 Mb to ~43 Mb. I switched back and forth between rootfs files several times to confirm, and even re-ran the V6 SuperCharger script again with the new rootfs, but there was always a discrepancy. It was as if the V6 SuperCharger script wasn't effective with the new rootfs. I will stick with the old rootfs until we understand what's causing that.

Update: With the mid-512 Mb setting in V6 SuperCharger (and 9/14 rootfs), I'm starting with ~77 Mb free. Still very good!

[arrrghhh]

Originally Posted by auburnham

After a few days of use, I've been very pleased with the performance improvement. I've had no 'mini-resets', even with two major app update cycles, so the SD card setting must be good, or it could be a combination of that setting and increased memory.

The only issue I had was two instances of the device 'sleeping to death'. I was running an app in the foreground in both instances and let it sit long enough to turn the screen off. In one instance the device went to sleep (green LED) and would not wake up. In another instance, the screen turned off, but the LED was orange, and the screen would not turn back on. I gave the device over 5 minutes to respond in each case before pulling the battery. I will change my V6 SuperCharger Update 9 beta script setting to the mid-512 Mb level to see if that resolves the problem.

Another strange issue that I discovered is that when I switched from the 9/14/11 rootfs.img to the 10/19/11 rootfs.img my initial free memory dropped from ~81 Mb to ~43 Mb. I switched back and forth between rootfs files several times to confirm, and even re-ran the V6 SuperCharger script again with the new rootfs, but there was always a discrepancy. It was as if the V6 SuperCharger script wasn't effective with the new rootfs. I will stick with the old rootfs until we understand what's causing that.

Update: With the mid-512 Mb setting in V6 SuperCharger (and 9/14 rootfs), I'm starting with ~77 Mb free. Still very good!

Unless there's a tangible slowdown, I wouldn't worry about it. You should be on the newest rootfs (and kernel), because it sounds like your LED still indicates sleep/wake status. That's been "fixed" for a little while now .

[auburnham]

Originally Posted by arrrghhh

Unless there's a tangible slowdown, I wouldn't worry about it. You should be on the newest rootfs (and kernel), because it sounds like your LED still indicates sleep/wake status. That's been "fixed" for a little while now .

I did notice a slower response with the newest rootfs, so I don't think it is a false reading. I am on the newest kernel, I've just forced the old led_regime mode because I like it better.

[arrrghhh]

Originally Posted by auburnham

I did notice a slower response with the newest rootfs, so I don't think it is a false reading. I am on the newest kernel, I've just forced the old led_regime mode because I like it better.

Fair enough.

I'd be curious about your rootfs slowdowns - is there a particular rootfs where it starts occurring? You said you switched from 9/14 to 10/19, but there is no 9/14 rootfs. 9/2, 9/18, 20, & 30.... then 10/19.

[auburnham]

Originally Posted by arrrghhh

Fair enough.

I'd be curious about your rootfs slowdowns - is there a particular rootfs where it starts occurring? You said you switched from 9/14 to 10/19, but there is no 9/14 rootfs. 9/2, 9/18, 20, & 30.... then 10/19.

Those were the modified dates of the rootfs.img files, so I guess it doesn't correspond to the version for the older file. How do I determine the version of the rootfs.img file? I believe it was the rootfs.img that came in the FRX07.1_Full_Bundle_20110901.zip file.

[arrrghhh]

Originally Posted by auburnham

Those were the modified dates of the rootfs.img files, so I guess it doesn't correspond to the version for the older file. How do I determine the version of the rootfs.img file? I believe it was the rootfs.img that came in the FRX07.1_Full_Bundle_20110901.zip file.

If you already have a rootfs, there's no fool-proof way that I can think of off the top of my head. I'd just go to the rootfs autobuild and then you'll know for sure.

[auburnham]

Originally Posted by arrrghhh

If you already have a rootfs, there's no fool-proof way that I can think of off the top of my head. I'd just go to the rootfs autobuild and then you'll know for sure.

From the rootfs autobuild log and the date code of the FRX07.1 bundle, I would guess the older rootfs.img file was from 8/31. However, it could be the 9/2 version since there is a note about lowering the SD readahead buffer to 256kb, which mine was originally. The newer rootfs.img is definitely from 10/19.

Looking through the rootfs autobuild log between those dates, the only entry I see that may be related to memory is from 9/30/11: fixup /dev/block/ramzswap0 creation

[nodoze]

Arrrghhh,

I really like this thread... I am very tired so I may have missed it in this thread but there are a few things I didn't see that should help speed Android up... These basically center around starting with a better base... These are not Android tweaks per se but because they speed up android by giving it a better foundation I thought you may want to include them in your speed tread...

The first thing I want to try is losing less to begin with to Windows Mobile... From our thread on SprintUsers the recommendation is to start with a stripped down WM6.1 ROM. The current recommended ROM is Calkin's Stripped down ROM for Android:
http://www.sprintusers.com/forum/showthread.php?p=2640948#post2640948

Anyone disagree with this train of thought and/or have a better ROM recommendation?

The other recommendation I didn't see, also along the lines of starting with a better base, is getting a faster SD card and it may be the newer larger read optimized cards are maybe NOT better:

http://forum.ppcgeeks.com/android-tp2/147357-sd-cards-performance.html

　

Lastly, I am not a Windows Mobile guy and am confused on changing ROMs and HSPLs and such.

If anyone can throw me a bone and point me toward easy instructions to changing the ROM on my Sprint TP2 I would really appreciate it.

[arrrghhh]

Originally Posted by nodoze

Arrrghhh,

I really like this thread... I am very tired so I may have missed it in this thread but there are a few things I didn't see that should help speed Android up... These basically center around starting with a better base... These are not Android tweaks per se but because they speed up android by giving it a better foundation I thought you may want to include them in your speed tread...

The first thing I want to try is losing less to begin with to Windows Mobile... From our thread on SprintUsers the recommendation is to start with a stripped down WM6.1 ROM. The current recommended ROM is Calkin's Stripped down ROM for Android:
http://www.sprintusers.com/forum/showthread.php?p=2640948#post2640948

Anyone disagree with this train of thought and/or have a better ROM recommendation?

The other recommendation I didn't see, also along the lines of starting with a better base, is getting a faster SD card and it may be the newer larger read optimized cards are maybe NOT better:

http://forum.ppcgeeks.com/android-tp2/147357-sd-cards-performance.html

　

Lastly, I am not a Windows Mobile guy and am confused on changing ROMs and HSPLs and such.

If anyone can throw me a bone and point me toward easy instructions to changing the ROM on my Sprint TP2 I would really appreciate it.

Well unfortunately none of these would speed up Android.

1) Many have done tests with all sorts of different WinMo ROM's... and the conclusion is WinMo speed has absolutely, positively nothing to do with how fast Android runs. Gen.Y or a slim ROM will help you get to Android faster, but it won't make Android faster - hope that makes sense. Again, WinMo ROM does not effect the speed of Android.

I love how you suggest changing ROM's, but don't know how too. lol.

2) SD card speed also doesn't do anything for Android's speed. With that said, if you have a bad card with a ton of bad blocks etc then I'm sure the performance on the card would be slower. But unfortunately our phones can't really take advantage of Class 10 or even Class 6 cards speed - that's really for high-end cameras that need that much memory bandwidth to record 1080p. Again, people have done many extensive tests and the cards with the best random read/write performance (which SD cards are horrible at) were Sandisk cards. You really have to test each card's throughput on your phone to get an idea of how it'll effect Android.

As far as WinMo, you really shouldn't ask questions about it in the Android section. But it's really quite easy - flash HSPL (http://forum.ppcgeeks.com/cdma-tp2-d...w-hardspl.html) then flash a ROM.