yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] :
kudos to SuperCurio and all the developers. Hoping to get this for the public soon. Willing to pay for the US$10 for the complete fix.

By the way,For those who were able to run some test. How is the battery life? Does it drain fast? how is the battery life? I have tried some lag fixes before and after a while, i tried installing Auto killer/Min free manager and my battery drain quite faster than before. Hope with this fix, there will be no need to run task managers.

Cheers!:)
[Galaxy S I9000 Android Development] HaTeNL:
[ot]Task managers are bad for your battery and everything gets slower. So just don't use them![/ot]

Pretty impressive lagfix! I can't wait to use it.
[Galaxy S I9000 Android Development] distortedloop:
Autokiller and MinFreeMgr are not taskkillers, despite the poor name choice for the former.

Both of them just change the default values that Android's own memory manager uses to keep memory clean by flushing stuff from memory. You can argue whether or not that's a wise thing to do, but it's not the same thing as artificially forcing an app to close with something like Advanced Task Manager and its ilk.

At least that's my understanding.
[Galaxy S I9000 Android Development] SetiroN:
Awesome news.

I will gladly donate if the following conditions are met:

- support for any kernel, granted its ability to support the FS in use (meaning no Captivate/Vibrant/i9000m/custom kernel "racism")

- fully documented and open source for others to include it in their ROMs

- use of ext2 file system (ext4's journaling DOES kill microSDs, as they use the lowest quality NAND with the lowest write cycle rates and no wear leveling)

Thank you so much for working on it.
[Galaxy S I9000 Android Development] Aweb:
Don't worry, I had 70+ apps before I installed Voodoo, and it was lagging quite a lot even with RyanZA's lagfix (which still was much better than without lagfix at all). Vodoo transfered my apps to the ext4 partition and everything is now smooth :)
[Galaxy S I9000 Android Development] distortedloop:
Given the relatively short life span of our phones, do you really think that you're going to kill the nand before you move to the next phone? Just curious, not challenging.

I'm pretty sure supercurio's of the opinion that ext2 is not safe and prone to corruption, like many of us believe. Not sure I think that's a fair requirement to impose. Since the source and method will be open, should be easy enough to just change the format command to ext2 from ext4 he's shipping with.
[Galaxy S I9000 Android Development] funk0014:
Oke so I guess you wil not donate? Why is the ext4 partition used?
[Galaxy S I9000 Android Development] sunwee:
i hope supercurio will forgive me :) well i'm not an official beta tester, but by hook or by crook i managed to get hand on the files. i'm quite a heavy phone user, so i am very sensitive to the lag. i've tried all the lag-fixes so far, so i reckon i would have been a good beta tester, but too bad i saw supercurio's call for beta too late...

nevertheless, i'll try to provide my feedback (as unsolicited as some may think).

1) if you are not applying it on a fresh firmware, first boot will take ages (stuck in S) as apps are moved, fs applied, and apps moved back. truly ages. some ppl may panic and manually switch off and then on again. DONT DO IT, let the whole thing run to it's completion.

2) general usage is snappy. dont expect miracles though, it's not as if every app will fly open a microsecond after you click the icon. on general usage, it mostly will feel like the loopback fix and the sdcard/ext4 fix.

3) there are important differences though...and here's where voodoo shines. the other lagfixes (especially loopback fix) although they minimise general lagging, still exhibit occasional and weird lags. my theory is that after a big read/write request, although the ext2 virtual file complete the read/write it still needs to rely on the underlying RFS to carry out the actual read/write. and when the buffer overflows, RFS lags as it performs the read/write. thus the whole phone suddenly feels unresponsive for a couple of seconds.

this is most apparent when installing/uninstalling files. with voodoo, this lag seems eliminated, or at least greatly reduced. installing apps, whether from the Market or directly from apks performs as expected. once you click ok, apps are installed and the phone feels almost immediately responsive afterwards.

4) later samsung firmwares (eg those released in aug and later) also seemed to have helped in reducing lags. however there is still an underlying problem. the longer you use the phone (ie without reboot), seems like the lag increases.

Example, i'm running the I9000HVJH1, it's relatively good enough without needing any lagfix. i have installed widgetlocker (a lockscreen app). initially after a reboot, sliding to unlock is quick. but after several hours, sliding to unlock starts to stutter abit before bringing up the homescreen. However with voodoo fix, this problem seem to have been eliminated (i have been running voodoofix for over 6hrs now - no reboot and testing the phone pretty rigourously, opening, closing and switching app)

5) my initial conclusion: i would say this pretty much bring the general usage feel of the sgs very close to my experiences with the htc desire and n1 :)

second conclusion: the fix feels very complete. i think it's quite ready for public testing although documentations should be clearly laid out..FAQs, steps to uninstall, steps to take before and after upgrading to new firmwares, steps to take for upgrading to new voodoofix kernels etc etc.

overall, i must commend Supercurio. it's a Great job, dude!! :)
[Galaxy S I9000 Android Development] :
@Bounty: thanks for the clarification. I was actually mislead to believe it could "enhance" the response from my Sgs considering it was increasing my phones memory. :-)
[Galaxy S I9000 Android Development] Stefanauss:
Is this comparation referred to N1 and desire running Froyo or Eclair?
[Galaxy S I9000 Android Development] distortedloop:
You weren't mislead, it can, in theory. Many report it does, in practice.

edit: it doesn't increase your phone's memory (total), it increases the amount of free memory. Not quite the same thing.

I'm not convinced, because ultimately you're limiting the amount of memory the system can play with, if that makes sense. Instead of allowing the system to keep 10 things in memory ready and waiting for you to use, by setting more aggressive settings, you're telling the system it can only keep 8 thins in memory on standby, so to speak.

At the same time, you're leaving more open RAM available for new stuff to grab when it opens so that improves that aspect, but then the system will have to spend overhead killing other stuff to maintain that larger free available amount.

It probably just depends on how you use your phone. There's probably a different sweet spot for every individual.

And take all I say with a grain of salt, I am far from an expert in memory management, and might be totally off-base with my thoughts on this.

All I can say is I've used AutoKiller and honestly couldn't swear there's a difference in my daily use. I also have to sort of trust that the Google guys are smarter than I am in setting this parameter, but maybe the Samsung guys changed it and messed things up...
[Galaxy S I9000 Android Development] AlessandroIT:
I think he's referring to Eclair..

N1 running Froyo is way faster..imho
[Galaxy S I9000 Android Development] rajendra82:
I wish we could get Samsung to add this fix to stock, or to bring RFS up to ext4 speed.
[Galaxy S I9000 Android Development] vygi:
I will also donate $10 for a COMPLETE fix, nothing for partial.

EDIT: please contact me if you need a tester. I have a standard not locked/branded German I9000.
[Galaxy S I9000 Android Development] mikelyon:
Several pages with no news from Supercurio, perhaps still waiting for more feedbacks after several hours/days of use and preparing the final release or simply still sleeping after the hard work provided :p
[Galaxy S I9000 Android Development] RyanZA:
Autokiller just sets some preferences that are set by Samsung. There is no guarantee that Samsung's preferences are the best, or even that they didn't just pick them from a dart board. So changing this value to find a better one is a good idea. The 'empty app' in particular should probably be higher than stock. I like 'strict' setting myself.

Disagree. Do you have a Desire you have directly compared with? Co-worker has a desire, and my SGS is a lot smoother for scrolling lists/homescreens/etc. I'm using JG8 firmware though, which is probably the smoothest/most polished firmware. And firmware makes a big difference imo.

100% correct! :)

Not true, SGS has some of the best (perhaps the best) quality NAND available, judging by benchmarks.

Not true, and I wish people wouldn't keep spreading mis-information concerning linpack. Linpack is a floating point benchmark. N1 has a special floating point processor that helps a huge amount in this benchmark. It is not JIT.

Probably never going to happen. It's fine though - they've done their job in releasing the source so that people can do it for them - whole point of open source. :)
[Galaxy S I9000 Android Development] thomkat:
Part 20,- $

Full 40,- $

Thanks,

Greetings from Germany
[Galaxy S I9000 Android Development] lafaya:
Being the financial nerd that I am. I will be scrutinising Samsung's Financial Statements and seeing how much they must have spent on R&D.

RFS was probably an idea they came up with to unify all OSes they'll be working on (be it Android, WinMo7, BADA). It makes sense because it cuts down on cost if this is true.

If RFS was something thye will use solely on Android phones then it beats the hell out of my as to why they want to reinevnt the wheel when ext partitions are good enough! The open source community shouldn't have to fix, what I regard, a major bottleneck in a great phone. We should be hear tweaking minor things such as the battery indicator, etc (though nothing should prevent us from tweaking open source stuff also).

Economically, if the latter is true, then Samsung should employ the XDA devs lol
[Galaxy S I9000 Android Development] AlessandroIT:
@RyAnZa

I agree with you. The galaxy S is faster than Desire/Nexus in Scrolling, but

When i say "A nexus is a way faster than a SGS" i mean in every day tasks.

And yes, i have also a Nexus One running Froyo :)
[Galaxy S I9000 Android Development] rajendra82:
Samsung needs to fire most of their coding department, if a guy sitting in his basement for two weeks (no offense supercurio), can overcome what their army of Engineers couldn't in the months they had to develop RFS. Pass the cost savings on to us while they are at it.
[Galaxy S I9000 Android Development] Stefanauss:
I said that, the different architecture details about the processor, but i thought JIT was somehow involved. Really JIT does not make ANY difference on an Eclair vs Froyo Linpack Test on a N1?

Whenever someone post a Quadrant Advanced test, for instance, we always notice that the blue bar (CPU) is way higher on N1 with 2.2 comparing with the Desire (same processor).

Thanks if you can clarify.
[Galaxy S I9000 Android Development] michael0702:
I have now been testing the "voodoo fix" extensively all day, and im very impressed.

Its running real smooth, everything opens/closes much faster.

Apps etc. installs/uninstalls at speeds never seen before on sgs.

Lag don't seem to be building up like I felt it did on other fixes ive tried.
[Galaxy S I9000 Android Development] jsomby:
Is there any chance to get that fix ... "for testing"? :D
[Galaxy S I9000 Android Development] rajendra82:
Does Clockoworkmod Recovery backup/restore work with /data on ext4? Can someone with beta access chime in on this.

When supercurio does a Captivate kernel, or posts the source changes, so that somecan can modify unhelpful's overclock kernel to support the full lag fix, I will be pitching in some donation as well. There are some gotcha's in Captivate kernel (missing sound chip driver source file, wake up lag depending on tool chain) that I hope supercurio will get some help on before adding his awsome fix in.
[Galaxy S I9000 Android Development] :
It didn't when I tried it. This is not proof that it doesn't work though.
[Galaxy S I9000 Android Development] rajendra82:
Koush will probably have to patch in the support in that case.
[Galaxy S I9000 Android Development] dakine:
Just flashed to JM7 and applied this fix. It really seems like he did it, even when coming from another lagfix you will instantly notice the difference.
[Galaxy S I9000 Android Development] rajendra82:
Per this post:

http://xdaforums.com/showpost.php?p=7953340&postcount=120

http://github.com/voodoo-project/lagfix/downloads

Open Odin

Add the voodoo file into the PDA part

Don't tick re-partition

No need for a .pit file

Attach phone in Download Mode

Start Flash
[Galaxy S I9000 Android Development] BackfireNL:
Hello people! i updated the bounty thread!

Supercurio and RyanZA read your PM
[Galaxy S I9000 Android Development] RyanZA:
I believe Samsung paid Microsoft a very very hefty sum for rights to FAT32. FAT32 has a lot of problems (it's probably the worst filesystem ever made), so Samsung has tried to patch up the big data loss issues. No idea if they've succeeded. Either way, the core of FAT32/RFS does not work with a multithreaded operating system - when any operation takes place, the entire system freezes up until that operation completes.

What I'm trying to get at is there is no technical reason to use RFS - it must be some kind of political/legal/other type of deal. Or the linux engineers at Samsung are very confused. Seems a bit strange, considering how good their hardware is (hardware team probably only talks to the software team through long distance emails through a translator...).

JIT makes a difference. 1gz CPU will get around 7 in linpack. With JIT, it goes up to about 14. With dedicated floating point hardware, the sky is the limit. Dedicated floating point hardware is mostly useless in a phone though, and sucks a hefty amount of battery (large amount of additional circuity on the chip which must be powered whenever the cpu is active).
[Galaxy S I9000 Android Development] Stefanauss:
So my previous statements were right :)

The final answer for those who asked is: N1 get over 40+ on Linpack because of Snapdragon AND JIT.

BTW, JPC reportedly score 14~ with Linpack. Can we conclude that JIT is enabled and fully working (it wasn't in first fryos ROM)?

Is there any way to find out for sure?
[Galaxy S I9000 Android Development] RADLOUNI:
Humble Question

Hi Guys

I am not an experienced coder, but based on my experience with the SGS and the posts i read in the forum, i have concluded that SGS's problem is two-fold:

1- The ****ty RFS system which i think the people here are creating a fix for. Will this fix involve a virtual file system on top of RFS, or will it totally replace RFS?

2- severe lag experienced after RAM drops below 50 Mb after several hours of usage. I understood from experienced guys in this forum that for android this is not a problem as android is designed to handle memory optimumly. So my question is whether samsung's implementation of android is whats causing this lag due to RAM drops (maybe samsung's customization of android is not really compatible with the SGS hardware.......)

Thanks for your feedback
[Galaxy S I9000 Android Development] DocRambone:
Desire have linpack score at 7 with 2.1 and 40 with 2.2.

I would say its the JIT and not the desire cpu that make the difference. And take a look at the 2.2 release notes where Google states 2.2 will bring big performance boost.

Both N1 and Desire (with 2.2) is way faster in real use the SGS (with even oc or the leaked2.2 roms)

N1 had Linpack scores around 15 with the first JIT kernels so lets not loose hope the Samsung can bring some boost to SGS to.
[Galaxy S I9000 Android Development] alexandruvlad:
10$ anytime or even more for a complete super incredible fix :D

Perhaps Samsung will consider rewarding the maker of that fix :)

Donation sent :)
[Galaxy S I9000 Android Development] BackfireNL:
Just flashed supercurio's voodoo fix and waiting for my phone to boot... i'm getting excited!

EDIT: OMG phone boots so much faster now.. it loads al my widgets / launcher pro so much faster.. testing the rest and running a quadrant bench right now!

Ok quadrant score: 1736...

....
[Galaxy S I9000 Android Development] BackfireNL:
Ok supercurio... you have done it :)

Now make it easy.. is there a way to make a update.zip and flash this through redband_au?

Because this FIX FIXES ALLLLLLL LAG! i'm so happy!

Seriously all apps install instantly AND open instantly... wowwww

Can run 10 apps at the same time and still it will open apps instant

For all the people: Flashing does not make you lose any data...
[Galaxy S I9000 Android Development] nerve21:
Other fs on SGS

Hi,

I'm a new android user with a SGS for 1 month, but i've some linux experiences.

I've read this thread and i'm thinking on a new feature for this fix:

Could this fix change all RFS fs to ext4 ?

maybe the /dbdata and /cache fs coulld also impact speed of the SGS :confused:
[Galaxy S I9000 Android Development] etking:
Ever thought about using yaffs2 as filesystem, which is - in contrast to ext4 - optimized for flash memory?
[Galaxy S I9000 Android Development] jjwa:
Wow, the phone feels even quicker than it was stock, clean any with no apps on it. It now has 40 apps on it. I will report back later, after much use, running without reboot for a longer time, and I will probably have a lot more apps on it by then :).

And I too am waiting for a 'real' benchmark, but my Quadrant score is 1735 (used to be 800~900 something). Because I like numbers as much as any geek :).

I think as soon as this gets an easy fool proof install method (free from-market install for example), I will make my donation :).
[Galaxy S I9000 Android Development] glio1337:
It's been stated several times that this mod will use EXT4 and is already using it.

We could debate forever the dozens upon dozens of possible filesystems to use and which one is better but EXT4 is the best option for this concept and developer. Let's just leave it at that.
[Galaxy S I9000 Android Development] Stefanauss:
BTW, supercurio himself has already addressed that previously on this very thread, you can search for details =)
[Galaxy S I9000 Android Development] Bandis710:
:eek::eek::eek: Wow ! Just applied the voodoo fix .it is voodoo magic indeed .. My galaxy is greaced ligthning :D
[Galaxy S I9000 Android Development] dutchcow:
So what exactly does this lagfix do? I flashed it, and it just had a kernel inside by the looks of it. Does it convert the RFS into ext4? Some details would be nice. It seems all smooth though, will definitely donate once there are some docs available.
[Galaxy S I9000 Android Development] glio1337:
All of the details are in this thread already.
[Galaxy S I9000 Android Development] rajendra82:
Start at the bottom of page 6 of this thread, and read on. Why the heck did you flash it, if you didn't know what it does? :eek:
[Galaxy S I9000 Android Development] Wasmachinator:
just because i wanted to know it to i've found it.
[Galaxy S I9000 Android Development] Trollitito:
Which is the negative side of that fix? Or it doesn't have one? It doesn't spent more battery or use too much internal/flash memory/card and after a while they "die"?

I'm just asking because it seems too much good for be true and don't know if it was explained before, my english is a little bad. :P
[Galaxy S I9000 Android Development] rui.mamede:
They should be in the first page, not along the thread...
[Galaxy S I9000 Android Development] RyanZA:
Negative side for some is the custom kernel requirement. It's an insignificant negative though, considering the benefits. :)

Other than that, this just corrects a mistake that Samsung made. The phone should have always been as it behaves with this lagfix, but Samsung made a mistake.

EDIT: Also, could Tayutama be included in the links in the first post please? :D
[Galaxy S I9000 Android Development] rajendra82:
I can think of a few negatives so far. (I don't have the fix available for my Captivate, but I know how it works):

1. Needs a custom kernel, so you have to wait on a modified kernel based on a source code compatible with your ROM or have to revert to RFS, before you can update to a new firmware.

2. Does not seem to work yet in a Clockwork recovery session so no nandroid backups of /data unless you have reverted to RFS first. May require a patch from Koush to his program before it will do a full backup correctly.

3. EXT4 may be theoretically harder on the internal flash memory in terms of wear than RFS, but we don't know if this is of any practical significance. Both use journaling, and we have little to no concrete details about wear leveling implementation on our devices.

4. I am not sure how well EXT4 will continue to handle the shutdown procedure implemented by Samsung before something gets corrupted. This

should

not be an issue with EXT4 due to its ability to rebuild via the journal, but time will tell.
[Galaxy S I9000 Android Development] glio1337:
This thread is for the bounty, not for the specifics of an individual's solution for the bounty.
[Galaxy S I9000 Android Development] rui.mamede:
Yeah sure, its still the only place where we can know the news about this fix, so the important info should still be in the first page :rolleyes:

EDIT: also, forthose who are beta testing this fix, would be nice to know if we can flash new versions (when they show up) over this one without having problems
[Galaxy S I9000 Android Development] RyanZA:
I guess a benchmark in java with a tight loop is the best way to determine it.

This is really only a problem on certain firmwares. Some of the firmwares, such as JG8, do not seem to be affected by the ram issue, even after long periods of use. Tweaking the ram settings with ATK seem to take care of it for most 2.1 firmwares though.

Google only turned on the hardware fpu (I still don't fully understand how) in 2.2. In 2.1 it was disabled. You can actually turn off the fpu in N1 2.2, and the linpack benchmarks drop down to normal levels.
[Galaxy S I9000 Android Development] RyanZA:
There probably won't be new versions of this lag fix. It does one task, with no real need to change anything after it's been done.

If you mean new versions of android, then you first have to tell the kernel to remove the EXT4 partition, reboot for it to move your data back to RFS, and then only can you upgrade to a new android firmware.
[Galaxy S I9000 Android Development] Trollitito:
Hmm, so can we expect samsung will correct it in final version of froyo or just on gingerbread? Or none of both? Of course, after all this, i think samsung will "hear" it and try to improve their software, i guess.

Hmm, and can we revert to RFS in a easy way? Or it's complicated/impossible? With that uninstall_lagfix.txt it's reverted or just disabled while keeping EXT4?

After all i read about this, i really want to try it, but a lot of good things put me thinking if it's 100% safety. Of course, maybe we won't have problems, maybe we have, so... I guess i prefer don't know it. Anyway, i will keep reading and wait for more news, because would be great such a lagfix.
[Galaxy S I9000 Android Development] DocRambone:
Have a look at these scores, i think is pure JIT implementation that gives the big boost.

http://www.greenecomputing.com/apps/linpack/linpack-by-device/
[Galaxy S I9000 Android Development] :
Dont work with JPC!!
[Galaxy S I9000 Android Development] DocRambone:
JPC is froyo so it should not...
[Galaxy S I9000 Android Development] rajendra82:
Why would you expect a 2.1 kernel to work with a 2.2 ROM?
[Galaxy S I9000 Android Development] wuffa:
good stuff, this fix just feels right and was so easy.

RyanZa: 10, cause I used this a lot

curio: 35
[Galaxy S I9000 Android Development] odyssey61:
Its a beta fix actually had you read the posts clearly.

I have to say the feel of this is very good indeed. Market opens quickly, inside lock with GPS and thats all with Autokiller on default settings.