[Hero CDMA Android Development] jasonmaloney:
In regard to your explanation:

/sys/block/mmcblk1/queue/nr_requests

As stated previously in the old thread, this file has never and will never exist on the hero, because we only have one SD device.

0.0.0.0 is NOT a DNS. All this value does is force the phone to use whichever DNS the network specifies (which it may or may not be doing anyway).

ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=24
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3

You said to "ask someone in the networking field" about these values. Someone from the "networking field" (dhero) already chimed in (as did several other people) and told you that some of these lines don't even do anything. The only thing here that's probably making a difference in network speeds is the bitmask value (which is just setting all bits to 1, negating what they actually do).

For instance, I can tell you 100%, for a fact, that the "ro.ril.enable.dtm" line does nothing on the hero, because the entire point of this line is to enable simultaneous use of voice/data on GSM networks. CDMA networks have never been able to do this, and that's not something you can change

The line "ro.ril.enable.a53" also does absolutely nothing on our phones. A5/3 is an encryption algorithm, used on GSM networks. It has no use in CDMA devices, and was actually broken by hackers in recent history.

I've love to see some real documentation of how setting these values really makes a difference. The facts of speed tests are that (1) they are only testing your "burst" speeds which means they don't really answer many questions about long-term performance and that (2) they can vary wildly in the same time frame. I know that I have personally always had better EV-DO speeds than your scripts supposedly provide (sustained average 1.5-2mb/s downstream), and that all depends on signal range and nearby devices.

Right now I'm working on actually reverse-engineering the HTC RIL library to see what these values REALLY change. As far as I can tell, some of them never actually make a difference on the CDMA Hero and are just left over from the GSM Hero and other devices. They are read in from the prop file, but the variables which contain them aren't referenced by the CDMA code paths.

windowsmgr.max_events_per_sec=60

As stated previously in the old thread, this value does nothing because that's already the default value in the source code.

keyguard.no_require_sim=true

As stated previously in the old thread, this is already set in the build props.

debug.sf.hw=1

As stated previously in the old thread (and backed up by PROVIDING THE SOURCE CODE), this line does nothing because it's the equivalent of not specifying it at all. This is why we removed it from the CM build a LONG time ago. The ONLY time this line would EVER make a difference is if someone had deliberately set it to 0 beforehand, and as far as I know, no ROM (including the stock one) has ever shipped with 0 set.

The DEFAULT behavior of SurfaceFlinger is to always use the GPU when possible. The ONLY reason the "debug.sf.hw" line exists is for troubleshooting/debugging, for example when booting the emulator.

------------------------------------------

In regard to my own exploration of the zips provided (for reference I used the no-latency 691 zip):

You have a typo in your code.

CHECK_NOOP=` cat /sys/block/mtdblock3/queue/scheduler

The tailing backtick is missing.

Why are you providing busybox in your zip? The version you provide (1.15) is outdated; a newer version is already in CM7 and other ROM images. And the folder you're copying it to (system/sbin) doesn't actually exist.

By overwriting the init.local.rc script instead of appending your code to it, you are effectively breaking compcache in CM.

Your CPU profiles contain multiple infinite loops. This is bad practice. Your loops don't contain ANY sleep calls as far as I can tell, which means they run indefinitely, sucking up CPU cycles and battery. Your script should be sleeping on an interval.

The functions called by your infinite loop themselves contain infinite loops, which means that (as far as I can tell) they will never return and charging source changes will never be detected. Am I reading this wrong? Does this really work?