Has anyone seen a data drop with the latest update? I've not seen any comments saying they have......
If you are curious you can open the terminal emulator and start the following:
$ su
# logcat -b radio | grep bad
Then hit "HOME" and the program will remain running (unless you run low on RAM, at which point it will get whacked, but...)
The above line will not print anything UNLESS the "bad connection" tracking code gets hit. This will give you the ability to see an entry for each time the code finds a bad data connection and resets it. Note that the expectation is that this is the only way you'll ever see them, as the point where the drop gets detected is essentially instantly when it fails (e.g. it's not polling for status, it actually catches the state transition when the failure happens.)
It should also be pretty hard to get materially under 100Mb of free map space in RAM with this build, which helps the "user experience" a LOT. While it's not impossible to drive the system lower on free RAM it was pretty easy to get it down into the 50MB range before, and that's too low - Android does poorly when it gets RAM constrained, and the adjustments I made to the free space management routines in the latest update should make it almost impossible to get backed into that corner now. The code has was adjusted to be heavily prejudiced against services and data providers that do not have active consumers of their respective resources and to start protecting available memory in the 80-100MB range rather than allowing system RAM to fall into what IMHO are critical free space levels first.
Finally, if you want to get even MORE aggressive the "V6 Supercharger" script is in /system/xbin, as the author says is ok. I don't run it but you might want to; I suspect you get 90% of the benefit of doing so with the adjustments I made to the minfree maps.
Recently I noticed that my browser has to reload often when I come back to it after running other apps for a while. Then remembered TG made some 'minfree' memory tweaks. Basically he raised the level of free RAM before Android starts killing idle processes, thus keeping more memory free to speed up loading new apps. This is all good if you're loading new apps. But if you want to keep more apps cached in memory, the default Android settings are more appropriate.
Default Android starts killing idle apps when less than 24 MB is free, with TG's values, it starts killing at 90 MB. Now I'm from the camp that believes the Android OS is good at managing multiple apps in the background 90+% of the time, and any free memory is wasted memory. Instead it should be used to cache and keep more apps in the background ready to be run again. So if you agree with this, you may want to reset the values to default Android OS values & reboot.
In /etc/init.d/99memory, 2nd to last line, the default Android OS values are:
"1536,2048,4096,5120,5632,6144"
NOTE: These are pages, so (6144 * 4)/1024) = 24 MB
Basically CM7 B0.8 values are more like running mildly-aggressive V6 Supercharger scripts, which I was never a fan of. So this restores it to default (my belief is that the Google engineers have it right since they know the internals better than tweakers). If you disagree, it's fine to leave it the way it is.
UPDATE: Default values for 512MB devices like the MT are "2048,3072,4096,6144,7168,8192"
