• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[MOD][KERNEL] Live OC

Search This thread

Ezekeel

Retired Recognized Developer
Jun 21, 2011
715
1,680
We all know Morfic's popular TEUV kernel which features a low maximum frequency of just 880MHz, but still shows an excellent performance. The secret sauce is the increased bus speed of 220MHz compared to the stock frequency of 200MHz. The problem is that every Nexus S behaves differently because of production tolerances for the CPU and not all devices are able to handle this increased bus speed.

Thus it would be nice to have some way for the user to individually adjust the bus speed to match the overclocking capabilities of their device. Unfortunately with TEUV the bus speed has to be defined on compilation time thus the only way would be to release different versions with different bus speeds which, frankly, would be a pain in the ass. So I implemented a way to change the bus speed on-the-fly while the device is running. In contrast to TEUV not only the bus speed for the maximum frequency but for all states is increased by the same percentage (might change this later, especially for the minimum state).

In '/sys/class/misc/liveoc' change the performance by passing a value from 100 to 120 to 'oc_value' (100 = stock performance, 120 = +20% performance; 100 is default). The bus speed and frequencies for all states will be adjusted accordingly.


I am currently running my Nexus with an increased performance +10% using the stock frequencies 100->110, 200->220, 400->440, 800->880 and 1000->1100 and after increasing the voltage for the maximum state by 25mV 30mV everything is working fine without a reboot for 24h now. The battery drain however seems to be pretty high so it might be a good idea to leave the lowest frequency state untouched. Time and your feedback will tell. Seems like the sleep frequency fix also took care of the high battery drain.


Changes to the source: http://www.pastie.org/2634833


BUGFIX:

The sleep frequency is also adjusted according to the selected OC value, so a proper sleep frequency is chosen when the device is suspended.

Bug fix: http://www.pastie.org/2635644


BUGFIX #2:

When OC value is changed, the minimum and maximum frequency limits set by the user are adjusted according to the new frequencies.

Bugfix: http://www.pastie.org/2691219


BUGFIX #3:

Made sure the bus speeds and frequencies are not changed while a frequency change is currently ongoing.

Bugfix: http://www.pastie.org/2710098


BUGFIX #4:

Instead of a spin lock (which leads to problems) we use a mutex to make sure the bus and frequencies are not changed while a frequency change is ongoing.

Bugfix: http://www.pastie.org/2710386


BUGFIX #5:

If no mutex lock can be obtained, an error value is returned to inform the caller that the frequency was not changed.

Bugfix: http://www.pastie.org/2746226


BUGFIX #6:

1. Reverting back to mutex_lock to make sure no important request like enabling/disabling further frequency changes are skipped.
2. The mutex is unlocked before the CPUfreq stats are resetted. With the above modification this seems necessary to avoid lockups when changing the OC value.
3. The frequencies and bus speed are updated only when the selected OC value actually did change.

Bugfix: http://www.pastie.org/2756640


BUGFIX #7:

Maximum OC value increased to 150.

Bugfix: http://www.pastie.org/2768535


No further patches will be published here. I have set up a git repo for all my tweaks. Each mod has its own branch to keep the tweaks cleanly separated and one can simply pull the latest patches from the corresponding branch.

https://github.com/Ezekeel/GLaDOS-nexus-s/tree/liveoc



Thanks to Morfic for his help.
 
Last edited:

kevinngck1

Senior Member
Aug 4, 2011
381
45
Is the liveoc file just included in morfic teuv kernel???

Sent from my NOOB Nexus S with the poor english by using XDA Premium App
 

franciscofranco

Recognized Developer
Dec 9, 2010
24,727
136,425
Carcavelos
Pretty impressive idea and implementation.

Although I don't have this phone (hope to get one soon as it's for a great price here in Portugal), I stumbled upon this thread and I liked it very much. Keep it up!
 

simms22

Recognized Contributor - R.I.P
Jun 4, 2009
34,055
25,931
BROOKLYN!
www.androidcommunity.com
We all know Morfic's popular TEUV kernel which features a low maximum frequency of just 880MHz, but still shows an excellent performance. The secret sauce is the increased bus speed of 220MHz compared to the stock frequency of 200MHz. The problem is that every Nexus S behaves differently because of production tolerances for the CPU and not all devices are able to handle this increased bus speed.

Thus it would be nice to have some way for the user to individually adjust the bus speed to match the overclocking capabilities of their device. Unfortunately with TEUV the bus speed has to be defined on compilation time thus the only way would be to release different versions with different bus speeds which, frankly, would be a pain in the ass. So I implemented a way to change the bus speed on-the-fly while the device is running. In contrast to TEUV not only the bus speed for the maximum frequency but for all states is increased by the same percentage (might change this later, especially for the minimum state).

In '/sys/class/misc/liveoc' change the performance by passing a value from 100 to 120 to 'oc_value' (100 = stock performance, 120 = +20% performance; 100 is default). The bus speed and frequencies for all states will be adjusted accordingly.


I am currently running my Nexus with an increased performance +10% using the stock frequencies 100->110, 200->220, 400->440, 800->880 and 1000->1100 and after increasing the voltage for the maximum state by 25mV everything is working fine without a reboot for 24h now. The battery drain however seems to be pretty high so it might be a good idea to leave the lowest frequency state untouched. Time and your feedback will tell.


Changes to the source: http://www.pastie.org/2634833


BUGFIX:

The sleep frequency is also adjusted according to the selected OC value, so a proper sleep frequency is chosen when the device is suspended.

Bug fix: http://www.pastie.org/2635644


Thanks to Morfic for his help.


very nice.
i wonder why the increased battery drain. are you still getting similar numbers in setcpu's "time in state" as you were with teuv?
 

morfic

Inactive Recognized Developer
Aug 3, 2008
7,211
12,879
San Antonio
www.derkernel.com
Morfic's TEUV kernel was the inspiration for this mod. It is not implemented in any kernel yet.

I'll need some time to wedge this in.
Check why the compile fails after adding the failed hunks (looks like possibly missapplied fuzzy hunk)
Aside i would want it to work with each kernel type, be it TEUV, TUV or T12, T13, T144 or T1544
Since that is all layed out as Kconfig options i'll have to check where to apply the code you added to stock source so it will indeed work for all the speeds, kind of as a added bonus to the current speeds.
Then i would have to shoehorn in a voltage control and OCing without voltage control is not a good idea, 1.0GHz has some obvious headroom, but the OC speeds especially will want a nudge on the voltage side if you nudge the bus/cpu/gpu across the board by x%

and with kernel.org up (not android.git.kernel.org (unless we android geeks just totally hammered it)) i would prefer to grab latest samsung source, freshen up all builds, then work on integrating this.

I could see the netarchy layout benefit from this patch as there are no Kconfig #ifdef to deal with :) (I'm looking at you mathkid ;P lol ;) hah! coo ;) <3)

Just a little timeframe setter to tune the expectations to a realistic level.


Thanks Ezekeel
 
  • Like
Reactions: simms22

Ezekeel

Retired Recognized Developer
Jun 21, 2011
715
1,680
Thanks to all your kind words.

Seems like the sleep frequency fix also took care of the high battery drain.
 

kenvan19

Senior Member
Dec 7, 2010
3,563
540
Dude, ezekeel do you ever sleep or think about anything other than making our phones more powerful? How can so much utility come from one guy and why are you not employed by the government finding new and exciting ways to kill people. Imo you deserve a massive salary with a brain like yours.

Sent from my Nexus S MV from the XDA Premium app.
 

morfic

Inactive Recognized Developer
Aug 3, 2008
7,211
12,879
San Antonio
www.derkernel.com
Dude, ezekeel do you ever sleep or think about anything other than making our phones more powerful? How can so much utility come from one guy and why are you not employed by the government finding new and exciting ways to kill people. Imo you deserve a massive salary with a brain like yours.

Sent from my Nexus S MV from the XDA Premium app.

He codes on the job, i think that makes a big difference on the time availability front. ;)
 

Top Liked Posts

  • There are no posts matching your filters.
  • 50
    We all know Morfic's popular TEUV kernel which features a low maximum frequency of just 880MHz, but still shows an excellent performance. The secret sauce is the increased bus speed of 220MHz compared to the stock frequency of 200MHz. The problem is that every Nexus S behaves differently because of production tolerances for the CPU and not all devices are able to handle this increased bus speed.

    Thus it would be nice to have some way for the user to individually adjust the bus speed to match the overclocking capabilities of their device. Unfortunately with TEUV the bus speed has to be defined on compilation time thus the only way would be to release different versions with different bus speeds which, frankly, would be a pain in the ass. So I implemented a way to change the bus speed on-the-fly while the device is running. In contrast to TEUV not only the bus speed for the maximum frequency but for all states is increased by the same percentage (might change this later, especially for the minimum state).

    In '/sys/class/misc/liveoc' change the performance by passing a value from 100 to 120 to 'oc_value' (100 = stock performance, 120 = +20% performance; 100 is default). The bus speed and frequencies for all states will be adjusted accordingly.


    I am currently running my Nexus with an increased performance +10% using the stock frequencies 100->110, 200->220, 400->440, 800->880 and 1000->1100 and after increasing the voltage for the maximum state by 25mV 30mV everything is working fine without a reboot for 24h now. The battery drain however seems to be pretty high so it might be a good idea to leave the lowest frequency state untouched. Time and your feedback will tell. Seems like the sleep frequency fix also took care of the high battery drain.


    Changes to the source: http://www.pastie.org/2634833


    BUGFIX:

    The sleep frequency is also adjusted according to the selected OC value, so a proper sleep frequency is chosen when the device is suspended.

    Bug fix: http://www.pastie.org/2635644


    BUGFIX #2:

    When OC value is changed, the minimum and maximum frequency limits set by the user are adjusted according to the new frequencies.

    Bugfix: http://www.pastie.org/2691219


    BUGFIX #3:

    Made sure the bus speeds and frequencies are not changed while a frequency change is currently ongoing.

    Bugfix: http://www.pastie.org/2710098


    BUGFIX #4:

    Instead of a spin lock (which leads to problems) we use a mutex to make sure the bus and frequencies are not changed while a frequency change is ongoing.

    Bugfix: http://www.pastie.org/2710386


    BUGFIX #5:

    If no mutex lock can be obtained, an error value is returned to inform the caller that the frequency was not changed.

    Bugfix: http://www.pastie.org/2746226


    BUGFIX #6:

    1. Reverting back to mutex_lock to make sure no important request like enabling/disabling further frequency changes are skipped.
    2. The mutex is unlocked before the CPUfreq stats are resetted. With the above modification this seems necessary to avoid lockups when changing the OC value.
    3. The frequencies and bus speed are updated only when the selected OC value actually did change.

    Bugfix: http://www.pastie.org/2756640


    BUGFIX #7:

    Maximum OC value increased to 150.

    Bugfix: http://www.pastie.org/2768535


    No further patches will be published here. I have set up a git repo for all my tweaks. Each mod has its own branch to keep the tweaks cleanly separated and one can simply pull the latest patches from the corresponding branch.

    https://github.com/Ezekeel/GLaDOS-nexus-s/tree/liveoc



    Thanks to Morfic for his help.
    12
    [MOD] Selective LiveOC

    I like this MOD. Except one(applies to ALL frequency).
    So I fixed it once. It works fine. So I want to show this MOD. :)

    This MOD is based on LiveOC(Is it natural? :D)

    This MOD applies 'LiveOC' 800MHz and above. If you want to change. You just change the value '800000'.

    This MOD's source is here.
    7
    I like this MOD. Except one(applies to ALL frequency).
    So I fixed it once. It works fine. So I want to show this MOD. :)

    This MOD is based on LiveOC(Is it natural? :D)

    This MOD applies 'LiveOC' 800MHz and above. If you want to change. You just change the value '800000'.

    This MOD's source is here.

    I've fixed more.
    now you can change this value.

    /sys/class/misc/liveoc/oc_target -> value is here

    source is here

    ---------- Post added at 11:03 PM ---------- Previous post was at 11:02 PM ----------

    Live OC above the selected freq?

    General users can change the oc target?

    yes. you can change value through "/sys/class/misc/liveoc/oc_target"

    if you want to change 1000MHz. Change the value 1000000. then liveoc applies 1000MHz and above. Below frequencies are not applied.
    6
    thanks for this mod! it seems like a great implementation. do you have any ideas as to having the mod apply to freq below the target, instead of freq above the target. this would give the ability to benefit from higher BUS at lower CPU freq without having to worry so much about stability issues at higher CPU frequencies ? so theoretically i could set the target at 800000 and live oc at 105 and my CPU freq would be overclocked up to 840 but then 1000 1200 1300 and 14** could stay the same. Or am I just missing the point :p


    Sorry to late reply. It is not difficult. I'll do&upload later.

    Sent from my Nexus S using xda app
    5
    Hello. I was added lower/higher frequency limit on MODed LiveOC.

    See this :)
    (I was consulted https://github.com/DerTeufel/samsung-kernel-aries/commit/923fcd92cc40c1ba5e93c419f3edd9fcb7a69303)

    great :)

    i have removed the limit for traget_low <= target_high and vice versa, and also added one more "if" to cpufreq.c, now the values can be "switched" and live_oc can be applied to all freq, which are NOT between the two limits. i'll send you the commit later. maybe you find this useful, too.