OverClocking 101

[samsonite801]

When the command is entered in terminal, nothing happens except a new command line. Is this what should happen or did I make a mistake?

You should be able to browse to /data/local.prop and see the new toggle command in there if it took.

Let's talk about this over in the launcherpro.com forum because I already have a topic running over there. Full instructions on doing this mod are there. I just don't want to further dillute this thread with posts that shouldn't be here.

Now back to overclocking... I took out the Slayher kernel I had been running with the interactive CPU governor and put back on my old jdlfg kernel which is built for Lithium Mod ROM and set it back to 'On Demand' in SetCPU and I already notice that while power-using, the battery is already lasting longer, and it acts a lot snappier again (menus scroll smoother like before). For some reason I had thought it may have been faster with the interactive one but after moving back to this old kernel it had become apparent to me without a shadow of a doubt that the jdlfg kernel which is built lighter with less modules runs faster and smoother.
.
.

[furbearingmammal]

Interactive isn't ready for primetime. Nuff said. Thanks for testing and proving it!

[projekt128]

When the command is entered in terminal, nothing happens except a new command line. Is this what should happen or did I make a mistake?

You should be able to browse to /data/local.prop and see the new toggle command in there if it took.

Let's talk about this over in the launcherpro.com forum because I already have a topic running over there. Full instructions on doing this mod are there. I just don't want to further dillute this thread with posts that shouldn't be here.

Now back to overclocking... I took out the Slayher kernel I had been running with the interactive CPU governor and put back on my old jdlfg kernel which is built for Lithium Mod ROM and set it back to 'On Demand' in SetCPU and I already notice that while power-using, the battery is already lasting longer, and it acts a lot snappier again (menus scroll smoother like before). For some reason I had thought it may have been faster with the interactive one but after moving back to this old kernel it had become apparent to me without a shadow of a doubt that the jdlfg kernel which is built lighter with less modules runs faster and smoother.
.
.

No dilution intended.. LAST COMMENT (I swear) .. The toggle in data/local.prop being......... ro.HOME_APP_ADJ=1 correct?

[Skull One]

No hurry at all. I also notice that when using apps such as Pandora, the CPU does get quite warm.. I'm sure there's no stopping this, but perhaps that can be taken into consideration. SS 4.7 seems like a great ROM, running with the ULV 1.25 kernel.. I've been hearing many good things regarding LFY, UltimateDroid, and BB. Just wondering your thoughts. Thanks again for taking the time.

If you are getting a warm CPU while on a ULV Kernel, there may be something wrong. Please try a Low Voltage Kernel and see if Pandora still exhibits this behavior. I want to rule out a Voltage issue before addressing a speed issue.

1.25 ulv Pandora is running consistently from at 30-34ºC I guess my sense of touch was off. But something silly like Robo Defense game seems to run a bit hotter.. Could be just me though. Seems like a game would be the most demanding task.

Actually that isn't always true. If you are in a weak 3G area while running Pandora and it is struggling to buffer the song, it is eating a lot of battery and CPU time trying to make sure the song is playing back in "good quality".

Currently games on the Android OS suffer from bad programming practices. They assume, and I have to admit rather correctly, that the phone is stock and can handle being run at 100%. They do this to get the max FPS (Frames Per Second) out of the display. This helps with collision detection and a few other items like AI (Artificial Intelligence) and user input. The problem is when we overclock, instead of the game loop running 20 to 30 times per second, we now are running it 40 to 90 times a second. That amount of screen drawing and CPU usage is going to heat the phone up very quickly. One day Android games will be written with FPS locks (IE the display only needs to be update 25 times a second) and the phone can be idle waiting for the next loop to execute. This would help tremendously with battery and heat issues. But I don't see that happening any time soon.

[samsonite801]

This is why I made a bunch of preventative profiles in SetCPU for this reason. So if the temp is below 100°f then it gets the full 1000mHz but if it goes higher than a mere 100°f, it will slow down to 850mHz, and if it hits 104°f then it slows to 700mHz, and if it hits 108°f then it slows to 600mHz, and if it hits 111°f then it slows to 400mHz, and finally, if it hits 122°f then it slows to 250mHz. This is my safety mechanism I must use since I notice a lot of apps do this very thing of heating the phone up to the point of meltdown if I don't stop it. But with these settings, it never goes past 108°f at all anymore.

One other thing I did just days ago was to install 'Droid Wall' which is a cool firewall frontend UI made to control iptables so you can easily turn off any unnecessary apps from accessing the internet. It calms down all the unnecessary network chatter (you know, from all those wallpapers that need 'Full Internet Access'). With that firewall frontend, combined with iptables, you can turn off all that crap from either WiFi, 3g, or both. Then you will see battery life get better too since the chatter is gone, and because those apps probably give up trying to connect after they realize that they can't connect to the internet. Please note that Droid Wall is a frontend UI, so if you want it to work, you need to install iptables v1.4.7 (older versions will error out) which can be found in the link from comment 15 here:

code.google.com/p/droidwall/issues/detail?id=27#c17

...just get that zip and extract the iptables bin from /system/bin in that zip, and copy it to your /system/bin folder. You must obviously be rooted for this to work as well. On mine, in order for the firewall to correctly block apps and function, I had to toggle the list to 'blacklist when item checked' mode, instead of 'whitelist when item checked' mode. Once I did that, this app worked nicely to cool down the WiFi and 3g radios, and I'm sure battery life will improve as well. I've also noticed that the phone doesn't seem to be as 'busy' when coming out of standby either.
.
.

[samsonite801]

No dilution intended.. LAST COMMENT (I swear) .. The toggle in data/local.prop being......... ro.HOME_APP_ADJ=1 correct?

Yes, it should be: ro.HOME_APP_ADJ=1

[projekt128]

If you are getting a warm CPU while on a ULV Kernel, there may be something wrong. Please try a Low Voltage Kernel and see if Pandora still exhibits this behavior. I want to rule out a Voltage issue before addressing a speed issue.

1.25 ulv Pandora is running consistently from at 30-34ºC I guess my sense of touch was off. But something silly like Robo Defense game seems to run a bit hotter.. Could be just me though. Seems like a game would be the most demanding task.

Actually that isn't always true. If you are in a weak 3G area while running Pandora and it is struggling to buffer the song, it is eating a lot of battery and CPU time trying to make sure the song is playing back in "good quality".

Currently games on the Android OS suffer from bad programming practices. They assume, and I have to admit rather correctly, that the phone is stock and can handle being run at 100%. They do this to get the max FPS (Frames Per Second) out of the display. This helps with collision detection and a few other items like AI (Artificial Intelligence) and user input. The problem is when we overclock, instead of the game loop running 20 to 30 times per second, we now are running it 40 to 90 times a second. That amount of screen drawing and CPU usage is going to heat the phone up very quickly. One day Android games will be written with FPS locks (IE the display only needs to be update 25 times a second) and the phone can be idle waiting for the next loop to execute. This would help tremendously with battery and heat issues. But I don't see that happening any time soon.

Makes perfect sense. There should be fixed fps settings as there are in PC games. Since we are overclocked, do you have any suggestions for best rom/kernel and setcpu profile settings for best managing these demanding tasks. I don't worry so much about the games as I do with Pandora, as I use that most everyday in car.

[huskerkate]

hey, that script/toggle in your sig is outstanding - thanks!!!! made a huge difference in the lag problems i was experiencing!

quick question - is that something that needs to be reentered after a soft reboot??
sorry for the noob question - but thanks again!!

When the command is entered in terminal, nothing happens except a new command line. Is this what should happen or did I make a mistake?

You should be able to browse to /data/local.prop and see the new toggle command in there if it took.

Let's talk about this over in the launcherpro.com forum because I already have a topic running over there. Full instructions on doing this mod are there. I just don't want to further dillute this thread with posts that shouldn't be here.

Now back to overclocking... I took out the Slayher kernel I had been running with the interactive CPU governor and put back on my old jdlfg kernel which is built for Lithium Mod ROM and set it back to 'On Demand' in SetCPU and I already notice that while power-using, the battery is already lasting longer, and it acts a lot snappier again (menus scroll smoother like before). For some reason I had thought it may have been faster with the interactive one but after moving back to this old kernel it had become apparent to me without a shadow of a doubt that the jdlfg kernel which is built lighter with less modules runs faster and smoother.
.
.

[samsonite801]

hey, that script/toggle in your sig is outstanding - thanks!!!! made a huge difference in the lag problems i was experiencing!

quick question - is that something that needs to be reentered after a soft reboot??
sorry for the noob question - but thanks again!!

NOPE. The setting DOES persist after reboot. The initial echo command entered in creates a file called local.prop (if it doesn't already exist - in which case it would just append to the local.prop file) which the toggle stays in there and each time you reboot, the system will parse that line out and load that setting in.
.
.

[xmguy]

I have my Droid overclocked with one Chevy's 1.0 Ghz kernels (see signature)

I have loads of battery and cpu/battery temp lockouts.

low # is MIN high # is MAX (i.e. 250Mhz is my MIN, 800Mhz is my MAX)

Battery at 40% drops to 250Mhz to 800Mhz
Battery at 30% drops to 250MHz to 700Mhz
Battery at 20% drops to 250Mhz to 550Mhz
Battery at 11% drops to 250Mhz to 400Mhz
Battery at 5% drops to 250Mhz to 250Mhz

Screen off is 250Mhz to 400Mhz

Charging on AC or Full is 250Mhz to 400Mhz

CPU Overhead lockout at 250Mhz to 800Mhz at 125F

Battery Overheat lockout at 250Mhz to 800Mhz at 110F

NORMAL runs at 250Mhz to 1.0Ghz