*OVERCLOCK* Specific OCT V1.5 Settings

[thewahlrus]

Originally Posted by one80oneday

I usually turn it off and on a few times when I change the settings and they usually stick when I reboot

Yep, that's what I do. Set, on/off a few times then they'll stick. If you just set then turn on you'll lose them on reset.

[horndoctor]

Wirelessly posted (htc Pocket PC: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 7.11) Sprint MP6950SP)

Originally Posted by madjokeer

The OCT Settings reset when the phone resets. is there a way to keep the settings @ reboot?

Yes, settings are only saved when you turn the oct off or you click on OCT_Stop to exit the device driver.

[slinkydoo1982]

In whatever ROM you're using, try this; using the OCT V1.5 cab, installed to the storage card, 710mhz, 2000ms polling, 100load max, 0 load min, 80 jum max, 3 jump min, ---> 15 steps <---. Let it run for a few hours, play with it, bump it up to the next higher speed; 729. Every few hours work your way up to the next higher speed setting. Once you get to 767 (my max) take it down to --> 2 <--steps, (I think maybe your processor needs to be "ramped up"?). Then if it stayed stable, take it from 2 steps to 0 steps. Did this a fresh install on 24xxx 9/4 NRG and it worked. Even had 787 for a while, then, froze :/

Just curious if all that works for others, on other ROMS.

[quick99si]

Originally Posted by horndoctor

Wirelessly posted (htc Pocket PC: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 8.12; MSIEMobile6.0) Sprint T7380)

Can someone who knows more than me please explain the load max, load min, jump max and jump min values to me and what they are supposed to do?
I left those values alone because after reading an explanation in the developers thread on xda I still am kinda confused.

Check out the developer's readme file at: http://forum.xda-developers.com/show...&postcount=162

The "steps" are a bit confusing since the math is slightly convoluted and all of the value depend on your max speed. Simply put, when OCT detects a cpu load (%) which exceeds load_max value, it will "step up" the cpu speed; conversely, it will "step down" if it's lower than load_min. This decision and resulting action are both performed at a regular interval which is configurable as well.

The stepping is done in stages and the change in cpu clock speed is a function of max cpu speed as well as the current step. It goes from cpu_max (let's say 700mhz)
to cpu_max/2 (350mhz)
to cpu_max/3 (233mhz)
to cpu_max/4 (175mhz)
..
to cpu_max(x) (cpu_max/x)

Setting the step value to 0 will keep the clock speed at cpu_max at all times (700mhz in our example). Setting it to 1 will keep the cpu at 700mhz and then underclock to 350mhz under low load; 2 will keep it at 700, then 350, and then eventually settle at 233mhz if the calculated load is less than load_min at every calculation. You can disable the ramping up by setting the load values to 100/0 respectively.

You can also configure it to essentially bypass, but not disable this ramping up effect by setting jump_min and jump_max. If the cpu load exceeds jump_max, OCT will set the clock speed to your cpu_max immediately. It'll also set it to your lowest speed if the load is less than jump_min. The lowest speed will equal cpu_max/(steps+1).

My settings are:
cpu_max: 748.8
steps: 4 (underclocked speed ~150mhz, no SOD yet)
load_max: 100
load_min: 0
jump_max: 50
jump_min: 2 (keeps it at max speed for a little longer while reading in Opera!)
interval: 2000

I don't like the fact that the cpu load is calculated so frequently, or rather the fact that the calculations are required for multiple clock speeds. The developer has included API which allows external applications to manipulate the cpu clock speed through OCT... it seems that event driven changes to this speed would be more efficient in every regard (eg backlight dim, suspend, idle timer). I don't enjoy the lag of a sudden demand on the cpu while it's stuck at its lowest speed.. I realize that lowering the interval or the number of steps would help, I left them as is for the battery life benefits with a small hit to on-demand performance. nueDynamicClock had this for the TP1 though it wasn't as flexible IMO.

[quick99si]

Is it me or does the backlight "un-dimming" cause OCT to bring the cpu up to max speed, regardless of load??

[horndoctor]

Originally Posted by quick99si

Is it me or does the backlight "un-dimming" cause OCT to bring the cpu up to max speed, regardless of load??

Yes, I believe you are right.
Thank You very much for your very informative post!
That helped to clear things up a bit for me and I'm sure others as well.
I think I may try something similar to your settings.
Thanks again!

[Eschelon]

I guess I'm one of the lucky ones

I can run OCT on stock settings at 825.6 MHz - STABLE

(screenie attached below to prove it)

I win

[quick99si]

Originally Posted by horndoctor

Yes, I believe you are right.
Thank You very much for your very informative post!
That helped to clear things up a bit for me and I'm sure others as well.
I think I may try something similar to your settings.
Thanks again!

No, thank you for the confirmation. This feature is welcome in my book, and it may be a sign of the developer's gradual movement toward the event driven overclock/under**** actions I described earlier.

Wouldn't it be great if it could be configured to do something like:
~750mhz with the backlight at full brightness
~250mhz with the backlight on low
~125mhz during suspend
No stepping, no intervals, no calculations

[Ph33zy]

do you guys actually notice any performance increase?

[horndoctor]

Wirelessly posted (htc Pocket PC: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 8.12; MSIEMobile6.0) Sprint T7380)

Originally Posted by Ph33zy

do you guys actually notice any performance increase?

Definitely!
If you run a benchmark you'll see proof.