OverClocking 101

[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?

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

Dude, you're running a task killer. That's bad with a capital B A D.

http://www.droidforums.net/forum/droid-applications/65483-task-killers-answer-google-developers.html

And enough hijack. Sorry, Skull!

 

[Skull One]

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

Dude, you're running a task killer. That's bad with a capital B A D.

http://www.droidforums.net/forum/droid-applications/65483-task-killers-answer-google-developers.html

And enough hijack. Sorry, Skull!

No worries. Rescue Squad members got to the front of the line in my book. So please feel free to chime in at any time.

Plus this threads very intention is to help with battery life and performance. So your answer is right on target for what we both want to help others with.

:icon_ banana:

 

[chefb]

I have a droid x would you suggest these same guidelines for me(a far as overclocking).

 

[Skull One]

I have a droid x would you suggest these same guidelines for me(a far as overclocking).

I haven't played with overclocking the Droid X so with that in mind....

The theory is exactly the same. This is because the code that is compiled for each device is based on one source code. Granted there are some tweaks here and there to the user interface but the ground level code should be nearly identical as far as Governors and the Kernel is concerned.

Hopefully a Rescue Squad reader can chime in (Hint Hint :icon_ banana with any specifics.

 

[lonndoggie]

[EDIT: Should've quoted, I guess, but this is in reference to Skull's extended explanation of how governors work...]

Yow! Thanks for the tutorial.

I have to appologize for a certain dense-ness about what threshold values mean: Of course, lower up threshold == go up sooner and higher down threshold == go down sooner. :wacko: <-- me

I found the code for the conservitive governor: https://github.com/slayher/android_kernel_omap/blob/master/drivers/cpufreq/cpufreq_conservative.c

Basically, it computes "load" as the wall time minus the idle time, and checks the thresholds against this load.

The comments at the start of dbs_check_cpu (the function that performs the checks and calls for the change, if any) says that going up always goes to the max frequency, while going down is by steps. The code doesn't back this up, however, it appear both move by steps.

There is one other interesting wrinkle: The down check subtracts 10 from the downthreshold as specified--so if you say 50%, it'll actually use 40% as the limit.

And in the process of looking at the code, and writing this, I had an "aha!" moment, when your "why 50% down threshold isn't so bad" statement made sense: That basically during any intense activity we'll be well above that high down threshold; it's only when the CPU truly has some spare time (e.g, when it's drawn the screen for some "static" app and is waiting for the user to do something) that it'll ever drop below 50% long enough to be seen by the governor--but it'll see it as soon as possible with the higher threshold.

And yes, I do love the inner workings--especially when given something like a governor with a bunch of values I can change, with very little explanation of exactly what will happen when I do, and why I might want to chose certain values! About 30 years ago, I worked on a real time OS for a military processor, so I have some (ancient) background in this kinda stuff.

Interesting that they default to 80% up and 20% down. Seems not so conservative.

Thanks again!

LDog

 

[Skull One]

Yow! Thanks for the tutorial.

I have to appologize for a certain dense-ness about what threshold values mean: Of course, lower up threshold == go up sooner and higher down threshold == go down sooner. :wacko: <-- me

I found the code for the conservitive governor: https://github.com/slayher/android_kernel_omap/blob/master/drivers/cpufreq/cpufreq_conservative.c

Basically, it computes "load" as the wall time minus the idle time, and checks the thresholds against this load.

The comments at the start of dbs_check_cpu (the function that performs the checks and calls for the change, if any) says that going up always goes to the max frequency, while going down is by steps. The code doesn't back this up, however, it appear both move by steps.

There is one other interesting wrinkle: The down check subtracts 10 from the downthreshold as specified--so if you say 50%, it'll actually use 40% as the limit.

And in the process of looking at the code, and writing this, I had an "aha!" moment, when your "why 50% down threshold isn't so bad" statement made sense: That basically during any intense activity we'll be well above that high down threshold; it's only when the CPU truly has some spare time (e.g, when it's drawn the screen for some "static" app and is waiting for the user to do something) that it'll ever drop below 50% long enough to be seen by the governor--but it'll see it as soon as possible with the higher threshold.

And yes, I do love the inner workings--especially when given something like a governor with a bunch of values I can change, with very little explanation of exactly what will happen when I do, and why I might want to chose certain values! About 30 years ago, I worked on a real time OS for a military processor, so I have some (ancient) background in this kinda stuff.

Interesting that they default to 80% up and 20% down. Seems not so conservative.

Thanks again!

LDog

First and foremost this entire process is about learning. I am learning from you and everyone else just as much as you all learn from my ramblings

Now I must admit, didn't even bother to look up the current code used in Froyo. Did my write up based on theory, what little I remembered from the 2.1 code base (when I did my initial research) as well as my research into desktop/sever linux sources and what I observed during testing with the inputs involved in that testing. Wonder how much that will haunt me now

I just confirmed that your source link is the AOSP version. Now giving it a quick read....

I am actually impressed with the new code. It is much more streamlined than the kernel code I have read. They don't use buckets for the trend analysis like desktop linux. Which saves major time in code execution. Also this code has the ability to scan multiple CPUs. But I disagree with how they are calculating load but that is more of a "preference" not a "they are doing it wrong". I really like that they split the sampling rate code out of the decision to change slots code and made one call the other. This now allows the governor to truly sleep and then collect the load value in one call versus the old way of collecting the data over time and then deciding if the sampling rate had passed (this would be a battery waster). I am actually glad I didn't read this code first. It allowed me to see the major differences from the old way to the new more tuned for battery life way. And now you see why I learn just as much as anyone else from this discussion.

Now for my LOL moment and to address your wrinkle comment.

	/*
	 * The optimal frequency is the frequency that is the lowest that
	 * can support the current CPU usage without triggering the up
	 * policy. To be safe, we focus 10 points under the threshold.
	 */
	if (load < (dbs_tuners_ins.down_threshold - 10))

This is Rule #3 being observed There are some things you just can't get away from.

Reading the Froyo code base may have given me insight to why the time_in_state data is so skewed from the actual run time as well as why Conservative was able to sleep more than OnDemand. Hopefully this weekend I can find the time do some of my 8 hour tests/data captures to confirm my suspicions.

 

[moset]

No task killer. Well, system panel can but I seldom use that function. Mostly to monitor. I'm gonna try conservative governor again. It's hard to say for sure but it seems my overheating is worse with conservative than with on demand. Seems it would improve.
I have CPU temp profile set at 50 with alarm. Of will hit that on about 2 min of flash video. I have it set to drop to 400 at that temp. I'm running main profile at 250 min and 900 Max. It has hit 50° on a call with nothing else running. Pretty concerned I'll burn something. Thinking about going back the stock but I'm not sure that will help.

Sent from my Droid using DroidForums App

 

[furbearingmammal]

moset;

Just having it running puts a big whack on the processor, thereby the battery, and heat levels. Did you read that link I sent?

 

[moset]

Oh yah thanks Skull. I've learned a lot and appreciate your sharing your work AND knowledge.

Sent from my Droid using DroidForums App

 

[moset]

moset;

Just having it running puts a big whack on the processor, thereby the battery, and heat levels. Did you read that link I sent?

Yes the same info in System Panel help file. If System Panel reports CPU use accuracy it uses very little except when actually on like displayed. I have shut it down and have not noticed any difference in heating or battery. The only time I kill apps is when something looks wacky. Maybe kill all about 3 times in several days. I don't think it has an auto kill function.

Sent from my Droid using DroidForums App

 

[moset]

System panel monitor off phone idle for an hour conservative governor same advanced settings as Skulls test settings, Max 900 min 250. During a 20 min phone call SETCPU CPU temp profile kicked on. Signal now at 3 bars, pretty normal signal. Any ideas? I dropped Max CPU setting to 600 to test.

Sent from my Droid using DroidForums App

 

[lonndoggie]

First and foremost this entire process is about learning. I am learning from you and everyone else just as much as you all learn from my ramblings

The forum is WORKING! Glad I can contribute some light, less heat.

This is Rule #3 being observed There are some things you just can't get away from.

And why I set my low threshold on the low side, so as to not need to ramp back up immediately (the same reason they put in their comment).

To paraphrase Catch-22,

"That's some rule, that Rule #3!"
"It's the best there is!"

Ldog

 

[aggiechase37]

Hey Skull! Glad to see you're finally coming around on the whole conservative thing!!! Any more updates? Conservative your daily driver yet???

 

[dolfanpete]

i have a rooted phone, set for 1250 MHz. but my max (slider) is maxed out at 600 MHz, and min is at 250 MHz....set to performnance on boot. how can i change it so that the max truly goes to 1200 MHz? is there a setting i need to go to, to make is so?

how do i set the max slider to the 1250 MHz it is supposed to be at?

 

[jeffe65]

I'm confused - which isn't hard to do - but what part of the phone is "set" at 1250MHz? Did you install a new kernel after rooting?

The other possibility is that SetCPU isn't being recognized as a root app. Make sure you install it as a widget on one of your home screens, so it picks it up on reboot.