Min/Max frequencies of the CPU and you - Asus Eee Pad Transformer Prime

I remember there was this long debate about ASUS/NVIDIA and how they took away the 107MHz frequency and how it affected battery life..
For the record, on my CPU Spy I have it at 120 hours with 35% at 370MHz and 0% (56 minutes) at 102MHz with the rest in deep sleep and 405 and up to 1300MHz with great battery life.
In any case, there's a discussion in EVO 3D about CPU that might have some bearing on the frequencies and how it affects battery life and why sometimes the lowest one isn't the best for battery life.
Now, of course we know the variances between all the devices posted on here so while a lot of folks might have been fine, some might not, but that seems to be the case for the Prime. Hence we saw posts from folks saying they were fine with battery when it was at a min of 370MHz while some had worse.
Also, the Prime does use a different CPU than the EVO 3D so that could be taken into account as well
Anyways, good read for those interested
-----
From http://forum.xda-developers.com/showpost.php?p=23384703&postcount=2110
Thanks for the feedback. I do appreciate it, but by the looks of your post, you didn't see my detailed description of why the frequencies are set to what they are now. I was more interested in what people are actually experiencing as far as performance and battery in real world tests and conditions. From your post, the information that I believe is relevant is that you think your phone runs fine at 192Mhz. I'll accept that for what it is (a data point) but I already know from experience that you are in the minority here. As soon as I released v1.1 with the 192Mhz min frequency, I immediately started getting inundated with people complaining that battery life was much worse, and the phone lagged more on occasion. Then when I brought the frequency back up to 384Mhz, the vast majority reported "thank you, battery life is back to phenomenal and lag is gone". Well, that's what got me on my quest to actually find and measure the needed frequencies.
No, neither HTC nor Qualcomm set these devices up to work as well as they actually can. They simply do not have the resources and the time. These things are rushed to market and updates are no better: they are designed to "make the device work". That's about it! So when I actually started testing these things, I found that 192Mhz was far too slow to make this phone work without lag. 384 fixed the problem but when I looked into it further, 486 worked even better, and without extra battery drain. I didn't pull these numbers out of a hat nor did I increase them for bragging rights. They are measured values of what the phone actually needs in order to keep up! I spent many hours testing different states, what frequencies are needed when the CPU wakes up when the screen is off, etc. Simply put, 192 doesn't cut it (not even close) and 384 doesn't quite cut it either. When you crunch the numbers, you find that the phone actually needed 432Mhz while running one core with the screen off and 540Mhz while running dual core with the screen on. Lowering those numbers caused the CPU to jump relentlessly between the min/max numbers and when you look at the time and crunch the numbers, it was always shooting for those figures: 432 with screen off and 540 with screen on!
In other words, if you crank it down to even 384Mhz while the screen is on and IDLING (not even running any games or other apps: what you called "waiting for input"), it'll hop up to 1188 much more frequently and in fact, crunch the numbers for the amount of time it spent at 384 and 1188 and get an average and you'll find that on average, the CPU was using about 540Mhz of power with the screen on and about 432Mhz with the screen off. I will add a disclaimer here that yours may be slightly different (up or down one notch in the time table) from the 432-off/540-on numbers, but I did test a variety of configurations as I said in my description when I released 2.0 and 432/540 minimum frequencies were the good middle ground that worked well under all setups from clean install to heavily loaded down. Part of the need for higher minimum frequencies is because with the screen off, there's an initial "crunch" when the CPU is awakened and that often requires more CPU power than when a longer task is being performed. And with the screen on, it is always doing more than just waiting for input from you! There's a lot more going on in there than you think. Even bumping the min screen-on frequency from 384 to 486Mhz caused a dozen posts saying "Wow, lag is completely gone" and "apps seem to open before I even touch the screen". This is not placebo. This is noticeable and even measurable in benchmarks! No, the phone CANNOT and will not instantly crank up to 1188 Mhz from 192 (or 384). I've proven this many times. It doesn't work that way.
You have to remember that the decision to ramp up to 1188 is made at 192Mhz! It only measures CPU load 20 times per second. And it will never be able to ramp up to 1188 in 1/20 second! The reason is that by the time the service reports a high CPU load (high enough to trip the up-frequency), you've already experienced 1/20 second lag minimum. At that point, it takes at least one more cycle to actually increase CPU frequency at which point you've experienced at least 1/10 second of lag. That is almost always noticeable. To complicate matters, if you look at the code for the daemon, you'll notice that it is a "nice" process which means other high priority system processes can actually "steal" time from the daemon and that can actually greatly increase the amount of time it takes for the daemon to actually raise CPU frequency once it notices the phone is lagging. By that time, you've already noticed additional wait to open an app, a "hiccup" while scrolling, etc. The reality is, your phone can lag at 192Mhz (or 384) for several 1/20 second cycles before the CPU is actually ramped up to the full 1188 and THAT is what causes the lag.
So long story short (I know, too late now) I have to discount all your questioning about whether or not I got the numbers right because your assumptions about the numbers are quite frankly all dead wrong! Your scale of the numbers in your car analogy doesn't fit either. I actually do performance tuning on (among other setups) Hemis. The analogy is more like: set your idle to 192 RPM and see if you can keep it running. If it does, it'll be loping like hell and then when you hit the gas, what happens? It bogs. It's because the system wasn't ready for the load. Set it to 540RPM and see how much better it responds. That's a better analogy here.
So I'm really interested in actual results more than people pulling their own numbers out of a hat and saying "these make more sense to me". A lot of testing went into the CPU tweaks in this ROM and I'm aware of "theories" about how people think 192 might be better or 384 is better. Been there done that. That was the boardroom stage... kinda where HTC and Qualcomm left it. We're already out on the track racing and making adjustments.
Oh, and the frequencies are no more "locked" now than they've ever been. I intentionally set up the init.post_boot.sh so that they can easily be changed. So if you want to run yours at the laggier, less efficient 192Mhz, the choice is yours. Just follow Lrod's instructions above. I was going to post those but he did a fine job.
Edit: I also notice you said at one point "So I don't understand why the decision was made in v2.0 to raise the minimum frequencies to 432mhz for core0 and 540mhz for core1.". CPU0 is never run at a different minimum frequency than CPU1. The numbers for min/max are:
- Screen off: CPU0 = 432/648, CPU1 = offline
- Screen on: CPU0 = 540/1188, CPU1 = 540/1188
And again, these numbers came from actual measurements and number crunching. Didn't matter what you used for minimum frequency: you could set it to 192 and run the phone for a day, and then set it to 384 and run the phone for a day. What you'd find is that regardless of what you picked, the CPU was always "hunting" for about 432Mhz with the screen off and about 540Mhz with the screen on. And with screen on, I mean the screen forced on but the phone doing nothing but idling on the home screen. The CPU was doing nothing but typical background tasks with an occasional email or SMS message coming in and maybe a stray screen scrolling thrown in infrequently.
Mike