OverClocking 101

[Skull One]

OverClocking 101

This thread will be my attempt at helping you develop a very good foundation of knowledge for overclocking the Motorola Droid.

I am finding out that the second post is applicable to all Android based phones regardless of manufacturer. So if you want you can skip to the SetCPU section.

For those of you who have read some of my early work on this, I suggest a reread. I decided to get a tad more technically correct with this write up because I found most of you really wanted to know the complete ins and outs not just a sugar coated version that made sense.

So let's start with some ground rules.
1) Facts are king.
2) Opinions will be noted as opinions.
3) Subjective will be explained based on observations.
4) Examples will be simplified but I will post a link so you may research the full details when justified.

What is overclocking?

Overclocking is the practice of changing the frequency of a device so that it runs faster than intended.

That definition, while factual, is subjective when it comes to the Motorola Droid. The reason is simple. The stock Droid is clocked at 550Mhz. The OMAP3430 (The processor of the Droid) is built by the manufacturer to be clocked at 600Mhz. Who asked for it to be underclocked? Texas Instruments? Motorola? Verizon? Does it really matter? The best answer is no. Because we, as the owner of the phone, get to decide the amount of risk that is taken when we pick a kernel and clock speed.

So now we should cover the other side of the coin. What is underclocking?

Underclocking is the practice of changing the frequency of a device so that it runs slower than intended.

Once again a factual definition but also subjective when it comes to the Droid. The reason: the Droid underclocks itself, when it can, to extend battery life.

So what are the Pros and Cons of overclocking?
Pro: Faster Droid.
Con: Battery usage.

Could I list a whole slew of Pro's and Con's? Yes. But those two are, in my opinion, the two that matter for the purpose of this thread.

Let's review what makes a Droid overclockable.

Yield. It is a very interesting word in the world of electronics. Time to find out why. Each batch of chips and batteries made for a device are manufactured to achieve a certain yield. So let's do a simple run down on chip manufacturing. And let's start with the shiny metal plate called the wafer.

1) A wafer is X number of inches across.
2) The number of chips per wafer is based on the size of both the chip and wafer.

So a 12" wafer with .5" chip would have roughly 370 chips on it.

3) A chemical, photographical, electrical and mechanical set of processes etch/build the chips on the wafer.
4) The number of chips that meet the minimum requirement set by the manufacture is called the YIELD.

So if 100 chips are made on a wafer and only 80 of them pass quality control the yield is subjectively 80%. So if the next wafer has 85 chips passing QC, then that wafers yield is 85%. But the combined yield is now 82.5% ((80+85)/2). Once they have done a minimum run of wafers, anywhere from 10 to 1000, they calculate the yield across all wafers from that run as the base yield.

See Semiconductor device fabrication - Wikipedia, the free encyclopedia if you want the nitty gritty on what I just condensed.

So how does that affect what we are trying to do when it comes to overclocking? Simple, to get the highest yield possible they do their very best to make each chip on a wafer perfect. In that search for perfection it allows us to overclock. But the subjective part is, which chip did you get in your Droid? The flawless one that allows you to over clock to 1300Mhz or more? The good one that allows you to over clock to 1000Mhz? Or the marginal one that meets yield requirement and only allows you to over clock to 600Mhz? That is what makes overclocking very subjective. You won't know what the chip can do till you try everything.

Batteries are the next issue we need to discuss because heat is their enemy. If you overclock at a high enough frequency you are going to use more battery and generate more heat.

Subjective/Opinion: You should try to keep the battery between 32F (0c) - 120F (48.9c)
Subjective/Fact: As you approach cross 120F on the battery you are actually causing the battery to discharge at a faster rate. Even if the CPU isn't putting a large demand on it.

Getting your Droid's ambient temperature (the whole droid) above 130F for any length of time should be considered a bad idea. The battery itself is the issue. When a lithium-ion battery reaches around 140F, it can enter the state of "self heating" or more commonly referred to as "thermal runaway". Reach this state enough times or holding it there too long and the battery will become unusable as the individual cells of the battery break down from thermal overload.

The second issue is that the battery is the single largest surface area that can generate heat in the Droid. This heat is radiated in all directions. While the Droids back door is designed as a heat sink, the mother board on the opposite side is not. That heat will soak into the motherboard and it will eventually cause issues. Most notably Force Closes (Applications failure), erratic behaviors and finally failure of the Droid. The OMAP3430 CPU and support chips also generate heat. If both occur, you can actually heat soak the Droid to the point of failure by causing components to fail do to stress. What kind of stress? Physical. Remember grade school science? Heat something it expands and when cooled it contracts. Let's look at where that happens in the Droid.

Each material used in making a device has a different expansion and contraction rate based on their heating and cooling cycle. So, the mother board will expand and contract at a different rate than the solder. The solder will expand and contract a different rate than the leg of the chip. The leg of the chip will expand and contract at a different rate than the packaging and wafer it is connected to. As you heat soak the surface mount component they will go through this cycle from several times a day to sometimes several times a minute. As this happens, stress is being applied to the solder joints and the wafer in the chip. This stress will eventually cause a crack. If the crack breaks a connection, the chip fails and you buy a new Droid. The question of course is simple. How many times does this have to happen before guaranteed failure of either the solder point or of the chip itself? That is an answer that NO ONE can give with absolute certainty. We can only calculate a MTBF (Mean Time Between Failure). BTW, don't bother looking for the MTBF of the Droid. They have never stated it. Because the amount of testing to figure it out simply costs too much to be useful. But now you see why the Droid was underclocked to 550Mhz. The odds of it failing are greatly reduced.

The last part of overclocking we need to cover before moving on is Voltage.
CPUs are comprised of several types of components. Transistors, resistors, capacitors and diodes are the primary building blocks. With that in mind, electricity follows through each and is effected by their characteristics. So let's put that info to practical use.
A CPU needs electrons to work. Those electrons must meet two conditions to be useful to the CPU. A potential, known as Voltage and current (the number of electrons with a potential) known as Amperage.

As you raise the CPU frequency or Mhz, you are increasing the speed at which the electrons flow thru the circuit. This increase in speed results in more heat being generated by the CPU. Simply put the electrons are creating friction as they flow through the components of the CPU. The faster they go, the more electrons that pass a single point and the more friction or heat is generated at that point. Since there are millions of points in a CPU you can see why there can be a lot of heat. If you want a refresher course on friction and heat rub your hands together slowly. Not much heat. Now rub faster but maintain the same amount of pressure. Even more heat. Now apply more pressure at the faster speed. Even more heat. That added pressure is similar to what voltage does to a circuit. So let's see why different voltages exist for kernels.

Each CPU is technically unique. Some work better than others. Some work so well they only need low amounts of voltage to change the state of a transistor in a CPU. The issue is every transistor can be technically different on what voltage level is needed to switch states. And since there are millions of transistors in a CPU you have to find a voltage that will change the state of all of them properly. Now let's add in to the mix the frequency we want to run at. As you raise the frequency the electrons spend less time at each transistor. That time may not be enough for the transistor to switch state properly. Raise the voltage though and you will eventually have enough potential to cause the transistor to switch state. And there is where the chase to overclocking a Droid happens. Having the right amount of Voltage at the proper Frequency to make the CPU operate as expected.

So how do we know which frequency and voltage to pick? Testing. You should test each voltage and frequency over a period of time. So here are the signs you need to look for to know if what you are testing isn't working for you. And remember the higher the clock rate or Mhz the more likely a failure will occur.

Force Closes on things that used to work properly on stock voltage and frequency (IE how your Droid came).
Data corruption.
Unexplained anomalies.

The good news is, you shouldn't cause any damage to the hardware if you avoid generating too much heat, but your data on the other hand may become corrupted. Of course that is why we do nandroid backups before we do any new testing. I know the next question already. Where do I start?

My opinion is, medium voltage (stock) and 800 Mhz. Monitor your heat and programs. If nothing bad happens after an hour of testing, jump to 1000 Mhz. Then 1100 and finally 1200. As you get closer to 1200, you will see the heat in your Droid rise. Pay close attention to that. Now once you know your top speed, then start all over with low voltage and run the same tests. If you are lucky your Droid will operate the same way as it did with medium voltage. Should it work, you will end up using less battery to do the same job. And remember; my subjective opinion is you don't want to see the battery go over 120F or the CPU going over 135F for any length of time. The reason for this cautious limits reminder? Lithium-Ion batteries can reach thermal run-away at 140F. The CPU can handle up to 170F but the mother board holding it and the components around it are only rated to around 154F. So staying below both will help you stay happy with a working Droid.


Next up: SetCPU and how to use every feature to achieve your goal.

[Skull One]

If you are running Version 1.x (prior to 2.0 release in June of 2010) please click this link: SetCPU 1.x

SetCPU 2.0 released June 2010.

What does SetCPU do for you? In a nut shell it writes/sets files used by the Android OS to clock the OMAP3430. But that's not all it does. It also monitors if your Droid is charging, the percentage of remaining battery, the temperature of the battery and (if the kernel provides it) the temperature of the CPU. For the most part SetCPU is simply in an idle state waiting for a change in one of those conditions. When one of those conditions change, SetCPU can change how your Droid is being overclocked automatically. The benefits can be as simple as better battery life as your Droid's battery depletes, to warning you that your are overheating and throttle back the CPU before any damage can be done to your Droid.

With the new overhaul of the User Interface, lets look at how things are now done. But first, how I did my testing and current setup. As some of you may know Team Chaos retired. I wish all of their members the very best in what ever projects they tackle next. They gave me a very stable ROM to base my work on and for that I am very grateful. Going forward I have decided, after some research, to base my continued work on the following ROM builder:

ROM: Froyo (Android OS 2.2) built from the Google source code.
Builder: cvpcs - http://sapphire.cvpcs.org/wiki/
Version: Kernels, Get Your Kernels, RED HOT Kernels! - Sapphire - 0.7.0
Kernel: http://p3designs.info/kernels/

I would like to thank cvpcs and P3Droid for their hard work. It makes my testing and research much easier.



They say a picture is worth a thousand words. I believe the person was exaggerating, but lets find out.

The first thing you will notice about the SetCPU 2.0 is the tab layout. Clean and to the point. Love it.



As you can see the MAIN profile is still the first thing that is displayed.

The Max and Min Slider are now the center of attention along with the scaling selection and Set on Boot. So lets pull it apart.

Max: xxxxMhz with a slider. That setting is the highest Mhz the CPU will be allowed to run at.
Min: xxxxMhz with a slider. That setting is the lowest Mhz the CPU will be allowed to run at.

The Max and Min allowable selections will be based on what over clocking kernel you choose to use.
The steps on each slider will be based on the number of slots the kernel provides.

Set on Boot: The Min and Max slider will be used to set the CPU speeds once SetCPU has loaded during the startup of the phone if checked.

So we know what Max, Min and Set on Boot does, let's explore what Scaling does.

Since I am using P3Droids 1000 Mhz kernel, which is the default for the Sapphire 0.7.0 ROM, I have the following selections:
Conservative, ondemand, powersave, userspace and performance.

Let's explore what each does.

Conservative:
This setting does exactly what it says. Conserve. And it does it by conserving the battery where it can. It accomplishes this thru throttling the CPU to the Min frequency as much as possible. As the Android OS' CPU usage increases it throttles towards max but at a slower pace than "on demand" due to only checking every 1/4 of a second.

Ondemand:
This ramp the CPU, using the Advanced Settings Tab, from Min to Max based on system load.

Powersave:
It clocks the CPU to the Min setting.

Userspace: (subjective/opinion)
I don't have factual info on this one, even the author of SetCPU doesn't explain it. I have observed behavior with some kernels where it idles at the middle slot. In others it idles at the Max slot. Any insight to this one would be appreciated.

Performance:
It clocks the CPU to the Max setting.


Let's explore what the Advanced Setting does to facilitate ondemand and conservative.




Sampling Rate: How often the OS checks the Droids work load.
Up Threshold: At what point the max throttling kicks in based on system load.
Ignore Nice: Tells the OS to examine each process running and to see if ramping up the clock can be deferred.
Powersave Bias: How much overclocking above the Min setting is allowed to happen which helps conserve battery.


What does all of that mean? You have the power to custom tailor how fast your battery will drain vs. how snappy applications are going to respond/run.


Now the PROs and CONs of each setting: (Subjective observation)
Sampling Rate: This setting 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 of my findings under Froyo 2.2.

Sampling rates larger than 250000 (four times a second) seem to be pointless based on my testing. 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.

But what it does affect is how snappy thing happens. At 32000, the Android OS will almost instantly ramp from what ever clock rate it is at (save for already being at Max) and go to Max. The flip side to this? Under 2.2 it seems to ramp back down just as fast. Which means if you are running very well behaved apps, you will idle at minimum until something actually needs a faster CPU. It will jump to max, get the work done and then jump back down to min. I really like how the Android OS does this.

Up Threshold: This is NOT a direct measurement of the CPU usage but more of how well the CPU is doing servicing all applications. I am still exploring the full implications of this setting. But the Pro is lower percentage = faster ramp up. Con, quicker battery drain due to spending more time at Max.

Ignore Nice Load: Nice is all about how well a process surrenders use of the CPU to other processes. The current version of SetCPU and Froyo 2.2 STILL need testing.

Powersave Bias: 0 = don't save battery, 1000 = save battery at all costs.

How do we sum this up? We test (Sampling Rate) the Android OS work load (Up Threshold) and see how far towards Max we are allowed to go and stay there (Powersave Bias). Yes I know I left out Ignore Nice load, but you will see why in the next post .

Now for the where the most changes were made. I have commented several times to other forum members that this should be the way Profiles are done. And the Dev of SetCPU got it 90% right. But the slider for the priority is the only part I feel was done wrong. It should have been a drag and drop reorder system. It would be cleaner and not make you have to go constantly readjusting a slider to get things in the order you need. But with that complaint out the way lets have some fun with the new design!



Now this gets the job done. So lets add one.




First we need to pick the condition that triggers the profile.




Charging/Full - This is where the Droid is on the USB/Wall Charger and the battery is either charging or full.
Charging AC/Full - This is where the Droid is on the Wall Charger and the battery is either charging or full.
Charging USB/Full - This is where the Droid is on a USB port and the battery is either charging or full.

Why three different conditions that seem the same? When plugged into the wall, the Droid charges roughly at 10% per 12 minutes. But when hooked to USB it takes much longer (I am going to time it) because USB can only supply so much current unlike the wall charger that can provide max current. That max current though is a blessing and curse. If you have the Droid doing lots of work while wall charging and the CPU is clocked at 1000Mhz or above, you can actually overheat the battery because it is charging so rapidly. Where as USB charging doesn't have that issue as much.

Screen Off - This works in Froyo 2.2 properly Thanks Google!
Battery < - If the battery is below this setting, it activates this profile.
Temp > - If the battery temperature is above this setting, it activates this profile.
CPU Temp > - If the CPU temperature is above this setting, it activates this profile. NOTE: Your kernel MUST support CPU temp reading for this to work.

I am so glad the SetCPU developer decided to finally break Battery Temp and CPU Temp as two different triggers. The Motorola Droid needs this ability.

After you select the condition, set the min, max, governor and priority and you are done. The possibilities and custom tailoring with this design is unlimited. Just remember this simple rule:

They are executed from the top down.

If you look at my simple profile it works like this:
If the Droid is in Screen Off/Standby, it is clocked to 125/400.
If the Battery Temp is > than 44.9C, it is clocked to 125/500.
If the Battery is charging (regardless of USB or Wall), it is clocked to 125/800.
If the Battery is < 21%, it is clocked to 125/400.
If the Battery is < 41%, it is clocked to 125/600.

Now some of you are asking "WHY are you making Screen Off/Standby the first profile? Shouldn't it be a temperature check?" The answer is pretty straight forward, if the temp is high it clocks to 125/500. Well my Screen off is set to 125/400. Since that is actually slower, it is better to have it go first so the temp cools off even faster. And that is the true beauty of the new SetCPU and profile design. You can setup any condition you see fit to use. Once again, Droid does.

Next up: The Ondemand and Advanced Settings. Real world testing and observations to understand their impacts.

[Skull One]

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
Benchmark: Linkpack
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:
Min: 125
Max: 1000
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.

1000Mhz = 15.969 MFLOPS
 900MHZ = 14.397 MFLOPS
 800MHZ = 12.858 MFLOPS
 600MHZ =  9.684 MFLOPS
 500MHZ =  8.080 MFLOPS

Lets see if this scales properly. Scale is MFLOPS per 1Mhz.

1000Mhz = .01596 MFLOPS
 900MHZ = .01599 MFLOPS
 800MHZ = .01607 MFLOPS
 600MHZ = .01614 MFLOPS
 500MHZ = .01616 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.

Up Threshold.

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.

  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

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.


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.

   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

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?

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.

0 = 15.969 MFLOPS = 994Mhz
1 =  2.356 MFLOPS = 146Mhz

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.



Sampling Rate.

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.

  50000 = 15.969 = 994Mhz
 100000 = 15.969 = 994Mhz
 200000 = 15.969 = 994Mhz
 400000 = 15.969 = 994Mhz
 800000 = 15.969 = 994Mhz
1600000 = 15.969 = 994Mhz

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.

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.

[Skull One]

Now for the subjective and opinionated part of this article.

Sleep/Standby. I really wish I knew how this worked. Because I have set my min and max speeds to 1000mhz and the phone still wakes up sluggish and shows a load average above 80. I could understand if I set the min and max to 125mhz but at 1000mhz the Droid should never fall behind.

Sleep/Standby is fixed in Froyo 2.2!



Charging. Yes you can set a profile to 125/1000 but it usually picks something around 550/600 to idle but does ramp to max. No clue why yet.



Is 125Mhz bad? That is such a loaded question. A stock droid will actually clock down that low to help with battery life. The problem is with custom roms. If you only have a few programs running in background while the phone is in standby/sleep life is good. But if you are like me and you have 7 or 8 programs loaded at all time and it allows the CPU to fall behind on the work load. What is the side effect of this? Text messages and phone calls might be missed. The CPU is so busy trying to wake up and recover from the backed up work load that it actually misses the signal from the hardware that woke it up in the first place. I have put many hours in to testing this issue. At one point I got it down to only missing 1% of the incoming calls and texts with wonderful battery life. But I had to turn off a lot of apps to do it. The Droid simply wasn't as useful. So I now use 250Mhz as the low end to avoid missing calls and texts. But even at that speed I still notice the CPU getting bogged down during sleep mode. How do I notice it? When it wakes up to play a custom ringtone. If the work load is caught up, they play correctly. If the work load is way behind, it plays the default ringtone and sometimes I have to wait a second before I can slide the answer call button. One day I will find the magic bullet on this.

Froyo 2.2 fixed this issues as well! 125Mhz works so far based on all my testing.



5 vs 7 slots. I have tried them both. I prefer 7 over 5 because it allows me to use the three power < % profiles more effectively. Is one better than the other? To be blunt, no clue. I think voltage is the bigger concern over slots.

[Skull One]

RESERVED FOR RESULTS OF TESTS based on feedback and questions.

Why you might need SetCPU

Bugless Beast 1.1 and the discovery

Froyo 2.2

Froyo 2.2 Part 2

[Shelooga]

i feel less noobish now. thanks skull. looking forward to reading part 3 too

[marcogiudice]

skull what advance setting numbers should we use now? 62500,80,0,0 like before or has that changed

[Skull One]

i feel less noobish now. thanks skull. looking forward to reading part 3 too

Don't! I spent well over 40 hours to figure out a lot of what I have written so far. And I am still learning. Part 3 is going to be all about the Linpack benchmark and how it can be used to show what the Advanced settings can do for you. Then once I am done with that, I move on to Bugless Beast and Peter's work to see what happens when you don't use SetCPU for an overclocked ROM set. That testing is going to be a lot of fun.

[Corinacakes]

oh most awesome one...it's so good to see you around again! As usual, incredible writeup!

[Skull One]

skull what advance setting numbers should we use now? 62500,80,0,0 like before or has that changed

Funny you should ask that. After being on that setting for well over a month, I switched May 22nd to 62500, 70, 0, 0 just to see if I could perceive a difference in daily use. What it didn't affect was my battery life. I still only need to charge once a day. And I really don't perceive a big difference in my standard use. BUT I did track a difference. When the Droid was coming out of a prolonged sleep/standby it seemed to catch up just a tad quicker when I watched the load average. I am trying to formulate a testing method to make sure what I am observing is actually a faster result.