[Thunderbolt Q&A, Help & Troubleshooting] loonatik78:
OC'ing (update 10/22/11)

For the slightly more advanced noob I present.....

Intro to overclocking!

What is overclocking?

Overclocking is making your CPU/system work at faster clock rates than it was designed/rated for.

How do I overclock?

Glad ya asked! But before I go into the how, I'd like to point out the dangers and why it's beneficial.

Dangers:

The risks involved in OC'ing are probably greater than rooting your device. The worst thing you can do is fry your phone. You might also render your ROM/kernel useless junk on your device that you might need to wipe and restore/reflash. You can also corrupt your SDcard. In the long term, it's possible to reduce your device's lifespan because of the extra heat, which, if high enough, can chemically alter the silicon the transistor gates are made of, thus destroying them. Higher voltages can also induce electron tunneling, a quantum mechanical effect where electrons "tunnel" through the silicon from one circuit trace to another. This can be highly damaging.

Benefits:

The benefits of OC'ing are a significantly faster device. I conjunction with an appropriate governor, you can actually save power while improving performance.

Now, the "how-to":

There are several valuable apps I recommend to add to your OC'ing arsenal. The most popular is SetCPU, which can be obtained for free by XDA members at THIS thread. Instructions for it's use are included in the app as well as the thread. This is a good app to start with for messing around with settings. It will also allow you to select governors and enter governor parameters.

Incredicontrol is another useful tool you'll be interested in. It allows you to alter voltage settings for each clock step.

CPUspy is a very nice little app that provide you with time-in-state readings for every clock step. This will become useful if you're adjusting your governor. It will make evaluating your adjustments fast and easy.

Finally, ScriptFusion by TwistedUmbrella is an excellent long term solution to implementing clock and voltage tweaks. It's a good idea to get that and use it once you know what settings will work.

I can't really give you a step 1, step 2, step 3 guide to this. It's just impossible because every device is different. Instead, I'll try to lay out some method, theory, and reason.

The theory is to push your CPU to run as close to it's limitations as possible before it becomes unstable. Due to the nature of SoC's (system on chip), there are several major components to consider. The core, which executes applications, as well as the GPU, are the most robust components. The least robust are memory, such as caches, and are the first to suffer the effects of overclocking. Be SURE to do a nandroid backup before tweaking settings!!!

The method I tend to use is to first feel out what the CPU is capable of handling at some conservative voltages. Generally, kernel devs set their voltages conservatively because they don't feel like dealing with the heat that comes from some nutjob frying their toy. SetCPU is a good tool for this because you can adjust settings and not have them implemented at boot so if you do crash your device, it will reboot back to stock clock limits. Most devices will be stable at 1.5 GHz at around 1325mv because the S2 Snapdragon is fabbed at the same 45nm scale as the MSM8660 dual-core S3 that powers the EVO 3D at 1.5GHz. If your device isn't stable at this speed, it's quite likely that your CPU isn't a good candidate for OC'ing and only modest increases should be expected.

So, at this point you should use SetCPU to push your clock frequency up until you're either happy with it or it becomes unstable. Don't be afraid of it becoming unstable, it's probably going to happen eventually. All it means is you've found your CPU's limits at that voltage. Your phone will reboot to stock, assuming you did NOT check "apply at boot", and you're back at square one. No harm, no foul.

At this point I recommend installing Incredicontrol or getting comfy with your terminal emulator or ADB shell. Through Incredicontrol, terminal, or ADB, take a look at your voltage table. Incredicontrol provides a nice GUI and is self-explanatory. To view your voltages through ADB shell or terminal, enter the following command:

cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels

Memorize, screen capture, or write these settings down for reference. We KNOW these voltages to be stable up to a point and serve as a good baseline. Most kernels have a maximum voltage they will allow. Modern Ziggy kernels are 1400mv.

For sake of explanation, we'll say your device goes unstable at 1.49GHz at 1250mv on the stock voltage table. At this point, push the voltage up by 25mv for that frequency to 1275. Then, try your 1.49GHz setting again. You can either run a benchmark stress test, use the stress test in SetCPU, or use the device as normal to verify if the new voltage setting is stable. Hopefully it is. If so, increasing the voltages above that frequency by 25mv may make them stable as well. It doesn't sound like a lot, but 25mv does make a difference. Eventually, you'll find a point where too much voltage makes the device unstable, and too little is unstable as well. That's about the point where you're risking damage to your device and I suggest backing down the frequency by about 100MHz and calling that your safe maximum.

Now, for the other end of the frequency specturm...

You have a maximum AND a minimum. Most often, the frequency and voltages for the minimum are set for stability, not power saving. Some kernels will run as low as 22MHz. Some functions, such as playing media with the screen off, will not function well at such slow speeds. Usually 122MHz will perform well. After finding the lowest frequency that works for you, try to adjust the voltages down as low as possible. Since your phone spends most of it's time down around these frequencies, modest, but real power savings can be realized.

We've found the safe settings! Now what???

Well, you can do things the easy way and just set SetCPU and Incredicontrol to enforce your settings on boot, but now you've got 2 apps that are constantly running and taking up resources, especially SetCPU. There is a better way. That's where ScriptFusion comes into play. ScriptFusion is basically a script that creates a script in the /system/etc/init.d directory where boot executed scripts reside. This method doesn't use any system resources beyond those already used to establish these settings. ScriptFusion is easy to use, but it's settings execute at boot, therefore, any mistakes cannot be easy fixed if they make the system unstable. That's why I suggest using it as a method of implementing final changes, not feeling out where your points of stability are.

Still another way is to write your own script. Simple Linux commands in a properly formatted text file get the job done. Many resources can be found to show you how to write these kinds of scripts. It's also possible to copy a script already on your device, modify it, and push it back to the device using the "adb push" command.

Using a script:

The following is the actual script I use with the setup described in my signature. It began with a speedtweak.sh script that I pulled and edited over time to suite my desires.

#!/system/bin/sh
# Mode: extreme
#built for Imoseyon TEST kernels and branches. contact loonatik.lab@gmail.com with questions.
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
echo "184320 750" > $sysfile
echo "245760 825" > $sysfile
echo "368640 900" > $sysfile
echo "768000 1000" > $sysfile
echo "1024000 1100" > $sysfile
echo "1222400 1125" > $sysfile
echo "1408000 1175" > $sysfile
echo "1593600 1375" > $sysfile
echo "1766400 1375" > $sysfile
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1593600 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo smartassV2 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 60 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_ideal_freq
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
echo 1593600 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq
#echo 610000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
echo 6 > sys/devices/system/cpu/cpu0/cpufreq/smartass/sample_rate_jiffies
echo 50 > /proc/sys/vm/swappiness
echo cfq > /sys/block/mmcblk0/queue/scheduler
echo 40 > /proc/sys/vm/vfs_cache_pressure
echo "100,200,352,640,2570,5120" > /sys/module/lowmemorykiller/parameters/minfree
echo "0,1,2,11,12,13" > /sys/module/lowmemorykiller/parameters/adj
echo 30 > /proc/sys/vm/dirty_ratio
echo 35 > /proc/sys/vm/dirty_background_ratio
echo 5000 > /proc/sys/vm/dirty_expire_centisecs
echo 1 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/oom_dump_tasks
echo 1 > /proc/sys/kernel/sched_compat_yield
echo 250 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 1200 > /sys/block/mmcblk0/queue/iosched/write_expire
echo 1024 > /sys/block/mmcblk0/queue/read_ahead_kb
#echo "100,200,20000,20000,20000,25000" > /sys/module/lowmemorykiller/parameters/minfree

Everything all the way down to [echo "1408000 1175" > $sysfile] as well as the freq_min and freq_max is generated by the script. Imoseyon's speedtweak.sh doesn't have a quick setting for running at 1.6GHz, so the settings for 1600000KHz were added by me. The parameters with "smartass" in them are there to modify the behavior of the governor. The echo lines going to /proc/sys/vm/* modify RAM and virtual memory use. The lines echoing commands to /sys/* modify memory use and other behaviors. The lines beginning with "#" are ignored.

You've got 2 options, write the script from scratch using an appropriate editor, or modify one already on the device. Why invent the wheel if you don't have to? Let's modify! Here's one method to do it:

1) Connect your Tbolt to your computer with debugging checked and in "charge only" mode.

2) Navigate to your ADB directory in a command prompt window as usual, then enter "adb pull /system/etc/init.d/01vdd_levels", without the quotes.

3) You'll notice a new file in your ADB directory called.... 01vdd_levels! Lets open it with a suitable editor. I use Vim because it's made for Linux and this purpose. Easier ways exist.

4) From here you can make the edits you want to. Change a voltage, set your min or max freq, or adjust one of the many parameters of the governor you've chosen. A list of parameters for the active governor can be found using the following command: "ls /sys/devices/system/cpu/cpu0/cpufreq/(name of governor)" This doesn't work on non-active governors. "echo" commands set a parameter, followed by the parameter value, followed by the parameter location.

5) Once you've edited or created the parameters you want to run in the script, save it.

6) Go back to ADB. Enter "adb remount" to make /system writable. Enter "adb push 01vdd_levels /system/etc/init.d" to push the new file. It will automatically copy over the old file.

7) Now we have to set it's permissions. Enter "adb shell". That will take you to the command shell. Then enter "chmod 777 /system/etc/init.d/01vdd_levels". This permission level is higher than what it needs to be, but it will get the job done.

8) Reboot by exiting out of adb shell. Enter "exit" in the shell until you're back at the DOS prompt. Then enter "adb reboot". Your device will reboot a moment later and all your script setting SHOULD be in place if you've done it right. You can check to see if that's the case using the "cat" command. An example would be:

cat /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load

The result of that command should reflect the value you've entered in the script.

Another way of editing an already existent script: Our friend, Script Editor!

* You might need to modify file permissions to edit a stock file. In terminal: chmod 777 /system/etc/init.d/name_of_file

1: Go to the market and install Script Editor.

2: Navigate to /system/etc/init.d/01vdd_levels and select it.

3: You'll get a window with all kinds of spiffy options. We want to edit. If you have a text editor or a file manager with and editor, it will ask you to select one.

4: Edit your script. Double check your values. Then save it.

5: At the file menu you saw before, select "Run". You'll get a terminal screen as the script runs. Once it's finished, exit out with the button at the top left. You're all done!

The reason for editing the script the way I've done, by adding in parameters for the governor, is to better manage how the governor performs. Some simply cut the balls of their device by setting clock settings low to save power. No need for that if your chosen governor is behaving the way you want. I find the settings I have for smartass keep spikes up to full clock speed to a minimum and saves even more power than just castrating the device because it's CHOOSING to run at slower freqs, not artificially limited to them. Therefore, under more modest loads, it's going to use more modest settings, not the max possible, even if it's a low max. Properly tweaked, you're device may rarely exceed factory clock speeds, but if need be, summoning 1.6GHz is possible. Obviously this method is more efficient than castrating your device.

If you're prone to using different governors, or you like to change you freq_min or freq_max settings, you may add additional data to the script with no ill effects. For instance, if I change to the interactiveX governor, I can simply add in more lines to alter that governor without removing the lines for the smartass. The parameters for the smartass simply won't be implemented because the path becomes invalid.

This is the leanest method of implementing kernel settings, and the most powerful. This script by no means is the limit to what you can do. What a script is able to do depends on the kernel features you're applying it to. It's possible with some kernels to alternate between governors based on conditions of the device. For me, this script gets the job done and that's all I care about.

A valuable note on scripts: There's an app called Script Manager that does an excellent job helping to manage, edit, and create scripts. With this app, it's possible to edit a script, save it, and execute it. It will also allow you to execute scripts on boot that aren't in /system/etc/init.d. If you're attempting to edit a script in the /system directory and it warns you that it's read-only, back out of the file edit functions, hit "menu", then "more", then "advanced options", and select "mount /system as RW" If scripts are your thing, this is a very handy app to have.

"Geeze Loonatik! What's all that crap mean???"

Good question. There's a lot of numbers in there that don't seem to have an obvious value. It took me a while to look if up and get decent answers, and I still haven't figured it all about, but let me share what I know.

/lowmemorykiller values: These values are pages. There are 6 of them that dictate the minimum number of pages (4kb in size) allowed free before processes are killed in that catagory. More on this can be read HERE. Additional info can be found HERE.

/proc values: These values dictate virtual memory and RAM use and behavior. There's actually a lot of them, but most aren't going to do much, and some don't even apply to Android devices, but are there because it's Linux. THIS link does a very good job documenting them.

/smartass/sample_rate_jiffies: A "jiffy" is a time value based upon a number of clock cycles. The number of clock cycles is fixed, but not always the same for every implementation.

/sys/block/mmcblk0/queue: These parameters are pretty straight forward. Time is measured in milliseconds and size in kb. Before you look at these and say "Hell! I'll just set it to read a MB at a time ahead and IO reads and writes to expire in 150ms", consider the fact that will become the top priority of your device. It's entirely possible to create lag by setting IO operations to such high performance that will be pretty much all your phone wants to do. My settings are actually pretty extreme, but they work for how I generally use the phone.

I'll try to explain more as I have the time and learn more.

Credit: Androcheck, Pikachu01, Linuxinsight.com

I hope someone finds this useful. If anyone has any input or suggestions, feel free to toss them out there.