OverClocking 101

[Laurence5905]

Well, I finally took the plunge and rooted my Droid 1 so I could take advantage of SetCPU and maybe get some more performance out of this thing...

I had the stock Froyo 2.2 that I received from the Verizon OTA update a couple months ago... Never rooted this thing before, never really wanted to, but after that 2.2 update, things were getting a bit sluggish... I figured, worst-case scenario, I brick this Droid and wind up buying a Droid 2 for full-price (because I've still got 11 months in my current 2-year Verizon contract -- the one I signed on Nov. 6, 2009 when I bought this original Droid on release-day). Honestly, I thought it wouldn't be a terrible thing if I did brick it and was forced to buy a new Droid 2 -- I was getting pretty disgusted with the sluggish performance of this Droid 1 after the OTA 2.2 update.

Now that I've done it, all I can say is, "WOW!!!" I should've done this MONTHS ago!!! It's like having a brand-new phone for the $1.99 price of SetCPU. AMAZING!!!

And it was SO SIMPLE! I followed the instructions here, and in about 30 minutes I was rooted, and still running the same 2.2 Froyo that I had been before -- absolutely nothing on the phone changed at all, except now I had root access... It was precisely what I wanted to happen.

I purchased and downloaded SetCPU, set the sliders to 125MHz min and 800MHz max... (Can't get it any faster without a custom kernel.) Set up a few profiles as recommended by this thread's O.P. (I copied his profiles almost exactly, leaving out the one at Batt < 41%), set the advanced settings to 100000,75,0,75 -- of course I also selected Set On Boot for everything I could. Rebooted just for good measure (mostly to see if the settings would be maintained thru a reboot). It all looks great so far!

Played one of my favorite games (RoboDefense) and on the higher levels it was getting pretty sluggish before -- now, it's super smooth. And the phone didn't get any hotter than it did before overclocking, which totally blew me away! I think it's because the CPU is ramping down to 125MHz so quickly, when the game is between robot-waves. When I finished that game, I immediately checked the CPU temp -- 104-degrees F. Absolutely normal after playing that game -- perhaps even a bit cooler? I've seen it hit 106 or even 108 after a full level on that game.

Tried the web-browser; went to a page that I know is loaded with Flash-based advertisements (of course I have Flash 10.1 on my Droid! Take THAT you iPhone weenies!) Before the overclocking, pages with lots of Flash ads on them were quite slow to load -- now, it's super smooth! Really nice!

I honestly don't know why I didn't do this months ago -- I was so nervous about bricking my phone... But the instructions here were so EASY. It all went so smoothly, and now I'm absolutely loving my Droid again. I can wait 'till Motorola and Verizon get together and release a 4G-capable Droid (Droid 3? Droid 4? Droid 4G?), or until the end of my current contract, whichever is later.

Thanks a bunch, guys, for all your posts here that made this process so easy!

 

[hrdnhvy]

Skull One...how do u get your email set to check at specific intervals?

 

[moset]

Skull One...how do u get your email set to check at specific intervals?

Not Skull but may be ably to help. If I understand correctly Gmail does not check for new mail but rather the server sends new mail when it arrives (push). I use AOL mail. You can open email, select menu then account settings then Email check frequency. If you select never it only checks when you open the email app. Hope this helps.

Sent from my Droid using DroidForums App

 

[Skull One]

Skull One...how do u get your email set to check at specific intervals?

Not Skull but may be ably to help. If I understand correctly Gmail does not check for new mail but rather the server sends new mail when it arrives (push). I use AOL mail. You can open email, select menu then account settings then Email check frequency. If you select never it only checks when you open the email app. Hope this helps.

Sent from my Droid using DroidForums App

Moset is very correct. Gmail is a push based mail system similar to SMS (texting).

The Google Email app however uses the standard pull method that every email client has used for the last 24 or so years. So to change how often that application polls, you need to open email, click on the account's inbox and then hit the menu button. Click on Account Settings, then click on Email check frequency. You should then be able to select never, 5, 10, 15, 30 and 60 minutes.

 

[hrdnhvy]

thanks...kewl...i never even knew a person could change that about gmail....now im really curious as to what the heck mine is set at...lol....i would assume that less frequent might increase ones battery life ?

 

[moset]

Not on Gmail. Other email like AOL. Gmail uses push and does not have to check. There are no check frequency settings for Gmail.

Sent from my Droid using DroidForums App

 

[Bilgediver]

Well, I finally took the plunge and rooted my Droid 1 so I could take advantage of SetCPU and maybe get some more performance out of this thing...

I had the stock Froyo 2.2 that I received from the Verizon OTA update a couple months ago... Never rooted this thing before, never really wanted to, but after that 2.2 update, things were getting a bit sluggish... I figured, worst-case scenario, I brick this Droid and wind up buying a Droid 2 for full-price (because I've still got 11 months in my current 2-year Verizon contract -- the one I signed on Nov. 6, 2009 when I bought this original Droid on release-day). Honestly, I thought it wouldn't be a terrible thing if I did brick it and was forced to buy a new Droid 2 -- I was getting pretty disgusted with the sluggish performance of this Droid 1 after the OTA 2.2 update.

Now that I've done it, all I can say is, "WOW!!!" I should've done this MONTHS ago!!! It's like having a brand-new phone for the $1.99 price of SetCPU. AMAZING!!!

And it was SO SIMPLE! I followed the instructions here, and in about 30 minutes I was rooted, and still running the same 2.2 Froyo that I had been before -- absolutely nothing on the phone changed at all, except now I had root access... It was precisely what I wanted to happen.

I purchased and downloaded SetCPU, set the sliders to 125MHz min and 800MHz max... (Can't get it any faster without a custom kernel.) Set up a few profiles as recommended by this thread's O.P. (I copied his profiles almost exactly, leaving out the one at Batt < 41%), set the advanced settings to 100000,75,0,75 -- of course I also selected Set On Boot for everything I could. Rebooted just for good measure (mostly to see if the settings would be maintained thru a reboot). It all looks great so far!

Played one of my favorite games (RoboDefense) and on the higher levels it was getting pretty sluggish before -- now, it's super smooth. And the phone didn't get any hotter than it did before overclocking, which totally blew me away! I think it's because the CPU is ramping down to 125MHz so quickly, when the game is between robot-waves. When I finished that game, I immediately checked the CPU temp -- 104-degrees F. Absolutely normal after playing that game -- perhaps even a bit cooler? I've seen it hit 106 or even 108 after a full level on that game.

Tried the web-browser; went to a page that I know is loaded with Flash-based advertisements (of course I have Flash 10.1 on my Droid! Take THAT you iPhone weenies!) Before the overclocking, pages with lots of Flash ads on them were quite slow to load -- now, it's super smooth! Really nice!

I honestly don't know why I didn't do this months ago -- I was so nervous about bricking my phone... But the instructions here were so EASY. It all went so smoothly, and now I'm absolutely loving my Droid again. I can wait 'till Motorola and Verizon get together and release a 4G-capable Droid (Droid 3? Droid 4? Droid 4G?), or until the end of my current contract, whichever is later.

Thanks a bunch, guys, for all your posts here that made this process so easy!

Howdy, not to be a stickler but are you sure you're looking at CPU Temp?
If all you have is stock, you might just be looking at Battery Temp, not CPU Temp. I believe it can take a custom kernel to be able to pull off the CPU Temp, but anyone please feel free to correct me if I'm wrong.

 

[lonndoggie]

thanks...kewl...i never even knew a person could change that about gmail....now im really curious as to what the heck mine is set at...lol....i would assume that less frequent might increase ones battery life ?

You can't change polling for the Gmail app, but you can change the Google Email app. I haven't tried it, but I'd guess you could use the email app to fetch gmail via imap. Or maybe K-9 could do it, if Google somehow prevents their email app from handling Gmail accounts.

[EDIT] Whoops, didn't see the previous post that also highlighted the difference between the Gmail app and the Google email app. Oh well, hard to miss it now!

 

[hrdnhvy]

Are there any apps that can managae multiple email apps at the same time & allow a person to set the frequency as well....I know lonndoggie mentioned k9? not sure what it is but Im gonna check it out...thanks everyone who replid...

 

[Skull One]

The following data has me a little stumped.

Governor: OnDemand
Advanced: 30000, 85, 0, 0
Runtime: 23 hours 57 minutes
Display time 2 hours 15 minutes

[FONT=Fixedsys]SLOT-Hz  Time-mS   Human Readable
[/FONT][FONT=Fixedsys]1000000   999675    2:46:36.75 
 900000    64839      10:48.36
 800000   220042      36:40.02
 600000   136309      22:43.09
 550000   640053    1:46:40.53  
 400000   711971    1:58:39.71
 125000  4132325   11:28:43.25[/FONT]
[FONT=Fixedsys]------------------------------
[/FONT][FONT=Fixedsys]                   19:20:52.14[/FONT]

Governor: Conservative 
Advanced: 156250, 85, 45, 0, 10
Runtime: 23 hours 7 minutes
Display time 2 hours 48 minutes

[FONT=Fixedsys]SLOT-Hz  Time-mS   Human Readable[/FONT]
[FONT=Fixedsys]1000000   174801      29:08.01
 900000    48207       8:02.07
 800000   120829      20:08.29
 600000    29293       4:52.93
 550000   135605      22:36.05
 400000   561933    1:33:39.33
 125000  2815278    7:49:12.78
[/FONT][FONT=Fixedsys]------------------------------
[/FONT] [FONT=Fixedsys]                  10:47:39.46[/FONT]

Hopefully you have noticed that the Runtime and the Human Readable totals don't match. I knew going in there would be some discrepancy between the two numbers. Mainly because I know the phone does go into a "Sleep/Standby" mode where it tries to use the least amount of battery possible. To the point of no longer updating even it's own internal counters. But never would I have imagined that Conservative would show a difference of 12 hours. I really need to figure out why.

I can make an interesting suppositions from this data and from my observations during the last two weeks.

Conservative really does work at saving battery life.

The biggest difference I noticed from OnDemand was from the time I unplugged when I woke up till when I got home from work. Conservative was always 10% higher, bordering on 20%. So basically when I wasn't using the phone a lot, the phone was able to sleep more and save more battery. If I hadn't abused the phone with Angry Birds during both runs, I believe I would have lasted much longer under Conservative.

Now I have my phone optimized. Between SetCPU with all of my profiles, what apps I actually run as well as how I have used autostarts to keep the phone running very lean I have always been able to make it from wake up to bed time. But with Conservative, I turned off all but 3 profiles (CPU Temp, Battery Temp, Charging). And I was still getting the same 24 hour runs that I got with OnDemand. That has me impressed.


My observations for Advanced Conservative settings.

Sampling Rate: Set it to the lowest number it allows because I didn't notice any real world difference between 156250 and the 300000 I tried.

Up Threshold: 75% to 90% seems like the sweet spot depending how responsive you want the phone. Lower = faster ramp up.

Down Threshold: 45% to 50% really seems to keep the CPU, when not busy, in the lowest slot (IE least battery used) while still leaving the phone snappy. Higher = faster ramp down

Ignore nice: 0 - I have yet to find a reason to change it to 1.

Freq Step: 5 to 10. Anything above 10 seems to cause the governor to flip between 3 to 4 slots instead of just the lower 2 slots. The longer you are in the lower slots the less battery you will use.


I need more testing. I am leaning towards: Sleep/Standby (8 hours), Browser using wifi (2 hours), display on with no use (8 hours), and Backgammon Free running in demo mode (8 hours). I will be using a battery graph app sampling every minute this time around to help me isolate exactly how much battery is being used. And I am going to try and see if System Panel can give me a solid profile of the CPU usage over the testing time frame. I have a bad feeling that the battery graph and System Panel apps running in background will negate Conservatives benefits. But I have to at least try to quantify what I am observing.

 

[lonndoggie]

Interesting findings. I've been fiddling with the up and down thresholds, and right now have up at 75%, down at...ah...20% (hrm...it was at 25% with p3's kernel and wouldn't let me go lower; now I'm trying slayhers, and I can go much lower).

Apparently we have a different understanding of what the down threshold means--per your description, higher percentage == faster ramp down.

I was assuming it meant literally at what CPU usage you should shift down--e.g., when CPU usage drops below your selected level, then it'll ramp down. This seems like a pretty simple way to do things, since CPU usage is a statistic that is always instantly available, and "ramp up when above x%, ramp down when below y%" seems to make intuitive sense.

If my assumption was correct, I chose a low ramp down to try to keep from thrashing--e.g., not drop level until we're less likely to bounce back up.

I know you've dug into the code before--have you looked at this to confirm the meaning of down threshold?

Thanks again for your efforts!

EDIT: I found Slayher's repository on github, and while I couldn't find the actual code, I did find a file called Documentation/cpu-freq/governors.txt, which had this to say about down threshold:

"down_threshold: same as the 'up_threshold' found for the "ondemand"
governor but for the opposite direction. For example when set to its
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased."

So it appears it is as I thought--up and down are brackets--cpu goes higher than up, and frequency is increased; if it goes lower than down, frequency is decreased.

The definition of On Demand also appears to indicate that it simply goes from the low frequency to the high, with no stops inbetween. This is why I like the concept of conservative--if it works well, it should keep you in the sweet spot of cycles needed to get the job at hand done. OTOH, if it doesn't work well, it could thrash horribly.

LDog

 

[moset]

Got a replacement Droid recently and rooted again. I have run Charity, LFY1.9, and now on Chevy 4.9. I have tried several Kernels including Med voltage 800 MHz. I am having trouble with overheating with all of them. I'm using SETCPU with high Temp included on profiles. Any ideas how to keep the temp down. The high Temp occurs randomly, not related to any app.

Sent from my Droid using DroidForums App

 

[furbearingmammal]

Are you running any persistent apps? Are you running low- or ultra-low-voltage kernels? Does your phone act sluggish with the lower-voltage kernels? Are you keeping your minimum speeds at the lowest slow available in SetCPU in every profile? Are you running any of those profiles on interactive or performance?

 

[moset]

Are you running any persistent apps? Are you running low- or ultra-low-voltage kernels? Does your phone act sluggish with the lower-voltage kernels? Are you keeping your minimum speeds at the lowest slow available in SetCPU in every profile? Are you running any of those profiles on interactive or performance?

Not sure about persistant apps otherwise I'm good on all other questions. SetCPU profiles are all good. I've tried all voltage Chevy kernels. Just flashed Slayer 1.1 "temp" kernel and it seems to be running cool so far so good. System Panel doesn't show any Apps to be a problem. A bit sluggish but cool. Will try this a while and see.



Sent from my Droid using DroidForums App

 

[Skull One]

Interesting findings. I've been fiddling with the up and down thresholds, and right now have up at 75%, down at...ah...20% (hrm...it was at 25% with p3's kernel and wouldn't let me go lower; now I'm trying slayhers, and I can go much lower).

Apparently we have a different understanding of what the down threshold means--per your description, higher percentage == faster ramp down.

I was assuming it meant literally at what CPU usage you should shift down--e.g., when CPU usage drops below your selected level, then it'll ramp down. This seems like a pretty simple way to do things, since CPU usage is a statistic that is always instantly available, and "ramp up when above x%, ramp down when below y%" seems to make intuitive sense.

If my assumption was correct, I chose a low ramp down to try to keep from thrashing--e.g., not drop level until we're less likely to bounce back up.

I know you've dug into the code before--have you looked at this to confirm the meaning of down threshold?

Thanks again for your efforts!

EDIT: I found Slayher's repository on github, and while I couldn't find the actual code, I did find a file called Documentation/cpu-freq/governors.txt, which had this to say about down threshold:

"down_threshold: same as the 'up_threshold' found for the "ondemand"
governor but for the opposite direction. For example when set to its
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased."

So it appears it is as I thought--up and down are brackets--cpu goes higher than up, and frequency is increased; if it goes lower than down, frequency is decreased.

The definition of On Demand also appears to indicate that it simply goes from the low frequency to the high, with no stops inbetween. This is why I like the concept of conservative--if it works well, it should keep you in the sweet spot of cycles needed to get the job at hand done. OTOH, if it doesn't work well, it could thrash horribly.

LDog

It never ceases to amaze me how hungry people get when it comes to the inner workings of electronic devices

Now for some rather dry fun LOL. Also your morning edit/addition shows that the creator of the notes that you read is very short sighted on how the overall architecture works.



There are times when I feel it is needed to get very technical and there are times when the general reading audience is better served by me giving the "overall feel" for what something does. When I was writing the original post, I knew that I was partially watering it down. But I felt it was in the best interest because the technical side gets rather sticky.

Your assumption on how the code works is only partially correct and the documents you have read aren't even close to telling the true story of what the code does. So let's lay down the ground work to establish the hows and whys.

First rule: All governors use CPU IDLE time for determining system load.

Of course 1 - CPU IDLE = CPU LOAD but if you forget that rule while reading the code you will spend some time scratching your head on the why the code is written the way it is.

Second Rule: Governors collect IDLE TICKS to help determine "over time" state information.

This means they actually collect two sets of TICKS. One for down trending and one for up trending. There is more stat collecting code in some governors than code that actually changes the frequency

Third Rule: Governors never respond to instant changes in CPU IDLE.

This rule would require a half hour spoken dissertation on latency, rubber-banding and runaway affects, so you will have to take my word on why it is important

With those three rules in mind let's look at the general flow.

1) Collect the ticks that have occurred since the last run cycle.
2) Check trend direction.
3) Store trend to the Down or Up buckets.
4) Check trend buckets against rules.
5) Change CPU Freq Slot based on step 4 results.

Now the magic of course is in step 4. So let's dig a little deeper.

Conservative uses four primary values to decide what to do. Up Threshold %, Down Threshold %, Freq Step % and Sampling Rate.

As you summarized, Down Threshold % is where the Governor decides to start its look at slowing/stepping down the clock. But that isn't the whole story. It does so by looking at the Freq Step % and Sampling Rate as part of that math. So for the downward trend to be considered legit, it has to occur over one full sampling rate. And then it has to apply the Freq Step % to accumulate when it finally steps down one slot out of a possible 7.

Of course the same rule applies to Up Threshold except it is looking for less idle time.

About now you might be wondering "What happens" between your 20% and 75%? Well the Governor is still looking at the trend, sampling rate and Freq Step to see if it can go up or down but now it does it much slower. So in a sense you are idling either slowly up or slowly down. And that is where battery usage can be seriously wasted.

If you set the Down Threshold to 50%, then the Governor is trying to trend down on clock speed at a much faster rate. Yes I can hear the "But I want the phone responsive" or "But it will go from slot 7 (faster) to slot 1 (slower) instantly". Neither statement is even close to the truth.

Let's use programming theory to help explain the real world affects of the code. A program is always in one of two states. Running or Waiting. If it is running, you can assume it is going to be using as much CPU time as the round robin task manager gives it. Waiting can be on any number of things. But the big one that matters is you, the user. Humans are slow. We measure time, realistically, in hundredths of seconds and poorly at that. Computers measure time in millionths of seconds with perfect precision. Needless to say there is a big difference between the two. So let's look at a game as one example of why 50% Down Threshold is not a bad thing.

A game has the following construct if you follow the general paradigm of programming:

WHILE NOT DONE
- Collect Input
- Update Game
- Draw Game

This loop is the basis for probably 85% of every game ever written since the '70s. Now the first thing to note of value is that this loop is always executing something. The reason for that is simple, you capture the user input but don't wait for it. You do this so the Update and Draw can still move the bullet across the screen and check to see if it hits it target. Now in my kernel the lowest sampling rate I can set is 156250 micro seconds. That is .156 seconds or in human terms an event that occurs 6.4 times a second. By now everyone knows that FPS (Frames per Second) is the "Benchmark" for how fast something is drawn. Can you imagine a game running at 6 FPS? You would quit playing at that rate. So a game that outputs at 20 to 30 FPS is happening at .05 seconds or 50 milliseconds to .033 or 33 milliseconds.

Now you see why 50% Down Threshold is not a bad thing. The game is already utilizing the CPU at 3 to 5 time faster than the Down Threshold kicks in at. Now for non-gaming applications this is where the power saving really can kick in. Because the user input is now the stopping point for the code. The CPU is basically idle. Why keep the CPU running at full speed or even mid speed if the user is reading for 1 to 5 seconds. Remember, 1 second is 6.4 sampling rates passing by. If 4 of those sampling rates are at Slot 1 (slowest) speed then you are saving battery life. And yes there is a ramp up for the program. But that ramp up is 156 milliseconds. By the way, about the only thing you can do in that time frame is blink. Everything else you are going to do physically, in that time frame, will take longer.

Hopefully you now have a better understanding of what is going on inside the code.