SetCPU Real World Testing. And as a special treat for all of us, the testing is under Froyo 2.2.
First I would like to thank P3Droid and bgill55. Without their hard work my testing would not have been possible. P3Droid of course helped bring Froyo to us to begin with and provided me with the kernels I will be using for these tests. bgill55 of Team Chaos provided the final ROM that was installed for these tests. It was tweaked, zip aligned, and a whole mess of things I don't begin to claim to understand yet.
First lets layout the tools:
Android OS: Froyo 2.2 tweaked by bgill55 of Team Chaos
Overclocking: SetCPU version 1.5.4
Kernel: P3Droid 1.0Ghz 7 Slot Low Voltage 125/300/500/600/800/900/1000
Now for the baseline:
CPU Governor: On Demand
Advanced: 50000, 75, 0, 0
So lets find out what that baseline does. I hit Run Benchmark 20 times and wrote down the highest number.
Lets see if this scales properly. Scale is MFLOPS per 1Mhz.
1000Mhz = 15.969 MFLOPS
900MHZ = 14.397 MFLOPS
800MHZ = 12.858 MFLOPS
600MHZ = 9.684 MFLOPS
500MHZ = 8.080 MFLOPS
Not bad but not perfect. The difference between 500Mhz and 1000Mhz is 1.2%. In testing of this nature, that is a actually a pretty big difference. But since this is more for getting a feel for what is going on how SetCPU effects the OS, lets take the average of .01606 and use that to calculate the predicted frequency based on adjustments. That equates to 994Mhz on the top end and 503Mhz on the low end. I think we can all live with that.
1000Mhz = .01596 MFLOPS
900MHZ = .01599 MFLOPS
800MHZ = .01607 MFLOPS
600MHZ = .01614 MFLOPS
500MHZ = .01616 MFLOPS
So where to start? Lets play with Up Threshold and leave the rest of the baseline alone. This one is going to be fun and you will see why in a bit.
Yes, you read that correctly on 100%. The Android OS can't detect when the Up Threshold hits 100% so it always clocks at 125 Mhz because it can never step up. The second thing you probably noticed was 40% to 80% gave the same result which matches the predicted 994 Mhz top end baseline we set earlier. But notice 20%? It is really close to the 1000Mhz actual setting. The reason behind that is what makes Up Threshold so powerful. The OS can hit 20% so quick it jumps from 125Mhz to 10000Mhz in one 50000 microsecond Sampling Rate. And that is where the power lies in this setting, at what point do you want to start throttling up towards max? We will be revisiting this setting later in combo with Sampling Rate. Because that is where we will see the greatest effects.
0% = Can't be tested. It is an illegal value.
20% = 16.016 MFLOPS = 997 Mhz
40% = 15.969 MFLOPS = 994 Mhz
60% = 15.969 MFLOPS = 994 Mhz
80% = 15.969 MFLOPS = 944 Mhz
100% = 1.976 MFLOPS = 123 Mhz
Power Save Bias.
Just as a reminder. SetCPU is only changing native settings of the Android OS. Once you hit apply to any setting changes, the OS takes over and then SetCPU waits for one if its triggered events to change to the profile you specified.
Power Save Bias. The name of this tweak is interesting. Technically what it does is adjust how the OS ramps up and down the slots of the kernel. But the net result is where it gets its name. By trying to stay at a lower frequency, the CPU uses less power.
So lets change the Bias in 100 increments using the base setting from earlier.
The P3Droid's kernel I am using has the following frequencies for the 7 slots 125Mhz, 300Mhz, 500Mhz, 600Mhz, 800Mhz, 900Mhz and 1000Mhz. And yet at a Power Save Bias of 600 I am clocking in at 364Mhz. That isn't one of our slots. How is the Linkpack reporting that? The OS is toggling between 125Mhz and 500Mhz with the setting at 600. If you want to see that in real time download "System Panel" from the market and in the top right of the display it shows the CPU Clock. Now scroll the list of programs running and you will see the CPU Clock bounce between 125Mhz, 300Mhz and 500Mhz. While Linpack is running the OS clocks between 300Mhz and 500Mhz with the bias leaning towards 300Mhz. And that is how we got the average of 364Mhz. The OS in real time is weighing everything that is going on and trying to meet your request of saving power. Can you really ask any more from an OS?
0 = 15.969 = 994Mhz
100 = 14.591 = 908Mhz
200 = 12.797 = 796Mhz
300 = 10.698 = 666Mhz
400 = 9.667 = 601Mhz
500 = 8.086 = 503Mhz
600 = 5.846 = 364Mhz
700 = 4.791 = 298Mhz
800 = 2.758 = 171Mhz
900 = 1.981 = 123Mhz
1000 = 1.963 = 122Mhz
So lets have some fun. Because one of the implications of this setting is the ability to create an average frequency that doesn't exist in any of the real slots. How about 700Mhz. Lets see what it takes. We know the Power Save Bias has to be between 200 and 300 right off the bat. And since we know .01606 MFLOPS equals 1Mhz the math looks like this: 700Mhz * .01606 = 11.242 MFLOPS. That's our target number. So lets use 250 and see where that puts the MLOPS. 10.968 MFLOPS or 682Mhz. Close! 225 gives us 11.003 MFLOPS or 685MHZ. Even closer. 212 gives us 11.254 MFLOPS or 700Mhz. SUCCESS! Now this is a 7 slot kernel. After I finish with the other two settings, I will revisit Power Save Bias with a 5 slot kernel just so we can explore what can be done under that condition.
Ignore Nice Load.
SetCPU says 0 = false, which in English means don't ignore nice load and 1 = true which means ignore nice load.
What can we take away from this? The results don't make sense based on what the setting says and what I know about nice under the *nix OS. Time to open up System Panel and see what the CPU is actually doing. It is toggling between 125Mhz and 1000Mhz. I even see it occasionally hitting some of the other slots. SetCPU information show load avg to be normal. Browser seems to be acting normally. Looks like the meaning I learned and what is being done today is different. I am going to guess, the application is setting a nice flag that the OS is now respecting and when set to 1, Linpack is time slicing every chance it gets instead of running in one continuous shot. More research is required.
0 = 15.969 MFLOPS = 994Mhz
1 = 2.356 MFLOPS = 146Mhz
Lets get straight to it. Because no one is going to like the results. Baseline setting with a doubling of Sampling Rate on each step.
I know what you are asking. What the heck?!?! That setting isn't changing jack! Well of course it isn't. But that is the fault of the test used not of the setting and Android OS. Remember what part of the baseline is? 20 runs of Linpack and find the best number. Well the CPU is loaded up by the fourth run which crosses the Up Threshold of 75% which in turns sets the CPU to the 1000Mhz slot.
50000 = 15.969 = 994Mhz
100000 = 15.969 = 994Mhz
200000 = 15.969 = 994Mhz
400000 = 15.969 = 994Mhz
800000 = 15.969 = 994Mhz
1600000 = 15.969 = 994Mhz
So lets work thru some theoretical tests:
Idea #1: Base setting but only run Linkpack once after doubling the Sampling Rate.
I had a bad feeling about this idea right off the bat. So I put in 1000000, waited 15 seconds and ran Linkpack once. I got 16.063. Anyone realize the significance of that number? It equates to 1000Mhz right on the money. The reason for that is, the clock rate is locked theoretically for 1 second between changes based on Up Threshold. The test only needs 1/3 of that time to run in. So it got 100% of the clock during its entire run.
Idea #2: Change up threshold to 95%, double sampling rate and test.
Yeah, that idea fails too. See the above.
Idea #3: Drop back 10 and punt. Where is my 2.1 data?
Upon reviewing the data collected under 2.1 I found the same exact issue. No help there.
So, what is the setting actually good for? I believe I can give a fairly accurate answer for that. This setting allows us to choose how many times a second we sample the Up Threshold and step the CPU both up and down the slots in the kernel. At 50000 microseconds we are testing 20 times a second. With a Up Threshold of 75%, that means anything that needs CPU time is going to be at full speed in probably 1 to 3 samples. But here is the kicker. Lets examine the other side of the coin. Just as fast as we ramp up, the same process applies to slowing back down. And we have already established, the slower the CPU is running, the longer the battery life. So in effect we can use Sampling Rate to save battery by allowing the system to throttle back faster. The testing for this is subjective at best. I plan to run 50000, 75, 0, 0 along with 100000, 75, 0, 0 and 250000, 75, 0, 0 over the next week. And track my battery usage. My instincts tell me I won't get enough data difference, but it isn't going to kill me to test.
Remember early on I said Sampling Rate and Up Threshold is where we will see the greatest effects? Now you see why. They work in concert. You sample the OS to see if the Up Threshold is met and the you change the clock rate up and down inside of the confines of the power saving bias.
Or in layman terms: Me using 50000, 75, 0, 0 could very well equal your 30000, 90, 0, 70 for power usage. And since every Droid is different, it makes testing on your Droid the only real benchmark.
Something amazing happened by accident!
While finishing up the Sampling Rate section, I forgot to reset back to 50000. I was still at 1000000 when a call came in. Guess what failed? My custom ringtone! And I could not be happier. Because now I have a real world test. Here is the break down. Call comes in and raises a hardware interrupt to the Android OS. That in turns causes a software event to be called. Each application tied to that event gets run. How fast they respond is the issue. Because I had the Sampling Rate only checking the Up Threshold every 1 second, the system couldn't look up the custom ringtone in the time allotted before it has to play something. So this weekend I can start there and work my way back until I find the number that doesn't fail!
Sampling rates continued
Sampling rate is about how many times a second the OS checks things. If you want to check once a second you would enter 1000000. To check four times a second you would enter 250000. Twenty times a second is 50000. So the more you want to sample the lower the number has to be. With that in mind, here is some new findings under Froyo 2.2.
Sampling rates larger than 250000 (four times a second) seem to be pointless based on my testing this week. At 333333 (3 times a second) custom ringtone playback starts to fail. After testing 50000, 100000, 1500000, 250000 and 333333, I can't really seem to find an affect on battery life worth noting.
So it seems some where between 30000 (33ish times a second) and 100000 (10 times a second), with an up threshold of 75 to 90 and power bias between 0 and 100 seems to be the safe bet for daily use.
And here is a reminder on the rule:
Sampling rate tells the OS how many times a second to test the Up Threshold to see if you need to ramp up or down and the power bias tells the CPU how far up it should go towards max.
5 Slot testing still needs to be done.