yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] sevenvt:
2211 quadrant

had some noobish trouble dropping from 1.18 bb to 1.17, but simple rm /system/bin/busybox and sideload the 1.17 apk, tada... great performance, just snappy all the time now. Will continue to follow the ext2 discussion, but as was said either here or over in modaco, this phone will last me a year, and i keep nothing that important to me on my phone... its a toy effectively, happy with it at the moment, and thats pretty much what counts when I consider this will probably only be my speed fix until the ota 2.2 push comes out in sept (or whenever it actually hits)
[Captivate Android Development] sevenvt:
From the looks of it quadrant is over scoring us by leaps and bounds.

edit1: benchmark (app) shows write at 166 m/sec and read 322 m/sec... interesting.

edit2: j bench puts write at 4 mb/s for both (approx)

seems like quadrant and benchmark are doing something strange.

edit3: there are multiple benchmarks out there that put us in the 200 write and 300-500 mb/s read. Then others that put us at 4mb...
[Captivate Android Development] caelestis2:
Hey this fix is fast and everything, but is it safe to mount my internal storage?

Is this procedure safe:

Plug into computer.

Swipe down notification bar and mount to fs to computer.

Do not launch any apps during this process.
[Captivate Android Development] caelestis2:
To end the debate about internal storage health and ext2 reliability, this is from the one click thread:
[Captivate Android Development] ranova:
*sigh*

That's what I was afraid of. Most people don't even bother trying out the NAND hack due to its severe limitations of 130mb of app space and quickly glance over the fact that it may be the fastest fix available (even though quadrant scores are almost stock 850s).
[Captivate Android Development] max_warheads:
I was ising the nand fix for my phone and am still using it for my gfs captivate. In our use side by side we can both see the boost this provides for our usage pattern.

To each their own eh? I wish we had a concrete way to replace rfs.
[Captivate Android Development] Kaik541:
I was never arguing against this point, and many people gave also brought up that most flash based chips also have garbage collection utilities too. My point was that both work equally as well in my day to day usage. I prefer this ext2 virtual filesystem to the ext3/4 as card trick because it will have less of an impact over a shorter time and I'm mostly pegging on the fact that someone will find a "true" fix to this or samsung resolves it in the froyo updates. We have the space internally to use as app storage, maybe they'll move away from rfs and go to yaffs and leave us with 512 mb to 1 gb internal for apps on a native filesystem (unlikely, but doesn't mean i can't hope)

Sent from my SGH-i897
[Captivate Android Development] dougp.me:
I'm with dontshakepandas here - while I loved seeing an increase in Quadrant scores, I was still experiencing severe "lock ups" when installing apps from the market. I couldn't browse while it was installing an app - just seems odd that something like this wouldn't fix it.
[Captivate Android Development] TimF:
I've been using the NAND fix for about two weeks now and it is working great. I'm sitting at about 50mb of app data so I doubt that I will run into the 130mb restriction before a better solution comes up.

I was hopeful about this solution but after reading through the pages I've decided to pass. This solution might be a good option when/if i start to encroach on the 130mb limit of the NAND fix but I am not there yet.

It would be nice to see this kernel and OS ported to a different file system that is designed to run on flash memory.
[Captivate Android Development] mykenyc:
I'm sorry but in my humble opinion its irrelevant for people to care about your phone exploding because of this, for 1 this is only a temporary fix until sammy does their job. We talking only a few weeks this will be on your phone i doubt really seriously you will damage your phone that quick for those worried. Also i have had my current SD card for almost 3 years now, i have been using apps2sd and all sorts of crap to it yet its still functional. I understand a phone is a investment but some people worry where you really don't although i do agree you should still take full responsibility if something due happens but thats with anything.

To me this hack works period i have been using it since yesterday, before when i use to move a icon from the drawer to the desktop it would make a 3-4 sec pause after i try to set it, now its instant.
[Captivate Android Development] iamamp3pimp:
I ran this, got my 2259 quadrant score and it is a bit faster loading and rendering things like *Maps

it does have a wake up pause though, as well as the screen being erratic for about 3 minutes on boot up.

so far im cool with it though..........now im toying aroung trying to fix the GPS but it isnt looking good on my end.

it was good out of the box for a few days until i started messing with things...
[Captivate Android Development] tbae2:
No such issues for me, I would look into what all you have installed and see if there is something running taking up large amounts of cpu.
[Captivate Android Development] iamamp3pimp:
I cant even get into the menu, when i was testing it out using swipe slowly going from one side of the screen to the other, the line goes up and down like an erratic heartbeat.
[Captivate Android Development] tbae2:
That is very odd, my phone is smooth as silk. Did you have a previous speed fix installed before? If you go to settings -> SD Card and phone storage, how much space does it say you have on internal phone storage at the bottom?
[Captivate Android Development] rajendra82:
In the Vibrant Development forum on the discussion of this thread, they have come up with an updated version of the fix that works with a custom kernel (by JAC) that supports init.d, and adds an error checking script on startup to overcome ext2 corruption. This appears to be the best compromise between using speed and reliability at this time. Is the kernel development on the Captivate too far behind for us to get a kernel with hacked in init,d support so that we can update the fix as well? Have any of the kernel chefs heard from Samsung about what causes us to have wake up lag?
[Captivate Android Development] max_warheads:
Error checking can be done by adding the e2fsck right before mounting the loopback in the userinit.sh script. I've got it running on mine and checking the behavior over the next days since I put it in place last night.

busybox e2fsck -p /dev/loop0
[Captivate Android Development] fua:
how to do that?
[Captivate Android Development] joeybear23:
bricked the phone twice trying this...
[Captivate Android Development] max_warheads:
It's in the NAND fix's thread.
[Captivate Android Development] max_warheads:
Did you verify requirements?

Did you watch the output for errors?

Did you revert any previous lag fixes prior to attempting?
[Captivate Android Development] ace518:
OK, so i've read a ton of debate on here about whether its good for your phone or not to do this or any variant. And while I understand that I may be risking having my phone die prematurely I still did not see anybody answer the question of if you COULD use an ext3 partition with this hack. I know the captivate stock kernal supports ext3 partitions. I also saw that somebody tried and the makefs command for ext3 seemed to not work.

What would it take to get around this? A new version of busybox with this implemented, or simply changing this script to do the makefs differently? I am still a bit new to all of this stuff, but am trying to learn as quick as I can.

Again, I understand this could cause damage to my phone, but so can overclocking my CPU at home, but that has never stopped me before. I think we should all be aware of risks, but if we still want to take them, that should be our choice.
[Captivate Android Development] Zilch25:
I would assume a new version of busybox with the EXT3 version of makefs could do this.
[Captivate Android Development] Zilch25:
Are you sure that's working? I didn't think e2fsck was functioning under the current build of busybox

Confirmed on mine: Getting applet not found. The line should be right, but the applet doesn't function under busybox, unless you've figured something out that I haven't.
[Captivate Android Development] iamamp3pimp:
no previous speed fixes installed.

632 MB of internal phone storage left.

I noticed that my phone got a bit warmer than average while charging as well, but ill have to do it inside using the AC charger as i was using the USB from my mobile laptop to charge, and it may be hotter outside.
[Captivate Android Development] joeybear23:
I used the zipped 1 step fix so that the pre-req's were all part of update.zip.

The script output a lot of warnings, but at the end it said it was complete, but both times I tried the phone would not come back after a reboot.

So I the Odin3 restore.

Haven't attempted any other lag fix.

It's not a big deal, I'll just wait until all the bugs are worked out and try later... or wait for Samsung's own fix or Froyo.. or both... or Christmas. Not in a huge hurry. This thing is still much faster than anythhing else I have used.

My stock quadrant scores have been from 890 - 928, and I don't notice anny significant lag, but I thought if I could make it even faster, hey why not.
[Captivate Android Development] max_warheads:
fark.

FWI/Appbrain just installed an update to 1.18.0.git... e2fsck is now dead.
[Captivate Android Development] Zilch25:
For what it's worth, I'm running 1.17.1 still and e2fsck doesn't seem to exist there either... seems like RyanZA is struggling with the same issue in the original thread too.
[Captivate Android Development] max_warheads:
I've not seen the 1-step zip in an update.zip format, so I can't speak to that...
[Captivate Android Development] Zilch25:
Seconding this, if you're using the instructions in the OP and renaming that file to update.zip there's no question why you landed in brick-city.

Actually I just saw that in the original thread there's an update.zip method- I wouldn't use this, as it was designed for the i9000 and there may be some chicanery in there that wreaks havoc on the Captivate.
[Captivate Android Development] ace518:
Thank you for the quick reply... Perhaps one of us could ask the author of it to add that functionality for us
[Captivate Android Development] joeybear23:
I haven't tried your write-up in post 116.

So maybe I'll give that a go...
[Captivate Android Development] Zilch25:
There's actually some talk of this in the original i9000 thread, hopefully they have some luck getting it done. I know they've said that "testing" shows EXT3 to be slower, but it would be nice to give people the option.
[Captivate Android Development] joeybear23:
Question:

Do you use a particular terminal emulator, or will any of them work?
[Captivate Android Development] joeybear23:
Trying Max Warhead's method now... but waiting on a little clarification on the terminal emulator.
[Captivate Android Development] Zilch25:
Keep in mind I haven't used the terminal emulator method before, but as far as I know there should be no reason why any of them wouldn't work. The terminal emulators just work as a conduit for you to execute linux commands, and as long as you can get root with it any of them should work.
[Captivate Android Development] max_warheads:
Any of them should work, but best experience seems to have been Android Terminal Emulator (you can find the link in the Enable Non-Market Apps thread)
[Captivate Android Development] tranms:
I performed the lag fix locally on the phone. I originally just searched for terminal emulator and installed that. That didn't load on my phone so I searched for android terminal emulator in the market and that worked.

The fix definitely improves performance in several apps and on the phone, but for now I uninstalled the fix until there is a method that won't mess up my internal memory.
[Captivate Android Development] joeybear23:
Okay, I used "Android terminal Emulator" and it seems to have worked...

First two quadrant results were 2164 and 2132.

...and the phone seems more peppy when playing around with it.

Thanks, max and zilch!
[Captivate Android Development] caelestis2:
Hey I don't like to annoy, but this question is kind of important.
[Captivate Android Development] Zilch25:
Everyone will give you a different answer to this... and there were like 3 pages of people arguing this topic earlier in the thread.

What it boils down to is: There is no definitive answer- there's people on both sides of the fence with very good points both defending and decrying this fix.

This fix will stress your internal NAND- whether or not it stress it more than everyday use with stock? The jury is still out on that. Once the wake lag gets fixed for the kernel based approaches we should see some methods that everyone will deem safe.
[Captivate Android Development] max_warheads:
Yes. It's PERFECTLY safe to mount the sdcards after this!

This fix makes use of the 2GB system /data partition, not the 14GB /sdcard partition that is mountable to a computer.

Note: You'll notice when you re-read I stated it's perfectly safe in specific regard to mounting the /sdcard portion.
[Captivate Android Development] caelestis2:
Oh thanks!
[Captivate Android Development] Zilch25:
Honestly the only real arguments right now are:

Will EXT2 stress the internal memory by reading and writing a whole lot more than the default FS?

The creator of this fix claims that this fix should actually read/write LESS than the default FS.

EXT2 is a non journaled file system and can be prone to corruption during shutdown, and allegedly during everyday use. While there isn't evidence at the moment that this is occurring in the wild it is a possibility that you need to be aware of before relying on this fix. Backups are a GOOD IDEA.

However according to the original thread they've requested the busybox maker include the fcsk util needed to check the integrity of the EXT2 file on startup which should eliminate the corruption issue, they've also requested that he add in the makefs for EXT3 which should placate those hungry for journaling.
[Captivate Android Development] caelestis2:
Well what does ext2 have to do with the amount of times the phone writes to the sd compared to the original flash memory? All the phone has is flash memory and I'm sure it will be fine.
[Captivate Android Development] Zilch25:
I wish I was more of a file system officianado so I could answer this question better, but apparently by default EXT2 can be vicious with writing to the drive repeatedly, and with flash memory at least the old school variety, data could be written and rewritten to the same block over and over again which would eventually result in a bad block on the memory chip (Newer flash media is generally smarter about this and manages itself rather than doing what the file system tells it), and that over time would kill your flash media. Apparently they've added some variable to the way this fix implements EXT2 to reduce the amount of write cycles to abuse the memory less.
[Captivate Android Development] max_warheads:
Here's the basic gist:

This fix uses Ext2 with the 'atime' or access time markers disabled, it's just a timestamp of the last time the file was accessed. Those buggers add up, then by placing this into a file inside of the stock RFS from Sammy (gee, thanks Sammy...), RFS intern reads the contents of /data/data as one file, not umpteen+/-100. This little tid-bits add up. The second effect is that we're using a portion of the ram to buffer between actual writes, reducing the total number that need to occur.

less writing = lower wear, and less waiting on writes to complete.
[Captivate Android Development] Zilch25:
Thanks, that makes a lot more sense than my babbling attempt to answer the question. Clears it up a bit for me too :)
[Captivate Android Development] Clienterror:
So worst case is this "might" mess up your file system making you load a backup. Cause some posts seem like your main board will melt and catch on fire and the world will explode. People keep saying this might permanently mess up your phone, or are they meaning "permanently" untill you load a backup lol.
[Captivate Android Development] allted:
Wow

Wow, thanks for this. Big noticeable speed bump to an already fast phone. It makes such a noticeable difference I ran quadrant for the first time and to my surprise it spit out 2134!

Thanks again
[Captivate Android Development] TimF:
Noticeable speed jump as compared to what? Were you running stock or were you running another lag fix mod?
[Captivate Android Development] max_warheads:
OK, LETS CLEAR THE AIR A BIT

First off, yes, we see a massive Quadrant score boost with this fix. However, the cause of that is the insane speed of the I/O tests when running against a loopback device (thats what our virtual Ext2 filesystem is).

The important part of this fix is not just the I/O boost it gives to the Quadrant, but the real-world, non-complex result it gives us in application performance.

If you are doing this just for the Quadrant score, You're Doing It Wrong(tm)

This and the mimocan variant that uses ext3/ext4 on the external SD card are essentially the same aside from the specifics of implementation. Be aware of this. We've just managed to eek out some extra performance and not suffer the wake-lag.
[Captivate Android Development] douglastheduke:
Thank you much.

Fantastic fix!!

Stock ROM.

ATT bloatware removed

With this i/o fix

Quadrant: 2234
[Captivate Android Development] ranova:
I concur, Quadrant scores mean NOTHING.

From past comments and personal experience, I still think the NAND trick still gives the best REAL WORLD performance. Although, I haven't had time to test this method
[Captivate Android Development] caelestis2:
I agree, quadrant has sucky I/O tests, BUT THAT DOESN'T MEAN THIS FIX HAS SLOW REAL-WORLD RESULTS. I used the NAND fix and it isn't nearly as fast as this fix! Dolphin-HD, market, gallery, file browser, application uninstall menu, email, google voice works MUCH faster than stock and faster than any previous fix! Everything across the board is faster, but some of you guys are applying your previous stereotypes and saying that high quadrant = low performance. That's true for mimocan but not for this.

To poster above, do not assume something until you try it! This fix only takes 5 mins to do and much less effort, only thing you need to do is unapply the previous fix. I guarantee you market will load faster (the download section especially) than NAND fix
[Captivate Android Development] ptc62:
This is the first speed fix I've attempted... its easy and as far as I can tell it truly does speed things up. the first real example is the launching of the market... before, while attached to either wifi, or "h" (running i9000JM5) the market was sluggish to start, and when it finally did waiting for descriptions, icons to display fully would take 15 - 20 seconds if not more. Now I literally click on the market icon and BAM its there fully loaded and ready for me to search. Most applications seem snappier at launch and while navigating through them. I still want to put this thing through its paces (only had it installed for 24hrs.)

One caveat; occasionally I'll notice it stutters while just trying to fly through menus and downloading/installing new apps etc... (I started with fresh install last night) but haven't really seen it since I was re-installing 5/6 different apps at the same time.

While I am hesitant about data corruption... there is nothing on my phone that I would be worried about other than pictures, which I try to backup nightly. Contacts, email etc... is all backed up for me with gmail. As for life of the disk, I'm not to overly concerned about this either... I am not an expert, but to my knowledge SSDs suffer from this same "weak point" but many articles that I've read state that this is truly a non-issue. Especially since the devs for our forums have turned out several different releases/fixes for this issue, I'm sure we will see something brilliant from them in the weeks to come, making this an even further non-issue since it will be on my phone for maybe a month??

Either way kudos to the Devs!!
[Captivate Android Development] Zilch25:
From reading the original thread in the I9000 forums it looks like they've got some changes in the making that should hopefully make this a little more reliable as far as corruption goes, and a lot of fine tuning. So stay tuned.
[Captivate Android Development] ranova:
I specifically stated I have not tried this method yet and no one ever stereotyped that High quadrant scores mean = slow real time speed. We are just telling people not to base the quality of the fix to how high quadrant scores are.
[Captivate Android Development] max_warheads:
This stutter, at least when installing apps, is also due to the fact that while the data may be on the ext2 fix, the actually application, not so much :)
[Captivate Android Development] max_warheads:
I'm.. just going to blink at this, and assume you're not referring to my post? Because that just doesn't make sense.
[Captivate Android Development] flashman2002:
Reading the thread this guy you refer to was referencing someone who stated the Nand fix was the only real world fix he has had work for him. And that he hasnt tried this lag fix. I still think that when doing comparative tests between my phone with this lag fix and my wife's stock Captivate and seeing how slow her phone was to load the market, Dolphin browser HD that to me this is a worth while fix until ATT comes out with 2.2 and we can see what that does for the phone.
[Captivate Android Development] sdimezq8:
I can confirm the 'fix' is working on my stock ROM Captivate. Just follow the steps in the first post... Thanks to everyone, great workaround!
[Captivate Android Development] gotfolk:
I've been running this fix on my phone for a good 48 hours now. Absolutely love the speed increase!!

Today though ran into a couple of quarks and thought I would mention this before passing out for the night.

Earlier my phone stopped receiving text messages I could send but none came in till I did a reboot.

The tonight while out my phone got the circle with a line thru it where the phone bars are, I figured due to where I was I must of lost signal, kept checking it thru out the night and on the way home in an area where I know I get great signal it still had the circle with the line, this also took a reboot to correct and once rebooted it had full bars and 3g.

I am not sure if the SMS issue was due to me running apparently killer, so I shrugged it off as a possibility but when this no signal happened it did make me wonder.

Has anyone else come across these issues?

Just thought I would mention it incase other people have experienced this.
[Captivate Android Development] novaIS350:
definitely noticed a speed increase in daily usage. however, certain apps, including the XDA app and goggles, kept crashing with this fix applied. Until this fix method has been fully tested and/or improved, I would suggest not applying this to your device.
[Captivate Android Development] _Opiate_:
This fix does make the IO portion of the quadrant test FLY by. It also seems to smoke the NAND hack in real world performance. Its just maybe a tad unstable at the moment but great idea!
[Captivate Android Development] NukaCola:
This fix is a cool hack and i'm sure it is fast, but it is never going to be stable for reasons already explained in this thread.
[Captivate Android Development] iamamp3pimp:
i have been using it for a couple of days now, and while it is super fast, sometimes it will stutter through my contacts list and while browsing, moving the page around.

I dont like that so its time for a Odin 1 click restore, and launcherpro w root & sideloading.

no point in me trying to make an already great phone run faster.....
[Captivate Android Development] flashman2002:
Why would you need to run Odin 1 click when you can simply undo the lagfixme? Unless you feel it is necessary to work from a clean slate I clicked the unfix me and went back to how my phone was. Just curious.