yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] pinetreehater:
sorry for the delay...

I tried to convert the file to .mpg and upload. Although that makes the file much smaller, it also seriously degrades it. I am uploading a 250mb file now. Bar says one hour twenty minutes.

In the meantime, CompCache comes out a hair faster. And since using it doesn't wear on your SD as much, it is is better all the way around.

The tweaks that Cyanogen made are having an effect. I also tested pure compcache vs linux swap, but on the CM 3.9.7 ROM (before CM made the tweaks to CompCache). In this battle, CompCache was slower, especially as more and more apps were opened.

Now, as my more detailed post after it finishes uploading will point out, CompCache doesn't get its stuff in internal memory pushed out by competing programs. Or something.

CompCache seems to work after HOURS and HOURS of standby....my browser was still loaded to the Valdosta.edu homepage four hours after the video was shot. That didn't happen before, something would push out the CompCache out of memory and it would have to start from scratch.
[G1 Android Development] enomther:
This sounds more like the compcache I know.

~enom~
[G1 Android Development] miketaylor00:
@PineTree, use my settings next. See my post above. I've had 3 people tell me it helps on .10
[G1 Android Development] warburto:
I will add +1 to that. Using Mike's user.conf file seems to have sped up the phone dramatically over stock cyanogen 3.9.10

Still trying to determine where the userinit.sh file is hidden :P
[G1 Android Development] darkphoenix2012:
The newest hero build I'm running supports a compcache setup if I am not mistaken. I'm currently running a 64mb Linux swap and it is pretty fast, but I wouldn't mind attempting a compcache setup if it would make a noticeable improvement. I'm using a 10mb/s fast sd card if that would make a difference. As far as wear and tear on the sd card is concerned, I am not worried about wearing the card out if its the best performance I've had sd cards live for years of abusive use ;)
[G1 Android Development] miketaylor00:
If the configs are the same, try the user.conf that I posted. I am really interested to know if it works on other ROMs.
[G1 Android Development] aron7awol:
Does anyone know what default settings are used with Cyanogen's ROM if a user.conf file is not used? We know CompCache is enabled in that case, but with or without a backing-swap if a swap partition is available? Also, what swappiness setting is used?
[G1 Android Development] miketaylor00:
It does use a user.conf file. It just doesn't use the userinit.sh file. It has another method for setting the configuration. You can still update your user.conf on Cyan ROMs
[G1 Android Development] aron7awol:
Thanks. Pardon my ignorance, but I don't see a user.conf in /system/sd. Where should I be looking?
[G1 Android Development] miketaylor00:
Which build are you on? I thought all Cyan builds have it located in /system/sd directory.
[G1 Android Development] aron7awol:
3.9.10

Do you know offhand what the default settings are?
[G1 Android Development] enomther:
pinetreehater,

I appreciate the effort you put into this testing. This is good information to witness in live action. Was very interesting to watch on a cm-3.9.10.

Thanks again.

~enom~
[G1 Android Development] aron7awol:
Let me second this. Thanks pinetreehater. Do you plan on doing the final test on whether the backing-swap helps or hinders?
[G1 Android Development] pinetreehater:
You know what would really be nice, is if a developer could create an app to force android to exclude a certain (perhaps 1 or 2) from having their memory purged. No matter how well compcache does (and it is working very well), every once in a while the browser gets its memory overwritten or otherwise dumped.

It would be uber sweet to be able reserve a place for the browser, never allowing the OS to purge its cache while it is running. Especially the browser, where an overwrite of the cache is very counterproductive (ie causing the slow ass page loads). I would permanently allocate so of my precious RAM to the browser.
[G1 Android Development] enomther:
Interesting concept. This seems to be something that could easily be implemented at the linux binary level of android. At the java, that would leave something entirely different to be desired.

Yeah, that is an interesting challenge you propose. While CGroups definitely help regulate foreground processing of selective apps, it does nothing in way of select memory management.

Definitely something to contemplate and/or rally support in the actual android dev community. One problem I see here is the subjective-ness of what would be considered a "critical" app to never purge from memory. In your case it's the browser, it joe-blows, it could be entirely different.

~enom~
[G1 Android Development] rpmccormick:
Giving Rosie fixed ram so it never has to do the 30-second reload would be sooo awesome! (and the browser too, page loads on the phone are ridiculous even though a tethered PC is fast as hell)
[G1 Android Development] enomther:
True, true.

I'm sure you'd get no argument out of the "HERO" users at large at that one.

~enom~
[G1 Android Development] zimphishmonger:
Cyan's roms look for a userinit.sh in /system/sd, I believe. If it finds one, it uses the settings in the userinit.sh, which usually refers to a user.conf file. If it doesn't, it automatically enabled basic compcache settings, i think 24mb 60 swappiness but I haven't been able to confirm as I have had a userinit.sh file for a while.

As I don't know where he stores his default settings, so that could mean that by default there is no user.conf file in /system/sd, just contemplating.....
[G1 Android Development] pinetreehater:
@arron7awol,

you my find some assistance in the CompCache thread

Yes, CyanogenMods store the userinit.sh under /system/sd/....which is the root of your ext3 partition.

Basically edit the user.conf file to your liking, then copy both files to the root of your C: on your computer...

then

adb remount
adb push /userinit.sh /system/sd/
adb push /user.conf /system/sd/

adb shell
chmod 655 /system/sd/userinit.sh
chmod 655 /system/sd/user.conf
exit
adb shell reboot

better instructions are in the CompCache thread.
[G1 Android Development] miketaylor00:
Actually he changed it on the last couple of builds. The A2SD script checks for the existence of the userinit.sh file. If it doesn't exist, then it turns on Compcache with no backing. Everything else uses the OS default. So if you want to run it on his latest builds, you do neet to run the userinit.sh. Follow the instructions on that thread.
[G1 Android Development] evilive27:
personally, i find linux-swap is faster than compcache.

I've tried different compcache settings but i find the system is faster with linux swap at 32mb and 10 swapiness
[G1 Android Development] miketaylor00:
Try the user.conf that I posted. Everyone who has used it so far has said it makes their phone faster.
[G1 Android Development] evilive27:
i'll try it out... is there anyway you can link it?

i know i should use search but i don't feel like going through a million pages to find it.
[G1 Android Development] miketaylor00:
I posted it on page 4 of this thread. But it's easy to upload so here you go.
[G1 Android Development] zimphishmonger:
Um....the forum's search engine allows you to look up by user name...Is it so hard to copy/paste miketaylor00's username and see which posts have attachments, ive seen him post his script at least 5+ times in several forums. It this (above) laziness that is making these threads so cluttered, it prob took just as long for u to ask for a repost than it did to find ONE of his many uploads.

I try to search these forums on my g1 (as Im sure a lot of you do), and it is already impossible as it is w/o the usual "flashing now", "cant find [insert feature\file]", etc

(end rant) Thanks for listening :)
[G1 Android Development] evilive27:
sorry dude... didn't mean to hit a nerve

anyways, this user.conf file does seem to make the phone a little snappier than linux-swap. Gonna leave the phone on all night and see how she runs tomorrow after being on for a while.

Thanks for uploading it again for me!
[G1 Android Development] miketaylor00:
Sweet. I've heard it makes Cyan boot up a lot faster too. I tried to get Cyan to put it in his build but he never responded to my email.
[G1 Android Development] miketaylor00:
Now if only I could get the OP to test with my settings... You could turn backing swap off and run it with just straight compcache. I know some people do that with my config.
[G1 Android Development] overground:
I tried your settings with 3.9.11.2 and it was smoking fast. Unfortunately, I was getting weird network issues that others have reported, also. Anyways, thanks for that, it works great.
[G1 Android Development] miketaylor00:
You're welcome. Thanks for letting me know. I'm thinking about trying to tweak hero to see if I can help out there.
[G1 Android Development] danielmid84:
You changed the CPU threshold but you left the CPU settings deactivated. 35 vs 40 had no effect with proc_cpu_en=0.
[G1 Android Development] miketaylor00:
Who didn't enable proc_cpu_en?
[G1 Android Development] danielmid84:
The OP, in his video you can see it is not enabled.
[G1 Android Development] dwang:
I think the main performance booster is lowering the swappiness value for compcache.

I have my swappiness set to 30 with compcache enabled, and the phone is much more responsive than with swappiness at 60.

Presumably because the kernel is doing less paging between RAM and swap, which means less decompression/compression taxing the CPU.

Only downside is I'm getting more frequent browser refreshes, but its not too bad. Certainly not as frequent as without a swap.

I haven't found that any of the other tweaks do too much. I just leave them as default
[G1 Android Development] miketaylor00:
There are a couple others that make a huge difference. Even dropping the swappiness from 30 to 28 makes a difference. You wouldn't think so but it does. I've benchmarked my phone both ways and it is consistently faster with 28 than 30. But 26 makes it worse. Trust me, I have spent hours and hours playing with these settings and testing them. I thought I would come out with a v2 of my conf file that was even better but I can't find anything that makes it better.
[G1 Android Development] darkphoenix2012:
Why has this not been put into hero builds for testing? Or is someone already doing so? IMO the non-hero roms are fast enough, I really don't see the need to push performance in cyanogen's or similar.:confused:

that's like saying a space shuttle during takeoff isn't fast enough lol
[G1 Android Development] miketaylor00:
If anyone wants to try these settings on Hero I would be interested in seeing how it works. Hero might need different settings since it is doing different things. I've been toying with the idea of tweaking one for a Hero ROM but I've been busy with other stuff. So far non of the devs have really been interested in using my tweaks on any ROMs except for xROM. So I will probably use JACs stuff to do my testing.
[G1 Android Development] ICBM:
So I saw this thread a few days back, and decided to give it a shot.. With 4.0.2, I don't see much difference between miketaylor00's user.conf and the typical linux-swap settings.

Then I decided to try to push it, enabling both comp-cache and linux-swap simultaneously (no cc backing obviously). Try as I may, I can't get it to work right. I mean, the phone works ok, but there's no obvious performance game versus not running any kind of swap/cc at all... Is this something that you've noted as well, or could i be doing something wrong? The relevant settings I'm using are:

#compcache related parameters

compcache{

compcache_en=1 # enable(1) or disable(0) compcache

cc_disksize=32 # Ram swap disksize - any number between 1 to 95 should work

cc_memlimit=18 # Limite the memory usage when backing swap is used

cc_backingswap_en=0 # enable or disable backing swap

cc_backingswap=/dev/block/mmcblk0p3 # pointing to the backingswap partition devi

ce

cc_swappiness=28 # default 60

}

#Linux swap parameters

#

# linux swap can only be enabled if cc_backingswap_en is set to "0"

#

linux_swap{

linux_swap_en=1 # enable(1) or disable(0) linux swap

linux_swap_partition=/dev/block/mmcblk0p3 # swap partition device

swappiness=28 # default 60

}
[G1 Android Development] ID#:
I'm wondering if there is any conclusion up to now which is the fastest configuration? Especially for Cyan (4.02) :D
[G1 Android Development] worldestroyer:
And for refrence, if you backingswap enabled, cc_disksize becomes a useless variable and doesn't affect the performance at all. You could set it to 0 and it would automatically fill up whatever space your swap partition is.

The only difference between you and huanyu's example is the memlimit, try setting it to 0.

Also, here's my user.conf based on Mike's and everything I've seen up here, works *really* well in 4.0.2

# General parameters
general{
apps2sd=0	# this is useless here, require a modified a2sd script
media2sd=0	# moves the medias to sd if /system/sd/media exists
}

#compcache related parameters
compcache{
compcache_en=1	# enable(1) or disable(0) compcache
cc_disksize=0	# Ram swap disksize - any number between 1 to 95 should work; default is 1/4 of the RAM (24)
cc_memlimit=20	# Limit the memory usage for backing swap (cc .5x known issue-defaults to 15% of total RAM)
cc_backingswap_en=1	# enable(1) or disable(0) backing swap
cc_backingswap=/dev/block/mmcblk0p3 # pointing to the backingswap partition device, swap
cc_swappiness=28 # default 60
}

#create swap file for compcache or linux swap
swap_file{
swap_file_en=0	# set to 1 to create swap file
# set to 0 to del the swap file
linux_swap_file_size=32	# swap file size in MB
linux_swap_file=/system/sd/swap.file	# pointing to the swap file location ( must be /system/sd/)
}

#Linux swap parameters
#
# linux swap can only be enabled if cc_backingswap_en is set to "0"
#
linux_swap{
linux_swap_en=0	# enable(1) or disable(0) linux swap
linux_swap_partition=/dev/block/mmcblk0p3 # swap partition device
swappiness=30 # default 60
}

#virtual memory
sys_vm{
sys_vm_en=1	# enable(1) or disable(0) virtual memory configurations
page_cluster=0	# default 3, (0 since CM3.9.6+)
laptop_mode=0	# default 0
dirty_expire_centisecs=3000	# default 3000
dirty_writeback_centisecs=500	# default 500
dirty_background_ratio=5	# default 5
dirty_ratio=10	# default 10
}

#cpu clock
proc_cpu{
proc_cpu_en=1	# enable(1) or disable(0) user cpu configurations
# freqency options
# 19200
# 122880
# 128000
# 245760
# 384000
# 528000
scaling_min_freq=192000	# default 245760
scaling_max_freq=528000	# default 528000
sampling_rate=2000000	# default 2000000 depending on kernel version
powersave_bias=0	# default 0, (200 since CM3.9.6+ )
up_threshold=35	# default 40, percent cpu usage before going up a speed step
}
[G1 Android Development] miketaylor00:
Can you post what you get back from sh /system/sd/userinit.sh -s
[G1 Android Development] student.driver:
OK, I have 4.0.2 and I am trying miketaylor's user.conf, but I found that I don't have a user.conf file in /system/sd/, so I just dropped it in there. How can I verify that it's working? I thought I read something about using "free" but that it might not be entirely correct. I do see a listing for swap, but it's 24MB vs. the 32MB of the swap partition I created. I keep hitting all the disparate threads trying to put this all together, but I'm clearly missing something. I am also not using any other tweaking files (userinit or whatever), as I was under the impression the user.conf file will control everything on its own, with userinit overriding settings after the fact. Thanks for any info to clear this up.
[G1 Android Development] student.driver:
I am going to take a stab at this and say that you need userinit.sh to make user.conf usable, right? I am trying to work from this thread:

http://xdaforums.com/showthread.php?t=542899&highlight=userinit.sh+setup

I just want the miketaylor00 user.conf file to be active. :)

Using userinit.sh -s, I see that swapiness is set to 28 and the other settings appear to conform to mike's (except I changed the min freq to 245670). I saw that goodcompress was 100% at boot, so I will check it out tomorrow after I've been running the music app, Last.fm scrobbler, and all the other crap I like to do.
[G1 Android Development] miketaylor00:
Yep, the old Cyanogen Mods had the userinit.sh built in. 3.9.10 and up don't have it but support it. Follow the steps in that thread, then drop the user.conf in on top. After it is setup you only need to change the user.conf to change anything.
[G1 Android Development] student.driver:
I just wanted to add that when using the miketaylor00 user.conf with my stock 4.0.2 Cyanogen ROM, the home screen has renewed urgency to come up when using any application. Also, it's a bit more friendly to my usual workload of checking email and web browsing while playing music through the stock app and letting Last.fm scrobble it. Very cool stuff.

For those that might have found this thread and don't know what to do, simply grab his user.conf

Here

http://xdaforums.com/showthread.php?p=4334135&highlight=user.conf#post4334135

and use the userinit.sh "package"

Here

http://xdaforums.com/showthread.php?t=542899

Then, swap out the user.conf included in the zip with Mike's and continue following the directions on putting the files there and changing the permissions.
[G1 Android Development] miketaylor00:
Glad I could help
[G1 Android Development] cal3thousand:
I'd also be interested in seeing comparisons that rely heavily on SD card usage. Its been stated that the bus becomes a bottleneck, so if you are doing an activity that takes a toll on the SD card bus, would it slow down the linux-swap?

For example, listening to music (on card) or watching a video and then going to browser and back?

I would imagine that CompCache will gain the advantage if the bottleneck in the SD card becomes sufficient.
[G1 Android Development] student.driver:
That is a good idea. When I first set up CC with backing swap last night, I had the stock music player going with Last.fm scrobbling. Then, I tried to hit the XDA Developers forum and it got about halfway and just stopped. It sat there for a good 10 seconds or so, but didn't timeout. I paused the music, and when right when the scrobbling stopped the browser continued to load immediately and went really fast. I haven't seen this issue since, but it did make me wonder when you hit the bottleneck.

My friend said his starts creeping after two days of use, but he's using the default user.conf settings. I really hope this isn't the case, as I have a real issue with rebooting any OS (yeah, I've been a Linux guy for a while :)) and rebooting your phone just seems like the worst thing ever.
[G1 Android Development] dwang:
I've definitely have noticed that playing music with a linux swap slows down the phone much more so than playing music with just compcache (no backing swap) enabled.

I'm actually quite pleased with the performance of compache in 4.02. The phone is very fast at initial boot, and stays relatively fast even after days of not rebooting. Thats something I couldn't say with cy versions previous to 4.02. They've always slowed down quite a bit after a day or 2 of not rebooting.

The only downside to compcache I'm seeing is the relatively small swap size, which means I see more browser reloads than I would like to.

You can increase it, but that ends up taking too much real memory away so I leave it at 24megs.
[G1 Android Development] miketaylor00:
You shouldn't have much slow down with the backing swap settings that you are using. If you had a really large memlimit on your backing swap you might because it would fill up and become harder for the OS to manage. I shared my config with the xROM guys weeks ago and no one has complained about slow down yet.

I think that is one of the benefits of having CC with BS. When you use over 32MB of normal linux swap the phone will start to slow down. It may not be slow at first but as it grows it will slow down. With CC you get 32MB of RAM plus 18MB of swap for a total of 40MB. Plus the CC is compressed so it would actually take a lot more than 40MB of linux swap to store the same data.

BTW, I made it into someone's signature. I can die a happy man now. ;)
[G1 Android Development] dwang:
dupe...........
[G1 Android Development] dwang:
I think you have it backwards.

If you use CC with backing swap, the memlimit is how much RAM compcache will use for compressed data before moving to the disk swap.

So if you set 18megs as the memlimit, compcache will use up to 18 megs of RAM as swap and once that fills up, it will go to the disk swap and use whatever size you have partitioned (in this case 32megs).

This is a quote from the compcache author:

"memlimit_kb parameter is used only when backing_swap is used. If you don't want to provide any backing swap, then you must use disksize_kb instead.

BTW, disksize_kb is upper limit on uncompressed worth of data given device can hold. While, memlimit_kb is upper limit on compressed worth of data given device can hold.

I understand that specifying disksize_kb value as upper limit on uncompressed data size seems bit counter-intuitive but this is how it is... We need to present a "fixed-size" disk to kernel."
[G1 Android Development] miketaylor00:
Oops, you are right. I said it backwards. It is 18MB of CC and 32MB of BS. Thanks for correcting me. Do you happen to know what the compression ratio is for CompCache?
[G1 Android Development] dwang:
I think its data dependent. I'm getting between 60 and 70% compression ratio, so with the default 24 meg disk_limit, I'm using about 9.5 megs of real RAM.

Also, when you use backing swap, its going to use the size of the swap partition as the upper limit for the swap size.

So if you have a swap partition of 32 megs, you'll only able able to store 32 megs worth of swap data. So it would be 18 megs of RAM + 14 megs of swap. Its not going to be 18 +32.
[G1 Android Development] miketaylor00:
I thought that was just the ratio of what could be compressed to total attempted. I get about that level too without BS. But when backing swap is turned on it goes to 100% no matter what. So it seems to me that it isn't saying that it was able to compress the data more, just that everything that it attempted to compress was compressed. 70% of the data could be compressed and 30% used either uncompressed RAM or BS or LS depending on the setup. Or am I missing something?
[G1 Android Development] dwang:
hmm ok that makes sense too. if you have backing_swap enabled, whatever can't be compressed goes to disk swap so it will be 100%.
[G1 Android Development] miketaylor00:
I disagree. Compcache uses RAM swap, not linux swap. that 18MB is in RAM. So you can still use all 32MB of your linux swap. Your Swap partition and your RAM are completely separate. Not shared at all.
[G1 Android Development] dwang:
if you use backing swap they are shared. The swap partition is the overflow once the RAM memlimit is reached. If you run rzscontrol -s, you see that the disk_limit is the size of your swap, and that is what is reported to the kernel.

If you run free u see that the swap size is 32, not 32 +18.

If you enable the swap partition via swapon then they aren't shared.
[G1 Android Development] ei8htohms:
I'm with Mike on this one

My understanding was that compcache can still not compress to external storage, so the backing swap is only for the uncompressed swap. It's possible I've misunderstood that or otherwise missed some info on the 0.6 update however.