OverClocking 101

[furbearingmammal]

Performance doesn't scale with speed in a 1:1 value no matter the processor anyway.

 

[AtrusNex]

Thanks for the help you two.

 

[furbearingmammal]

Always a pleasure.

 

[Skull One]

I honestly think that the conservative governor doesn't get enough love.

I've been running my system at 156250/70/40/0/5 on conservative and have actually noticed less jerkiness as the CPU up-clocks and much cooler temps. As low as 65° F at rest and rarely gets above 85° F under average use with my
P3Droid LV 125-1000 kernel.

Currently not running any profiles as I'd like to learn more about the inner workings of the processor when it sleeps first.

On another note does anybody either have a good source for information on how the Omap processor reacts during sleep, or would mind giving some explanation into it further?

I'm wondering does the processor actually dip below the minimum clock speed in sleep like going into a low power state on full size computers or does it just act like it's not running anything and sit at the lowest frequency slot it's allowed to? It'd be a great help if someone could enlighten me in my quest for battery life utopia!

Most of what you have asked has been answered save one major part.

The OMAP3430 doesn't have the ability to underclock itself. It has to be set by the software that is currently in control of it. The Android OS is a linux branch with some very nifty tricks added and enhanced. The most notable is the ability for the OS to go in to a pseudo-proper standby mode. Pre Froyo 2.2, the sleep/standby mode had some serious issue with the kernels being built from the ASOP source. The issues were fixed in the core part of the OS, thankfully, which is what now allows us to use 125Mhz as a sleep/standby speed. Without getting to technical the basics are this: Each app registers itself on the stack for a particular function it needs access to and once registered it can go to sleep until that function call wakes it up. Now for games this is pretty useless except for needing access to the call state. Because that is what actually pauses the game properly when you get a call. Now some apps have the permission flag needed to keep a phone from going into 100% sleep mode. You basically are running those at your own risk when it comes to battery life. Now for apps that don't set that flag they will set others. Examples are Handcent hooking into the SMS system, Weather Bug hooking into the timer system for periodic updates, GMail hooking into the 3G system for push messages, and Setting Profiles which can hook into the WiFi change state to determine if you are at home or the office based on what WiFi SSID that are detectable. If you really want a good look at everything that is hooked to which events in your phone buy "Autostarts" in the Market. I use that app to control what loads on startup as well as which apps actually attach to which events.

Now with all that in mind the OS still can not go into 100% pause/sleep/standby. But what it does do is get it down to the point that 125Mhz, I still think it can go slower and I am debating if I will ask for a kernel to be built to prove my theory, and do all housekeeping the OS needs without sacrificing the ability to wake up properly when a hardware event happens.

 

[AtrusNex]

wow! Nice post, very interesting. That certainly would be an interesting experiment to try an underclock it further. I imagine most hardware events would snap it out of sleep anyway allowing the governor to move it to a higher frequency slot, correct?

Sorry to bug you more, but this brings up a new question. Which flag does the SetCPU profiles get set under then, or is it a passive activity monitor and the changes themselves are event flags? If the former is the case there could be a possibility of minimizing cpu access in sleep by disable profiles right?

 

[Skull One]

wow! Nice post, very interesting. That certainly would be an interesting experiment to try an underclock it further. I imagine most hardware events would snap it out of sleep anyway allowing the governor to move it to a higher frequency slot, correct?

Sorry to bug you more, but this brings up a new question. Which flag does the SetCPU profiles get set under then, or is it a passive activity monitor and the changes themselves are event flags? If the former is the case there could be a possibility of minimizing cpu access in sleep by disable profiles right?

LOL!

You just listed another test I have been wanting to run.

Which profile conditions keep the phone from going into sleep mode since the only major permission it needs is "Prevent phone from sleeping".

Hopefully I will get around to testing that soon

 

[pulptastic]

I just found your thread...Great work!!!
Let me know if there is a donate link, I feel your efforts deserve a lil
sum sumthin!

I've got a few questions I haven't seen answered or asked...

-Moto Droid (1) Bugless Beast v0.4
-I am using Chevy's 7 slot ULV 125-1200 kernel
-I have setCPU 2.0.2 paid version and it does not see the kernel?

When I hit detect I get 250mhz min, and 1200max.
Scaling has to be set from Performance to Ondemand in order
to access the advanced tab...

Once I've done this and change the *sampling* from the default
320000 to 250000 it won't stick. I can change all other values
except for the sampling???


Is something wrong?
I hit apply, set on boot, and it doesn't reflect the change.

Even when I keep the ondemand scaling option running instead of
Performance I can't get 250000 to stay.

That side effect of not being able to make advanced settings stick is a combo of certain versions of SuperUser and SetCPU. I reverted back to SuperUser 2.1 while using SetCPU 2.0.2 to solve the issue. I have not tried the latest version of SuperUser 2.3.1 to see if it works properly now.

As for SetCPU not picking up the min and max frequencies properly, I have seen it be either a voltage issue or a ROM/Kernel combo issue. The easiest thing to try of course is using a Low Voltage kernel to see if that clears it up. If that doesn't work, then you may have to try other kernels from other makers.

I appreciate the thought, but no donations need. I started this project as a way to learn the ins and outs of the Android OS. It just wouldn't seem right to make a dime off a open source project of this nature.

**********
While catching up on all the threads, found this. [APP] Superuser 2.3.3 - Now on the Market [2010-08-15] - xda-developers

Latest version of SuperUser that says it should fix SetCPU issues.

**********
I can now confirm that the latest version of SuperUser works with SetCPU 2.0.2 properly during boot.

I can still replicate this with Superuser 2.3.1 and SetCPU 2.0.2

I change the advanced settings to 50000 75 0 0, click apply and it seems to stick. However, when I shut the screen off and back on, it always returns to 300000 75 0 0. I noticed that when I shut the screen off while viewing the advanced settings, the values and options change:

Edit: confirmed exact same behavior with new Superuser app 2.3.3

Edit #2: I found a workaround. I set my sleep scaling from conservative to on demand and the advanced settings now persist! Also, it looks like each scaling setting has it's own advanced settings and SetCPU apparently has some problems remembering states when it switches between them.

 

[samsonite801]

Is there such thing as having too many Profiles? This wouldn't slow it down too much would it?

My global min/max clock mHz is: 250min to 1000max

Here are my custom Profiles:

Temp---------122 deg F : 250min to 250max
(CPU Temp---122 deg F : 250min to 250max)
Temp---------111 deg F : 250min to 400max
(CPU Temp---111 deg F : 250min to 400max)
Temp---------108 deg F : 250min to 600max
(CPU Temp---108 deg F : 250min to 600max)
Screen off------------------250min to 600max
Chg/AC---------------------250min to 600max
Chg/USB--------------------250min to 700max
Batt<21%------------------250min to 400max
Batt<31%------------------250min to 600max
Temp---------104 deg F : 250min to 700max
(CPU Temp---104 deg F : 250min to 700max)
Temp---------100 deg F : 250min to 850max
(CPU Temp---100 deg F : 250min to 850max)

I've only been experimenting with having the CPU temp profiles in there (in tandem with the batt temp profiles) to decide if it is even necessary or beneficial to have them as well (as long as it doesn't hit performance to have them there as well.

I have found that when I watch a lot of Flash movies, the phone starts to heat up pretty good, so with this set of temp profiles, I can control the temps fairly well, since it is a 'proactive' plan. But I was just concerned with whether or not having so many profiles can have some negative effect (i.e. performance, etc).

And just in case it matters, my advanced settings are: 32000,93,0,0
.
.

 

[Skull One]

I can still replicate this with Superuser 2.3.1 and SetCPU 2.0.2

I change the advanced settings to 50000 75 0 0, click apply and it seems to stick. However, when I shut the screen off and back on, it always returns to 300000 75 0 0. I noticed that when I shut the screen off while viewing the advanced settings, the values and options change:

Edit: confirmed exact same behavior with new Superuser app 2.3.3

Edit #2: I found a workaround. I set my sleep scaling from conservative to on demand and the advanced settings now persist! Also, it looks like each scaling setting has it's own advanced settings and SetCPU apparently has some problems remembering states when it switches between them.

You are actually dealing with a whole new issue that is a design flaw in SetCPU. The developer doesn't keep separate settings for each type of Governor. So as you switch between them, their min/max settings and difference between what is needed corrupts each other. Which is one of the reasons I stick with OnDemand across all profiles.

 

[Skull One]

Is there such thing as having too many Profiles? This wouldn't slow it down too much would it?

My global min/max clock mHz is: 250min to 1000max

Here are my custom Profiles:

Temp---------122 deg F : 250min to 250max
(CPU Temp---122 deg F : 250min to 250max)
Temp---------111 deg F : 250min to 400max
(CPU Temp---111 deg F : 250min to 400max)
Temp---------108 deg F : 250min to 600max
(CPU Temp---108 deg F : 250min to 600max)
Screen off------------------250min to 600max
Chg/AC---------------------250min to 600max
Chg/USB--------------------250min to 700max
Batt<21%------------------250min to 400max
Batt<31%------------------250min to 600max
Temp---------104 deg F : 250min to 700max
(CPU Temp---104 deg F : 250min to 700max)
Temp---------100 deg F : 250min to 850max
(CPU Temp---100 deg F : 250min to 850max)

I've only been experimenting with having the CPU temp profiles in there (in tandem with the batt temp profiles) to decide if it is even necessary or beneficial to have them as well (as long as it doesn't hit performance to have them there as well.

I have found that when I watch a lot of Flash movies, the phone starts to heat up pretty good, so with this set of temp profiles, I can control the temps fairly well, since it is a 'proactive' plan. But I was just concerned with whether or not having so many profiles can have some negative effect (i.e. performance, etc).

And just in case it matters, my advanced settings are: 32000,93,0,0
.
.

I have never seen the code for SetCPU, but I am willing to guess that each profile takes less than 1 or 2 milliseconds to test at most. And I doubt the developer tests profiles every 120 seconds, if that, when in passive mode. So I would say you are probably good until the 50 or 60 profiles range. If I ever get truly bored, I may test it one day for grins and giggles

 

[TuBitMittens]

One thing I've actually been wondering concerning o'clocking and battery life if perhaps the consistency with the profiles changing the speed to often may actually affect battery drain? What I mean is like if I have to temp profiles and one might say for the phone to clock up to 600mhz at maybe 36.5c and then another one tells the phone to only clock up to say, 500mhz at around 39.0c or whatever, considering those increments are not terribly far apart..idk I hope my question made some sense. Lol I'm really not the expert here obviously.
Sent from my Droid using Tapatalk

 

[jhom]

I am new to overclocking and decided to first try the stock Froyo kernel. I am curious if anyone has any experience and optimized settings for the stock kernel.

Update: I didn't like how the stock kernel played with SetCPU. So, I've moved over to P3.

 

[drpaul07]

So i know lower voltages help to conserve battery life..do voltages change temperatures of battery and cpu? For example, would a MV kernel running at 1.1GHz have a different cpu temp than a LV kernel running at 1.1GHz?

 

[furbearingmammal]

So i know lower voltages help to conserve battery life..do voltages change temperatures of battery and cpu? For example, would a MV kernel running at 1.1GHz have a different cpu temp than a LV kernel running at 1.1GHz?

Yes, but only at first and/or in the short term.

Less juice to the CPU means less juice creating resistance (and less juice being pulled from the battery), which = less heat (including being produced by the battery as the electrons flow out), but run it long enough and you still reach the point where thermal dissipation cannot overcome even the lowered thermal generation. From a physical standpoint there may be a difference, but in the practical standpoint we have to live with it'll still be the same. It'll just take longer to get there and hopefully the task calling that much CPU power will be over with before it gets there.

Of course, if I'm totally wrong, someone tell me so I can correct myself, but that's my understanding.

 

[Skull One]

One thing I've actually been wondering concerning o'clocking and battery life if perhaps the consistency with the profiles changing the speed to often may actually affect battery drain? What I mean is like if I have to temp profiles and one might say for the phone to clock up to 600mhz at maybe 36.5c and then another one tells the phone to only clock up to say, 500mhz at around 39.0c or whatever, considering those increments are not terribly far apart..idk I hope my question made some sense. Lol I'm really not the expert here obviously.
Sent from my Droid using Tapatalk

Lets level the playing field and say both 500 and 600 Mhz are set to the same voltage level. Now we need to know the cause of the heat. The single largest production of heat, in a phone, is friction. As the electrons fly thru the transistors, diodes, resistors and capacitors, there are physical resistances that have to be over come. With that in mind lets setup a simple model.

One electron has to go thru one transistor in a continuous loop. Now this electron, regardless of its voltage or amperage, is flying thru the transistor at 500,000,000 times a second (500Mhz) for the sake of this model. As you can see that is a lot of times to go thru the transistor. Which means as the electron makes contact with the transistor it hits the resistance. The friction of overcoming the resistance is now felt as heat in the transistor. Now at 600 Mhz, that means the same thing happens 100,000,000 times more a second than 500Mhz. As you can see from this simple model, there is going to be more heat as you raise the frequency regardless of the voltage.

Now you see why we slow the phone down as the heat level builds. But this also shows what it means to battery life. As you slow the CPU down it uses less power because there are less electrons flowing thru the circuit at any given second. Less electrons that have to be charged to be used by the circuitry.

So by underclocking you are actually accomplishing two goals