[Q] Data2ext - GT540 Optimus General

I hear about this Data2ext that is supposed to increase the IO of the phone. Is it possible to do on the GT540?

it very easil possable from what i understand, it would just involve mounting the ext partition to data. the kernel would need a bit of edditing but it should be less to change that data2system.

I think rc.conf must be edited for this operation, and on SD Card ext partition must be created.

So, if I wanted to tackle creating Data2ext for the GT540, where would be the best place to start getting the required information?
Granted, I'm no programmer. But I've done some hex and file editing, and understand how operating systems, partitions, and all that stuff work. I used to to do a lot of work with dos back in the day, and I'm sure this can't be much harder.
edit: After a quick bit of research, Data2ext just places the data folder on the SD card, with some other frills. But in order for this to be beneficial, the SD card would need to be faster than the internal memory. So my SD card is 12MB/s write and 18MB/s read, how fast is the internal memory?

No idea, but you would need to decompile the kernel and Reddit some of the files I think. I would suggest you use HTC kitchen. Works with are phone, and there's an option to decopile the kernel.

I came across something interesting. I use AnTuTu System Benchmark, My GT540 scores pretty high, but not the highest. The only difference between me and the people who score higher is the IO score. I get a little above 100, they get close to 200. Which means, there must already be a hack out there to improve the IO score. It would be easier to install a working hack than to create a new one.
So I'll spend a bit of time looking for the IO speed increase, before I start working on data2ext. If anyone knows what they used to increase IO speed, let me know.

Are you talking about the whole data partition or the data folder of apps?
Link2SD can move app data(lib files) with the newer version.

The whole data partition, or at least most of it (more than just the apps). But, the new swiftdroid M5 has improved IO peformance,. So, I will abandon this idea and just use the new version of swiftdroid.

Related

compcache: some clarification please

i've been reading up on compcache and the way that it works, but i'm pretty confused on how exactly this works on the android platform... i can't seem to pull the exact definition of compcache for android through all the chatter from threads, and it seems my answer gets lost in translation...
so to put it simply, i'm assuming from all my thread reading that compcache is actually based off the ext partition that you have on your SD card, and not on the RAM itself on the device? is this right? this is where i get confused, cause the compcache writers and developers say that it creates a ramzswap in the ram itself and stores compressed pages on the device RAM, effectively increasing the efficiency of your onboard RAM... in android's case and all the cooked ROMs, does it work off your SD card and your ext partition? or does it work off the RAM itself...
i'm currently running cyanogen's latest 32b release on my mytouch and its running extremely fast WITHOUT apps2sd, but i would like the benefits of compcache to prevent losing information from my browser and other applications like gtalk, which supposedly compcache helps with... would i have to create a ext partition and utilize apps2sd in order to utilize compcache? thanks in advance
bump... would like to be learned
I'm also a bit confused
i would like to know as well as i've installed Cyanogen v4.0.1
i went into the recovery console and formatted my SD choosing the option of "Format SD: fat32+ext2+swap"
was this the correct thing to do?
either way if you format cyanogen's rom with just a fat32, or fat32 + ext + swap, it doesn't matter as his rom is compatible with either apps2sd or without...
the question is, where does compache compress its file pages? in the RAM, or in the SD card
Compcache uses xMB of RAM as compressed swap space. No ext2 or swap files or swap partitions are needed (though the latter two can be used as "backing swap").
So on a 32B, with RAM limitations already, how is that a good thing?
PsychoI3oy said:
Compcache uses xMB of RAM as compressed swap space. No ext2 or swap files or swap partitions are needed (though the latter two can be used as "backing swap").
Click to expand...
Click to collapse
thanks thats the answer i was looking for...
MikLSP said:
So on a 32B, with RAM limitations already, how is that a good thing?
Click to expand...
Click to collapse
how is it NOT a good thing? compcache compresses page files, effectively increasing your RAM's efficiency and "technically" increasing its storage size in the allocated ramzswap... according to the developer's tests on different machines, it effectively makes it seem like it doubles the RAM amount on your computer...
this is nothing but good, especially for lower end machines like netbooks, and phones that have limited RAM allocation to begin with...
heres a small tidbit from the google source page
http://code.google.com/p/compcache/
i don't mean to threadjack, but compcache will be active regardless of whether or not i partition my sd card to fat32+ext2+swap...?
and i only have to partition my sd card to fat32+ext2+swap ONLY if i want apps2sd to work correctly using Cyanogenmod's rom...?
please correct me if i'm wrong.
i'm really wondering because even though i'm using Cyanogenmod's latest rom on my MyTouch, i still get considerable lag throughout such as typing on the virtual keyboard, screen orientation rotation, etc. i also use TasKiller.
maybe i'm expecting too much...
probably... lag from orientation, keyboard, and small things like this are still very common... i've tested a lot of roms on both the g1 and mytouch, and cyanogen's is by far the fastest...
As I have understood it sort of compresses things stored in the RAM (like background apps)
I've done a good amount of reading on compcache and have found that its been causing problems in my 4.0.1 build of cyanogen... the best thread i've found on the issue is:
http://forum.xda-developers.com/showthread.php?t=547752
hopefully users continue to share their findings, as the the thread mentioned is for the G1, and i'm sure optimal compcache settings will differ on the mytouch 3G... i will be doing some extensive testing on compcache only (due to me recently buying a 32gb micro card, and don't want to mess it up with linux swap) and will report my results... if anyone would like to join in, please post your findings as well...

Lag issues with the SGS

It is by now well known the SGS has a lag issue (apps slow to launch, email slow to access, etc) that can be fixed by changing filesystems for parts of the device, to make it blazingly smooth.
There are several fixes available, some based on SD card, some used through PC, some based on kernel flashing, some based on on-device apps, etc.
At the time of this writing it is hard to say which is better. I would personally advise you to take a quick look around at which fixes are available.
Most of them are listed/referenced from the FAQ thread here: http://forum.xda-developers.com/showthread.php?t=723596
--
This is a placeholder post, the first method was stickied before but this seemed unfair to the other methods and may not be the method most suited to your device usage and situation. At this time, all of the fixes have their specific quirks and needs. Hopefully soon we will see a "much better than all the rest" fix soon from one of the devs here, or Samsung might even fix it themselves
If someone cares to write down a comparison between all the available methods at this time, feel free to post it in a reply here!
Great idea Chainfire.
When a user first decided to use a modified/custom/different firmware on their Samsung Galaxy S, they usually go through these steps:
1. Flash with Odin/Kies
2. Flash update.zip for root
3. Flash other update.zip (GPS fix, battery mod, etc) as necessary
4. Do a lag fix.
It took me a few hours and reading through countless posts to see the pro's and con's for each lag fix.
I will try to go through them as succintly as possible, and if anyone needs more explanation you can either click the link or do a search.
Feel free to correct me, this is how I see the lagfix as when I applied and tested it
Before starting, here is the internal structure of non volatile memory (where data persist after reboots) in Samsung Galaxy S:
- 128MB of very fast NAND (some people incorrectly called this ROM)
- 16/8GB of internal SD with 2GB set aside for application installs (this is why you see your internal SD as either 13+ or 5+ remaining, the 2GB shows up as Internal Phone storage)
- your micro SD card (external SD)
The lag is due to the inefficiency of the file system used in the 2GB (/data) partition for applications, stalling a lot of the read/write operation. You can search this for further reading if you want to.
Lag fixes
- MoDaCo's lagfix: Better than stock on old F/Ws but about the same as JM1/2/5 and JP1/2/3
This lagfix uses the 128MB very fast NAND to store your applications instead.
Pro: very very fast applications opening/switching performance
Cons: You are limited to 128MB of apps including built in apps .
- Mimocan's lagfix: Significant improvements in performance which can also be benchmarked. Requires an external SDcard formatted partly in fat and partly ext3 or ext4.
This moves the /data files into the ext3/ext4 partition on an external microSD card
Pros: very fast, lots of storage space for apps
Cons: You will be unable to unmount your external SD card when the phone is on, and you need an external SD card for this to work
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
There are still stalls when installing apps, and when accessing android applications database
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: There are still stalls when installing apps, and when accessing android applications database
-Voodoo lag fix by supercurio: a new class of total lag fix
Instead of creating a file inside the rfs partition and mounting it as /data/data, the voodoo lag fix updates the kernel so that the the 2GB partition is using ext4 instead or rfs. This gives the best possible lag fix.
Pros: fast, smooth, across everything you do. The way galaxy s should have been in the first place. The best and most consistent lag fix with no remaining lag left that is caused by rfs.
Support with other kernel mods are starting to show: backlight mod, OC/UV kernel
Cons: Incompatible with clockworkmod recovery
I am now using voodoo lagfix beta 4 only
http://project-voodoo.org/
I hope this helps
So, I usually read a lot on the Android Dev side of the SGS since I am very keen on a fix that will eliminate the lagging issues on the phone. I was in Spain for a holiday at the end of August and have come home to find a new 'Project Voodoo' fix being touted around. What sort of method does this fix entail?
And does anyone out there in the developer community believe that there will be a fix that will reformat the entire 2gb data partition to YAFFS2/EXT4/NILFS2 etc, as opposed to mounting a virtual file system on top of RFS? Or is it possible that Samsung themselves could remedy this with the 2.2 update?
sionyboy said:
And does anyone out there in the developer community believe that there will be a fix that will reformat the entire 2gb data partition to YAFFS2/EXT4/NILFS2 etc, as opposed to mounting a virtual file system on top of RFS? Or is it possible that Samsung themselves could remedy this with the 2.2 update?
Click to expand...
Click to collapse
Voodoo does that - ie mount /data as ext4
een625 said:
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: unable to rollback changes
Click to expand...
Click to collapse
RyanZA - good, but slower than minocans when you have a lot of apps/use phone for a few days.
CFLagFix by Chainfire - you can rollback without any problems.
ashwinds said:
Voodoo does that - ie mount /data as ext4
Click to expand...
Click to collapse
So Voodoo actually reformats the space as EXT4, as opposed to mounting a virtual filesystem.... Interesting! I did read that Cyanogen were going to be using the Voodoo fix in their upcoming SGS firmware, will be keeping an eye on that for sure.
(Unless of course the official 2.2 remedies this.... though I'll keep an eye on Cyanogen anyway )
Do you have any information regarding development process of cyanogen for the SGS?
Any reason the voodoo fix is not mentioned? (Except for the fact we have to wait for beta2 to become available).
dagrim1 said:
Any reason the voodoo fix is not mentioned? (Except for the fact we have to wait for beta2 to become available).
Click to expand...
Click to collapse
Probably because if you don't already have it, it's not really available. V1 was a "private" beta, or semi-private anyways, and the dev has pulled it while he works on beta2.
distortedloop said:
Probably because if you don't already have it, it's not really available. V1 was a "private" beta, or semi-private anyways, and the dev has pulled it while he works on beta2.
Click to expand...
Click to collapse
Yeah, makes sense and clear
Is a great (and my favorite so far) alternative though... Should become available this week though.
Voodoo is definitely the most promising method IF they can get the kinks worked out. We'll see it when it gets there
@een625 makes a pretty good short comparison of all the methods, but leaves out Supercurio's method. This should be added to the second post:
-Supercurio's lagfix (aka Voodoo beta 1): Significant improvements in performance which can also be benchmarked. Requires a custom kernel.
This reformats the /data mount point as ext4. The conversion is automatic on first boot and no data is lost.
Pros: very fast, does not affect the amount of storage for apps, doesn't impact free space reporting, uses ext4 for data integrity which some argue is unnecessary, easy to install, easy to uninstall.
Cons: Semi-private beta release only, must be specifically uninstalled to upgrade some firmwares, uses ext4 which some argue is significantly slower than ext2, no longer easily available while beta2 is finalized
I personally use this one right now, it is the only one that I have never experienced lag with at some point, even after almost five days of continuous uptime and heavy use. All the others have issues from time to time, especially with the Market and installing apps. This one does not, in my experience.
Also, I think that there should be some mention that mimocan's method requires a custom kernel, and also that mimocan is pretty much the same as apps2sd on other Android phones (uses ext3/4 in a partition on the external card). Additionally, a con to mimocan is that the user must manually partition and format the external card, all of the other methods can be done without user intervention other than flashing a PDA or running a script/apk.
Finally, dkcldark had an update.zip method posted very briefly that reformats the /data to nilfs or ext4. Looked promising, but was pulled for some reason.
And last but not least, please, please, please, let's not let this thread devolve into the ext2 vs ext4 debate that so many of the individual lag-fixe threads turn into. Perhaps a thread dedicated to that should be started (and stickied)?
distortedloop said:
And last but not least, please, please, please, let's not let this thread devolve into the ext2 vs ext4 debate that so many of the individual lag-fixe threads turn into. Perhaps a thread dedicated to that should be started (and stickied)?
Click to expand...
Click to collapse
I'll keep the suggestion in mind
RAID lagfix?
Speed is one concern, potential damage to the flash card is another. I would prefer to replace my external card than the internal one.
Btw, is it technically impossible to implement more advanced solutions such as using a combination of NAND (for heavy apps / data) and sd (for other apps / "bulk" storage)?
Moreover, I think that it would be possible to have some kind a RAID 1 arrangement that would increase read speed and reliability (esp. if combined with EXT2). Just think 2GB on internal and 2GB on external card. (Most importantly having - probably - the first mobile phone with a raid configuration. RAID is easy to implement under Linux so I don't see why this is not examined.
Evans_Prophet said:
Speed is one concern, potential damage to the flash card is another. I would prefer to replace my external card than the internal one.
Btw, is it technically impossible to implement more advanced solutions such as using a combination of NAND (for heavy apps / data) and sd (for other apps / "bulk" storage)?
Moreover, I think that it would be possible to have some kind a RAID 1 arrangement that would increase read speed and reliability (esp. if combined with EXT2). Just think 2GB on internal and 2GB on external card. (Most importantly having - probably - the first mobile phone with a raid configuration. RAID is easy to implement under Linux so I don't see why this is not examined.
Click to expand...
Click to collapse
i think I might have even suggested something like this before, but it was either overlooked or its too hard to do. But the idea (i did not think about RAID) is awesome.
I agree Voodoo lagfix is great but there is one problem/phenomena: CON: Big battery drains and we don't know where it's coming from :S
Wouldn't RAID put a big strain on the CPU?
I've tried MoDaCo, Mimocan and RyanZA lagfixes.. for a very brief review, I've to say that MoDaCo seems the fastest to me.. Followed by RyanZa 1-click lagfix and lastly the Mimocan lagfix. A pity that MoDaCo is limited to ~130mb of /dbdata space
Btw, just my personal opinion.. Some may disagree and feels that other lagfixes are faster.
lafaya said:
I agree Voodoo lagfix is great but there is one problem/phenomena: CON: Big battery drains and we don't know where it's coming from :S
Click to expand...
Click to collapse
That seems to be a YMMV kind of thing. I don't notice big battery drains with it, but there are those who say they do. Not sure if I am lucky, or others are unlucky.
Certainly couldn't hurt to do the whole wipe batterystats routine and see what's up after that.
Chainfire said:
It is by now well known the SGS has a lag issue (apps slow to launch, email slow to access, etc) that can be fixed by changing filesystems for parts of the device, to make it blazingly smooth.
There are several fixes available, some based on SD card, some used through PC, some based on kernel flashing, some based on on-device apps, etc.
Click to expand...
Click to collapse
Thanks for doing this. I had been pushing for the change for the last couple of weeks since RyanZA and Tayutama particularly bought out their fixes. We now have a great range with Voodoo being the best atm imo.

[Q] Anyone tried adding swap to dx?

Busybox allows dd to create a large file on sdcard.
It allows mkswap to create swap space on the file.
(at this point I'm super excited)
But when I try swapon busybox fails with function not implemented.
Any tips on getting this to work? Someone must have tried before. Virtual memory on the sdcard might have potential, or at least provide hours of fun with custom sysctl settings.
what are you trying to run on the dx that requires so much memory you need swap?
bobabc said:
what are you trying to run on the dx that requires so much memory you need swap?
Click to expand...
Click to collapse
Maybe he isn't trying to run a massive program, but add a windows like effect, prefetch, to speed up the phone?
For what I have read and heard, Android is relatively good at memory management, so it may not be a good idea to do that.
I think you can do some interesting things. If you have swap, you can perhaps encourage the kernel to swap out some rarely used processes like Xfinity, etc. (or at least some portions of it. Isn't it annoying how Xfinity always sticks around). Then you can tell the kernel to use more of the RAM for cache, thus making the phone faster. I know android already does a good job in managing memory and killing of less used processes but I think with swap we'd have a lot more flexibility.
Been doing some work with busybox and sysctl - you can read about it here: http://www.droidxforums.com/forum/droid-x-roms/16331-liberty-1-0-syssctl-config-4.html (I'm Marius on that forum).

Increasing readahead in a not completely retarded manner

So...there have been some reports going around on reddit and, here I guess, that increasing readahead will make your sd card faster, and maybe some of you noticed that on my build from early March that I had changed the default readahead values as well. And, the truth is, that it generally does, but the reason the mainline kernel tree doesn't have a higher readahead value isn't because some kernel "developers" here are smarter than Linus and everyone else, but because it is generally a bad idea, and the way some kernel "developers" have implemented it, it is an almost unbelievably stupid way to do it.
So, to give a little background about why the way some people implemented it is a really bad idea...readahead works like this - when you need a section of data from the disk, the kernel will grab that data, and anticipating you'll also use the next X number of kb, it will also grab that data as well and put it into memory. So, when you're doing something like listening to music, or copying data from an sd card (ie long sequential file reads), having a larger readahead is a good thing, and will speed up the process and make things more efficient. But when you aren't doing long sequential reads, you end up thrashing your data. In other words, if you set the readahead value to, let's say 1024kb on /system, every time you access a file you're reading ahead the data that you need, plus and additional 1024kb, or to the end of the file (wouldn't make much sense to read ahead past the end of a file). If you don't end up using that 1024kb it gets flushed from memory, and you read ahead on some other file by 1024kb. You don't end up using that section of data from readahead, it gets flushed, etc, etc. It's a tremendously stupid waste of resources to read ahead that much when you aren't using it. I mean, there's a reason why some of these things are tunable in the kernel and not set to higher values.
And if you want some serious proof check diskstats. With readahead set to 128kb on /system, I still have less than 10% of reads merged. If you only have 10% of reads merged with a 128kb readahead, why on earth (unless you don't know what you're doing) would you want to increase readahead to 1024kb?! To take this one step farther, with readahead set to 4kb, I still only have about 1/3 of the reads merged.
Isn't there a better way to increase readahead?
Yes. The better way is to use Wu Fengguang's series of patches found here http://lwn.net/Articles/372281/. The end result of these patches is that /system, /cache and /dbdata have readahead values of 4kb, /data and your internal and external sd cards have readahead set to 512kb. If you want to take it a step farther and increase it to 1024kb (or whatever value you happen to like - note that you get to a point where you don't get any more throughput, I wouldn't go beyond 1024kb personally), you can do it manually at
Code:
echo XXXX > /sys/devices/platform/s3c-sdhci.0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/queue/read_ahead_kb
(internal) and
Code:
echo XXXX > /sys/devices/platform/s3c-sdhci.2/mmc_host/mmc2/mmc2:bf2e/block/mmcblk1/queue/read_ahead_kb
(external).
What I do is have scripts set up in Gscript lite to increase and decrease readahead, but I don't even use these all the time. Also, if you don't want to flash kernels just to do this, you can set the readahead value for any drive manually, just like for the sd cards,
Code:
echo XX > /sys/devices/virtual/block/stl9/queue/read_ahead_kb
(/system)
Code:
echo XX > /sys/devices/virtual/block/stl10/queue/read_ahead_kb
(/dbdata)
(no point in increasing readahead on /cache, and really, really, really no point in doing it on bml or the other block devices...lol).
In other news...I promise I'll be back soon. I bought a house partially on a whim, partially to spite my girlfriend, and I've been rather busy tweaking the place I live in instead of my phone. But, I just started sorting through the patches I made to my personal sources and I will hopefully have it done tonight...(I know, I've said that many times before, but this time I'm serious...I think)
edit - as an aside, if you've ever wanted to have your display be at the lowered light setting that it switches to just before the screen automagically shuts off, you can control that as well at
Code:
echo 1 > /sys/devices/platform/s3cfb/spi_gpio.3/spi3.0/backlight/s5p_bl/brightness
it doesn't have to be 1, any value from 1-20 seems to have the same brightness, to my eyes at least. Again, I have this set up as a script in Gscript and if I want to dim the display a bit more I run this script...you have to use it every time you unlock the display or if you get close to the screen timeout limit and then touch the screen again.
good read and explanation. thanks
im guessing the new kernel will have the above mentioned readahead mods? cant wait!
Thank you man. This is the only useful description about readahead I've ever read and confirms that kernel default value is not so stupid as it looks.
so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?
npt1988 said:
so, is it a good idea to increase readahead if the only files on the sd card are mp3's, jpeg's and documents?
Click to expand...
Click to collapse
Yeh, bigger files that are streamed like movies or music will benefit from a higher read ahead. Smaller files like word docs might not.
[null]
just curious to know. will high readahead kb use more battery?
thanks
Hellboy4 said:
just curious to know. will high readahead kb use more battery?
thanks
Click to expand...
Click to collapse
Better to use 128kb for all existing IO blocks.
how increase read ahead cache and sdcard to 2048 in phoenix os
Hello XDA memebers and admin
i need help and very tired
i dont want use L speed in phoenix os for boost phone and speed read and write
i need other apk or code or tweak
please help me
Thanks for this useful post, which reminds me a few years ago every root user wanted to increase readahead. So I built a tool to actually test and compare read-speed when setting different readahead values.
The tool will read the content of the SD card (external or internal storage) up-to a predefined size (100Mb up-to 1Gb) and show resulting speed for various values of readahead (from 128Kb up-to 5Mb).
On a Nexus 4 running Android 4.2, 128Kb and 256Kb were between 20-50% slower, depending on files being read.
On a S10+ running Android 10 however, gain of increasing read-ahead is not so obvious.
I'd be very much interested in results from other devices running various version of Android.
You can get the tool here, and get support here.

[Q] New to Android

Ok i am new to Android i just traded my iPhone 3G for a HD2. I spent around 3 or 4 hours trying to get it running the way i like. After many errors i am on NexusHD2-Gingerbread_V2.9_NAND_(Android-2.3.5) and i am very happy. So now i need some help and yes i did look around before i am asking this. I read on a forum that i could install my apps onto my memory card and not into the phone is this true for the OS i am running now. And also i wanted to know if there is any apps i may need to make my phone run better even some cool apps i make need just to be happy/
hi razielleonhart, I believe you're referring the to the ext-sd function. To do that you'll have to repartition your SD card. You can do that in CMR (I believe you are booting form NAND?). Normally just choose a ext partition size and set the SWAP memory to 0 (I'm not sure what the SWAP is for, but I think it's to compensate your RAM if your RAM runs out of space, but that's unlikely on the HD2). When you boot back into Android you will notice that your "internal" memory has increased. Not all ROMs support this, and you'll have to check the thread on the particular ROM to see if the developer has cooked his ROM for that.
And you might want to check out some cool (but sometimes slightly hazardous apps) like SD booster (sets a new cache size on your SD card to make it run faster, just search the market) or SetCPU (allows you to overclock/underclock your phone's CPU, see link at http://forum.xda-developers.com/showthread.php?t=505419).

Categories

Resources