[Epic 4G General] APOLAUF:
Before you read my response, please know that my disagreement means no disrespect or ill-will... this is afterall a conversation, so here are my two cents:

I think there are two sticking points that I have with your argument. Actually, 2.5. The first is that yes, while the phone uses an ARMv7a CPU, it still relies *completely* on a baseband processor (using the old ARM11 (i.e., ARMv5)) platform. This processor has its own power handling that's independent of the main CPU's power management. Suffice it to say, that when the data connection is not dormant, the baseband processor will operate at full speed.

Point two: It doesn't make any sense to use direct memory access for data one way and programmed I/O for another. Almost nothing at all uses PI/O anymore, because nobody likes to tap someone on the shoulder repeatedly, asking "are we there yet? are we there yet?" I can virtually guarantee that the baseband processor has direct memory access/addressing and interrupt-level management. Even if we were to assume PI/O, there'd be no case for DMA one way and PI/O the other. Sorry, but that doesn't make sense from an architectural standpoint... the data bus to the baseband processor is the same for upstream and downstream data.

Point two point five: This is related to point one. Let's say that your theory of the phone idling is correct. (I can tell you that the CPU isn't entering a 100MHz sleep state just by leaving the phone alone with the screen on for a few seconds... no intelligent power management would do that, and even if the power management weren't intelligent, just having the screen and digitizer on are enough to prevent the CPU from going to sleep). Also, keep in mind that the gyros aren't constantly enabled, so they're not consuming power at the same rate as if they were constantly being used. Anyway, even if the CPU *were* running at 100MHz sleep, think about it: The data bus to just about everything on the ARM platform is 32 bits wide. We can safely assume that memory interfaces aren't going to clock less than 100 MHz core clock, simply because there's a lower limit to how slowly memory can be refreshed (yes, this is independent of the clock speed, as RAM is refreshed much faster than clock, but the diminishing of memory clock to below a certain point, say 100MHz, has diminishing returns in power savings). Even at 100MHz, equating, rather simplistically, the memory bus to the processor speed, at 32 bits, you're moving data at 381 *megabytes* per second! So, clearly, neither bus speed nor CPU speed are the bottleneck here. (To make a point, in order for bus clock speed to affect upload speeds with a 150kbit/s cap, the bus or CPU would have to be clocked down to 4.69 *kilohertz* :) )

Rather, I propose that the throttling is a very *active* event. This explains elevated CPU use, and perhaps the erratic reports of people blasting through the cap; perhaps the process involved in capping upload speeds has crashed or malfunctioned on their devices. Or, it could be a very nasty bug in the way data is handled. But I very much doubt that this is a physical hardware or power management implementation problem. Your theory of using another upload protocol sounds interesting - perhaps it's using 1xRTT, but then again, the speeds are FAR too consistent. Most 1xRTT networks won't give you anything faster than 50-70kbit/s. It *could* be using Ev-DO rev 0, but even with that standard, I could get faster upload speeds, or slower, but never that consistent. It certainly can't be using both standards at once. It remains to be seen what the solution is. Let's hope it gets here soon!

P.S. I hope none of that came off as being abrasive... but I did want to further the discussion. People bringing their ideas here is how things are solved, or at least explained. Let's keep it going!