Given that the samsung froyo update has been delayed another month from what i have heard, i've decided that i might as well use a lagfix until froyo comes along.
Given that there are so many lagfixes, some old some new, and i have no idea which is good and which is new.
Could someone tell me which lagfix works the best?
and if possible also point me to a guide here or out there in the www.
thanks
Voodoo if you are on Eclair. OCLF if you are on Froyo.
But I am not running any from yesterday on my JPH. So far so good. Quadrant 1008.
Trust no one of them fixes... <insert mysterious music>
All the so called Lag Fixes do really work, BUT you might ruin your internal SD card in the process.
If you are willing to take the chance, then by all means go ahead and DO iT the speed increase is really amazing
However... expect your internal SD to die quickly as a result of that.
It's like a drug you know, just the same stuff some athretes takes to get an energy boost at the cost of their health.
AllGamer said:
Trust no one of them fixes...
All the so called Lag Fixes do really work, BUT you might ruin your internal SD card in the process.
If you are willing to take the chance, then by all means go ahead and DO iT the speed increase is really amazing
However... expect your internal SD to die quickly as a result of that.
It's like a drug you know, just the same stuff some athretes takes to get an energy boost at the cost of their health.
Click to expand...
Click to collapse
How is it destroying internal sd card ?
Sent from my GT-I9000M
if you search for SD problem here in the forum, all the topics that comes back states they were either using lag fix for a while, installing lag fix, or something else to do with lag fix
So you're trying to say that rfs file system which is reading and writing on sd also isn't destroy the internal sd?
Sent from my GT-I9000 using Tapatalk
what ever it's the slow rfs used by Samsung is at least less invasive than the methods we are currently using for the Lag Fixes
i'm not a developer, but if i were to fix what is wrong right now, i'll go with a virtual RAM drive solution.
that's how i configured old win2k servers and Win9x/XP machines
by avoiding write to a real disk it prevented delay, and that improved speed drastically even on low end machines
back in the SGS phone we are stuck with 512 RAM, so wasting more ram on a virtual drive might not be a good idea, but if we even setup a "cache" drive of 128 MB RAM instead of writing to the partitioned internal SD, that will kill 2 birds at once
improve speed and prevent SD write exhaustion
I'm still not yet at the point of being annoyed by the lag, else it would have been a big motivation to implement the idea mentioned above.
the only time i get lag is when i install 2 ore more Android Apps from Market simultaneously, like when there are updates for 5 or more products and you click OK on all of them.
normal daily operations has not shown any delay at all.
my only trick is i prevent any unwanted background services from starting with the phone.
i use the original lag fix that adds a logical link from /data/data to /dbdata.. have not read this causing any problems with corrupt sd cards as it is not changing partition type or anything.. the only drawback is the size is limited.. but as long as you dont install huge games i have over 100 apps with no problems ie..
not as high benchmarks as some of the others (but i belive they are artificial anyway) and the phone is fast and hardly ever lags..
try running k9-mail without it and it takes about 5 minutes to go through all my mailboxes versus about 30 sec.
C:\galaxy>cat speedtweak.sh
#!/system/bin/sh
## this script is made by deckcard##
## clean up csc folder
echo
echo Speed tweaks that move data from mmc to nand
echo
echo busybox cp -rp /data/data /dbdata >> /sdcard/1.sh
echo mv /data/data /data/data.bak >> /sdcard/1.sh
echo ln -s /dbdata/data /data/data >> /sdcard/1.sh
echo reboot >> /sdcard/1.sh
su</sdcard/1.sh
rm /sdcard/1.sh
theres tons of different fixes, some are better than others, but its all personal preference...and also, some of them just improve your quadrant score and not real life performance.
Related
I've noticed that my G1 (Running CM6) tends to run out of RAM fairly often, I was thinking maybe having swap space might help me a bit with this, however I only have a Class 2 SDHC Card (16GB), would I see any performance increment or should I just wait until I can afford a much faster one? (eg. The Kingston Class 10 one)
I would suggest to use no swap at all ... if RAM is too low, try to enable compcache it will help you probably a bit. I noticed a massive performance drop when enabling swap on CM6.
Sent from my Htcclay's Superfly G1 using XDA App
Swap and CM5/6 don't get along. The memory killer in the kernel thinks that swap is actually free RAM and keeps more things open, stopping tasks from being killed at all. If you want to use swap, I recommend you use a donut/cupcake/hero rom that uses a different kernel so that things don't get down to a screeching halt. And anyways, the fastest speed I have ever seen my phone write something from my computer to the phone via USB is 2.7mb/s, compared with 6-12mb/s I get from an sdcard reader. That means that even when your phone is writing at top speed, it is just barely far from the 2mb/s write speed guaranteed by a class 2. You will definately see better performance with swap on a class 4, but anything higher won't benefit your phone much at all, unless you regularly transfer large amounts of files to your memery card via a card reader.
AndDiSa said:
I would suggest to use no swap at all ... if RAM is too low, try to enable compcache it will help you probably a bit. I noticed a massive performance drop when enabling swap on CM6.
Sent from my Htcclay's Superfly G1 using XDA App
Click to expand...
Click to collapse
Compcache didn't improve performance at all, for me at least.
mejorguille said:
Swap and CM5/6 don't get along. The memory killer in the kernel thinks that swap is actually free RAM and keeps more things open, stopping tasks from being killed at all. If you want to use swap, I recommend you use a donut/cupcake/hero rom that uses a different kernel so that things don't get down to a screeching halt. And anyways, the fastest speed I have ever seen my phone write something from my computer to the phone via USB is 2.7mb/s, compared with 6-12mb/s I get from an sdcard reader. That means that even when your phone is writing at top speed, it is just barely far from the 2mb/s write speed guaranteed by a class 2. You will definately see better performance with swap on a class 4, but anything higher won't benefit your phone much at all, unless you regularly transfer large amounts of files to your memery card via a card reader.
Click to expand...
Click to collapse
What if I have a task killer app? Because running out of RAM is just as bad as having too much running...I don't have many apps as I only keep what I actually use as well.
I have to ask, what are you seeing as the symptom of "running out of ram" the system will always use all ram so it will always have nearly none free.
By this I of course mean what is taking forever from you the end users perspective.. from there we can tweek in the right direction or work on making the phone prioritize what is needed to be useful.
Many times people put tons of swap only to find the the problem application is still removed from ram/swap due to configuration and the system is even slower with swap.
Also before enabling swap try the settings -> adw -> system -> system persistent is enabled. (Or equivalent on other launchers)
If you really want to try swap, it wont be fast but in very little amounts
ezterry said:
I have to ask, what are you seeing as the symptom of "running out of ram" the system will always use all ram so it will always have nearly none free.
By this I of course mean what is taking forever from you the end users perspective.. from there we can tweek in the right direction or work on making the phone prioritize what is needed to be useful.
Many times people put tons of swap only to find the the problem application is still removed from ram/swap due to configuration and the system is even slower with swap.
Also before enabling swap try the settings -> adw -> system -> system persistent is enabled. (Or equivalent on other launchers)
If you really want to try swap, it wont be fast but in very little amounts
Click to expand...
Click to collapse
Well, if I have MSN Talk open, the home screen tends to fall out of memory (Yeah, I have System persistent enabled) and Messaging is extremely slow (To the point where a letter appears a good second after I press the key), it's that kind of thing when I run certain programs, it makes it hard to have stuff like JuiceDefender running because I always run out of RAM even just running the Speedtest app then.
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
When I was running mimocan, I also moved/symlinked /dalvik-cache and /media to the external ext4 partition. Don't know how much it improved things, though.
Seems like running autokiller really is enough to address the memory management issue, maybe we'll see those settings tweaked in future firmwares.
aeo087 said:
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
Click to expand...
Click to collapse
aeo087 said:
The current lag-fixes optimize application load times by changing the filesystem for "/data", and with that fix the phone does become a lot more responsive.
With /data optimized, I still notice a pretty bad lag when opening anything database related or cache related, for example: Adding a shortcut to the homescreen takes a good 15 seconds to load the list, I tried the same thing in a Droid X and it's instant... LauncherPro stalls everytime you do something for the first time, and then works ok, it loads animations to the cache so... (write times to cache maybe?)
Any thoughts on this? I haven't done all the research, so these are just my observations. (I've seen this with OneClick lagfix ext2, chainfire's 1.80 ext2 and ext4, and Tayutama's ext2 and ext4, on JM5, 6 and 7).
Another problem I have seen is the low ram lag, as soon as the phone dips under ~70MB of ram it becomes extremely sluggish, I haven't used a single firmware where I don't need autokiller with aggressive settings, again comparing to a nexus one or droid x, those phones work flawlessly with ~30MB free...
I haven't tried the Vooodoo lag fix, does that or any other lag-fix address this issues?
Click to expand...
Click to collapse
Nope, Voodoo doesn't address it either. /dbdata acts strangely if you try to mess with it and seems to cause some strange issues, which is why it has been left out of fixes so far. Plus, /dbdata is on very fast NAND which doesn't suffer so much as the sdcard from RFS.
Low ram lag is probably touchwizz related, or if not touchwizz, than some other badly done Samsung modification. Unfortunately that kind of thing is very hard to find. It could be something completely unrelated though, like a badly made driver that behaves badly when RAM is low.
RyanZA said:
Nope, Voodoo doesn't address it either. /dbdata acts strangely if you try to mess with it and seems to cause some strange issues, which is why it has been left out of fixes so far. Plus, /dbdata is on very fast NAND which doesn't suffer so much as the sdcard from RFS.
Low ram lag is probably touchwizz related, or if not touchwizz, than some other badly done Samsung modification. Unfortunately that kind of thing is very hard to find. It could be something completely unrelated though, like a badly made driver that behaves badly when RAM is low.
Click to expand...
Click to collapse
Am I right to say that that lag when adding a shortcut or accessing the list of apps comes from dbdata? why is the phone so slow at pulling up that information? Also, have you seen any performance benefit from optimizing the cache partition?
So, many of us want more storage space for apps. It seems that there are a couple of options:
1. Use BlackRose to increase the /data partition.
2. Use DT apps2sd to move the applications to the sd card
3. Use DT apps2sd to move the dalvik cache to the sd card
(or a combination of 2 and 3)
Can anyone provide a clear understanding of what the trade-offs are? Option 1 has some appeal, as it just leaves everything in internal memory and simply repartitions to match the a good setting for my current ROM (OxygeN1mod).
I have used DT apps2sd, but all I moved with the dalvik cache (option 3 above).. It seemed to work OK for a while, then everything seemed to fall apart (FC, etc.) Not sure if the problem was with the SD card, the fact that the dc was moved, or something unrelated.
So, in short, what are the performance considerations of moving either apps or the dalvik cache to the SD card?
The only performance consideration is the speed of your SD card and Nexus' SD controller (the slowest of them), compared to the speed of Nexus' system NAND (the original location of /data partition).
The space consideration is simple - no matter how you split Nexus' partitions, you end up with nothing. I don't have too many apps installed (only 103), and I have 700 MB taken on /data on my MT4G. So even if you squeeze 300MB out of Nexus using Blackrose, it's still nothing.
Jack_R1 said:
The only performance consideration is the speed of your SD card and Nexus' SD controller (the slowest of them), compared to the speed of Nexus' system NAND (the original location of /data partition).
Click to expand...
Click to collapse
In other words, using blackrose means you stay on the system NAND, whereas DT you have the SD controller bottleneck? Do we have any performance measurements on these?
Jack_R1 said:
The space consideration is simple - no matter how you split Nexus' partitions, you end up with nothing. I don't have too many apps installed (only 103), and I have 700 MB taken on /data on my MT4G. So even if you squeeze 300MB out of Nexus using Blackrose, it's still nothing.
Click to expand...
Click to collapse
I thought this was the N1 forum
Sure, getting another phone will give me more NAND. But for me, getting an additional 50-100 MB is what I'm after.
Theoretically, SD controller can be faster than NAND, since NAND is slow. On newer devices with eMMC you can see this very clearly.
The problem is that eMMC use 8 bit MMC protocol, while regular SD card uses 4 bit - this is dropping the performance expectations for N1 2-fold already. Also, SD controller in Nexus One might have a system throughput bottleneck, just like its WiFi path does.
I don't think there are any ready-made measurements, but you can easily make your own. Take a big file (50MB or so), move it from /data to /sd-ext, and move it back. It'll give you a good measurement of write speed. There might be performance measurement apps in the Market, I just didn't ever look. The easiest will be just reading from the same 50MB file, from both locations, and seeing which read takes less time.
I still hang around in N1 forum, since I had this phone for a while, and I made some stuff for it, including sorting and writing a big part of the Wiki. But I don't have the phone anymore.
If anyone could help me out here I will love you LONG time:
I am wondering id I should set up a swap partition and use it with this script (apps/data 2 ext, supports swap). I am starting fresh on my Nexus One installing a Gingerbread MIUI ROM using this script for the first time. I was wondering if I should use a SWAP with my class 4 16gig sd card. I will have a 1gb EXT partition. If anyone could state simple pros/cons I would MUCH appreciate it. I have heard good but mostly bad about swap on gingerbread saying that it is not needed and can cause bad.
Does the N1 really need SWAP with Gingerbread? I'm shaking in my pants posting this but I have not seen any related articles, let alone for the N1. I have done a Google search but that doesn't help, it confused me more if it is worth it.
Thanks again. Deuces.
There are some comments from experienced users here on swap, most are against. Here is a link that has a lot of comments--
http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/
I am no android tech, but never used and don't have issues. I run a lot of apps over a hundred from the Market alone
Thanks! Exactly what I needed. No SWAP for me!
Glad to help--
I'm no expert either. But I do have a 256MB swap partition.
Swap *should* only be used when physical memory is low, and more is still needed by the system. If you're low on memory and need more, then swap might be useful then.
There's a kernel setting called "swappiness". I have this set to a low setting "5", which I believe means that swap should only be used as a last resort i.e. more importance is put on using physical memory over swap.
Yes swap is slower. If a system is swapping out, then it's logical to add more physical memory to the system. However as we cannot upgrade physical memory on our phones, so I suppose swap is the next best thing.
Anyhow that's just my personal thinking. My Nexus is running sweet and I don't notice any considerable slowdowns. However perhaps my swap has never really been required?!
Swap is made for desktop OS, where there is such thing as "lack of memory".
Such thing doesn't exist on Android, mobile OS of completely different design.
The reason is - desktop OS can't kill the tasks you've left running. Mobile OS can, and will, once it senses that it needs more memory. And the tasks themselves are built to be killed.
Adding SWAP is fooling Android that it has more actual memory than there really is - and the OS is using it like it was real memory, not killing tasks when it should. And while doing that, SWAP is far slower than just killing and reloading tasks - because it requires writing to and reading from the SWAP partition the whole app, while when killing and loading it, only reading is required - making the process MUCH faster.
I believe that's the essence of the earlier reference.
Shortly, unless there is severe lack of RAM (and on N1 there isn't by any parameters) - SWAP will make things worse, not better.
By activating compcache (~18% should do), and kernel samepage merging, there is no need for swap. I think texasice confirmed this, although I am not sure.
Sent from my Nexus One using Tapatalk
I would never use swap for GB. Tough there is discussion of using it on ICS, the few times I have tried it I did not use it.
I used swap a long time ago on CM6 or early 7 and there was absolutely no benefit in my opinion. Doesn't swap force more read/write times on SD which can decrease the life as well? That's just my $0.02.
TheAndroidStop said:
I used swap a long time ago on CM6 or early 7 and there was absolutely no benefit in my opinion. Doesn't swap force more read/write times on SD which can decrease the life as well? That's just my $0.02.
Click to expand...
Click to collapse
Swap isn't useful when it's not being used, and FroYo or Gingerbread hardly uses that much RAM. ICS, however, with its full hardware acceleration, is a real memory hog. Now, though, if we enable kernel samepage merging and a zram amount of like 18%, we wouldn't need a swap partition. Like it's been said before, swap is very slow, much slower than actual RAM.
Sent from my Nexus One using Tapatalk
Swap seems as use full as a taskiller in Android....
Sent from my Nexus One using xda premium
Hello, does not swap hard Android phone for auxiliary memory damage the hard?
Hello,
I'm using my N7000 with CM 10.2-20131214 for about third month and it got pretty slow and laggy. This is becouse of leftovers from previous data.
Using AndroBench random write score is 0.28 MB/s 73.3 IOPS which is dramatically slow.
There is an app for cleaning this mess called LagFix but N7000 is not supported.
I was also trying to TRIM using Terminal Emulator with no resault.
Code:
[email protected]:/ $ su
[email protected]:/ # fstrim -v /system
fstrim -v /system
fstrim:FITRIM: Operation not supported on transport endpoint
Is there any kind of solution for this issue, or I just need to do formatting internal storage from time to time?
No, there is no way to enable trim on the device.
It could cause a superbrick if you did manage to activate it.
Azeazezar said:
No, there is no way to enable trim on the device.
It could cause a superbrick if you did manage to activate it.
Click to expand...
Click to collapse
Thanks for reply
Good that i didn't :<
Can formatting may be threat also?
Is it possible that this will be fixed in future?
Well, the fix is to disable what would cause a superbrick. (Which is why it failed in your case)
Completely fixing it, as far as i understand it, would requiring updating the EMMC firmware, which is risky, if not impossible.
You will just have to use the old garbage collection the chip has been using quite successfully. It seems to be doing fine.
No need for trim, or any special action on your part.
P.S.
Your random write speed is normal and identical to my own note.
Now, how often do you think random writing is bottle-necking your note?
It is likely something else that is the bottleneck.
My guess is that those guys at cyanogen are still using gpu clock speeds from the S2. I have not used that rom in a while, but i remember overclocking my lowest gpu step to 160 (from 100(CM), or 130(Stock) still nowhere near the top step that is 266) to give it a little boost.
I am not a developer, And i have not messed with that stuff for a while. So do your own research to what the problem is.
Azeazezar said:
My guess is that those guys at cyanogen are still using gpu clock speeds from the S2. I have not used that rom in a while, but i remember overclocking my lowest gpu step to 160 (from 100(CM), or 130(Stock) still nowhere near the top step that is 266) to give it a little boost.
I am not a developer, And i have not messed with that stuff for a while. So do your own research to what the problem is.
Click to expand...
Click to collapse
CyanogenMod uses 133MHz as the first GPU step for our note
yes, you can trim the n7000...
http://forum.xda-developers.com/gal...kernel-trim-speed-cyanogenmod-galaxy-t2875730