I'm playing a bit with the Nexus One kernel a bit and I noticed this code snippet:
/* Move to 768 MHz for boot, which is a safe frequency
* for all versions of Scorpion at the moment.
*/
speed = acpu_freq_tbl;
for ( ;; ) {
if (speed->acpu_khz == 768000)
break;
if (speed->acpu_khz == 0) {
pr_err("acpuclk_init: cannot find 768 MHz\n");
BUG();
}
speed++;
}
Click to expand...
Click to collapse
Now, I might be wrong and please correct me if I am: I am assuming this code is there because there are two versions of Snapdragon QSD 8250 - one that runs at 998 MHz, and one that runs on 768 MHz, which is essentially just an underclocked version of the first one (maybe just slightly worse units not binned for 998 MHz during the production)
I suppose that CPU driver has to support both versions, and therefore I am assuming they need to stay at 768 MHz during the boot process to be safe...
Anyway... maybe I am wrong, but I just replaced the 768 MHz clock selection with 998 MHz and I see no problem at all - my N1 is booting perfectly fine with 998 MHz boot frequency.
But, as stated above - I could be really wrong here, and it would be great if people with deeper knowledge (or in possession of QSD 8x50 datasheets ) would comment on this...
Also, at the same time I added AXI frequency scaling to the CPU driver - code is here: http://forum.xda-developers.com/showpost.php?p=7541522&postcount=13 - this also appears to be stable... but, as with any experimental addition - it will need further testing
Did you see any noticeable benefit with the boot @ 998? I think you're probably right about it being set to "safe" for both processors, but what would be the gain? I'm all for a quicker boot sequence.
Would be nice to do some benchmarks on a clean install, and domt see why we couldn't post at 1113. If we could would be a near 33% increase for cpu limited tasks
I think I saw Cyan change this before so I think you have the right idea with this being the bootup frequency.
Yep - even 1113 MHz boots just fine, at least on my phone...
Now, I cannot say if the boot is any faster really as my phone is loaded with lots of things so it would be hard to measure... I guess to benchmark this the best would be to start with a "clean" just wiped phone.
Ivan Dimkovic said:
Yep - even 1113 MHz boots just fine, at least on my phone...
Now, I cannot say if the boot is any faster really as my phone is loaded with lots of things so it would be hard to measure... I guess to benchmark this the best would be to start with a "clean" just wiped phone.
Click to expand...
Click to collapse
Thats what I was thinking, although if you nandroid, wipe, install some default ROM, nandroid, push, nandroid, you can switch and change between the two in maybe 5 mins from then on.
its a safe (for the masses) boot up frequency.
i use 883 (768 (stock)).
Have you timed the difference in bootup speed of 768Mhz Vs 998Mhz? Any difference of any merit? (maybe boot 3 times on each and take an average?).
have you tried setting the values out of a reasonable range (1267 or something similar) just to see if changing that value does anything at all? if it doesn't boot, you would know that your values are getting read correctly...
What we need is a benchmark.
See if it boots faster.
Related
So I've been traipsing through some of the other Qualcomm repositories searching for tidbits that might be of use for N1 kernels. As far as I can tell, none of these changes have been merged in to the aosp or cyanogen kernels, although unfortunately the underlying kernels have diverged and these won't apply cleanly but it should be possible to manually merge with some effort.
First up, this patch reduces AXI (internal bus) speed when the apps CPU is running at lower clock speeds and increases it when at higher clock speeds. Memory would otherwise be the bottleneck for many applications.
https://www.codeaurora.org/gitweb/q...it;h=6caa6d84d8c687b5f66f5b5ea281183eae8947a8
Code:
msm: acpuclock-8x50: Couple CPU freq and AXI freq.
The memory throughput is directly proportional to the AXI frequency. The
AXI freq is coupled with the CPU freq to prevent the memory from being
the bottleneck when the CPU is running at one of its higher frequencies.
This will cause an increase in power consumption when the CPU is running
at higher frequencies, but will give a better performance/power ratio.
This patch adds core support for AXI clock changes.
https://www.codeaurora.org/gitweb/q...it;h=009d997b1439edf1991e181206c74ee3e943787e
Code:
msm: clock: Add SoC/board independent APIs to set/get max AXI frequency.
Some drivers need to set the AXI frequency to the maximum frequency
supported by the board. Add a MSM_AXI_MAX_FREQ_KHZ magic value that
allows them to achieve that in a SoC/board independent manner.
The following two patches drop the AXI speed when the processor is idle but the screen is on, down to the minimum that will allow the framebuffer to keep driving the screen. Claims to save ~20 mA which would be somewhere around 10-20% at least. Unfortunately these will probably be harder to merge in, as the Chromium kernel uses quite a different mdp/framebuffer architecture. Still, worth trying!
https://www.codeaurora.org/gitweb/q...it;h=fdb01a9945f2ac3a4cc76c507ed0abf5dd5cfb57
Code:
msm_fb: Reduce AXI bus frequency to 62 Mhz from 128 Mhz
Reduced AXI bus frequency to 62 Mhx to save power during idle
screen mode/limited sleep mode.
https://www.codeaurora.org/gitweb/q...it;h=dee586811e34cb24dedc1d0587f3e31f1ba656a6
Code:
msm_fb: Reduce AXI bus frequency to 58 Mhz from 64 Mhz.
Reduce AXI bus frequency further to 58 Mhz for lcdc panels to save
~20mA power during idle screen mode/limited sleep mode.
I can't wait to see what Kmobz, Intersect, and pershoot do with this!
interesting stuff...hopefully one of the many great kernel devs can use this info and find a way to get it to be useful on the N1 and save more battery life
For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:
Code:
/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
axi_rate = 0;
clk_set_rate(axi_clk, axi_rate);
}
The only thing that is missing is the setting of the axi rates along with the cpu frequency. However, I would think that it is going to take a special amount of trial and error to get the rates correct for the nexus one, since they are, after all, different pieces of hardware.
We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?
coolbho3000 said:
We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?
Click to expand...
Click to collapse
It should be possible to go with Code Aurora's 58 I think?
Yes we could reduce it further. I dont know what impact it will have on stability yet.
I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.
It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.
I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).
Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....
jazzor said:
Yes we could reduce it further. I dont know what impact it will have on stability yet.
I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.
It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.
I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).
Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....
Click to expand...
Click to collapse
I've made too many changes to acpuclock to apply this directly. I'll take a look at it later though.
jazzor said:
For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:
Code:
/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
axi_rate = 0;
clk_set_rate(axi_clk, axi_rate);
}
Click to expand...
Click to collapse
True, but the comment doesn't agree with the code itself:
Code:
/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
axi_rate = 128000000;
sleep_axi_rate = 120000000; // <- 120 MHz...
clk_set_rate(axi_clk, axi_rate);
}
I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?
Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).
hugonz said:
True, but the comment doesn't agree with the code itself:
Code:
/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
axi_rate = 128000000;
sleep_axi_rate = 120000000; // <- 120 MHz...
clk_set_rate(axi_clk, axi_rate);
}
I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?
Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).
Click to expand...
Click to collapse
I might be wrong, but this is how I understand it. axi_early_suspend is called when the nexus is going under suspend mode, which is like suspend to ram. This happens when there are no active tasks running and the screen is off. As the code says, the rate is set to 0 implying it is going to set it as low as the limits allow (assuming that is 61mhz). axi_late_resume is for the case when the nexus is NOT in suspend. There are still 2 states in this mode, one where the machine is being actively used (browsing web) and one where the machine is idle (such as when we are listening to music or any background task that may or may not be using the screen), but the machine cannot suspend to ram due tasks still actively running.
In any case, experimenting with lower values of axi rates should be done to see if it indeed saves battery.
oooh great thread. I will definitely be looking into this stuff when I get back in town! thanks for the links!
https://www.codeaurora.org/gitweb/q...it;h=8a68421a300878d729991c1db609a541910d2c70
Here is another patch (more up to date -> perhaps easier to merge).
I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.
Ivan Dimkovic said:
I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.
Click to expand...
Click to collapse
Do you run this along with a custom kernel and just flash in recovery like an update.zip?
I usually use Cyanogen's kernel as base for my experiments - so this should definitely compile with Cyanogen's 2.6.34 kernels. This acpuclk-scorpion.c has lowered voltages and also support for frequencies up to 1190 MHz
Although you will also need to change few call prototypes in acpuclock.h - it is quite trivial just replace old acpuclk_set_rate() and acpuclk_power_collapse() prototypes with these:
enum setrate_reason {
SETRATE_CPUFREQ = 0,
SETRATE_SWFI,
SETRATE_PC,
SETRATE_PC_IDLE,
};
int acpuclk_set_rate(unsigned long rate, enum setrate_reason reason);
unsigned long acpuclk_power_collapse(int from_idle);
Click to expand...
Click to collapse
That should do it.
Markdental said:
Do you run this along with a custom kernel and just flash in recovery like an update.zip?
Click to expand...
Click to collapse
No, this will have to compiled into the kernel, which I'm doing right now. Thank you so much for doing this Ivan!
Nice to see someone finally got this to work! I've been too lax as of late.
Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built
Ivan Dimkovic said:
Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built
Click to expand...
Click to collapse
what change to pm.c if any?
pm.c already has everything in place needed for AXI clock switching.
Hi... I have rooted my Samsung GS2 and payed for the OC app TEGRAK ..
But every time I go over 1400mhz the phone gets very unstable.
It even feezes at 1400 mhz when i use my navigon app...
I have tested it at 1500 mhz.. But reboots in a kind of save mode.,,,
At 1400mhz i runs Quadrant smooth with 4200 in score
And 56 MFLOPS in Linpack
But why is my phone so unstalbe?
But why is my phone so unstalbe?
Click to expand...
Click to collapse
Because it's supposed to run at 1.2Ghz.
If every SGS2 was able to run at 1.4Ghz without any issue I guess Samsung would have set them at 1.4Ghz by default (since battery life is obviously the least of their concerns ^^). When CPUs are produced, there's always variations in quality. what usually happens on x86 CPUs is that they're tested, sorted according to their max stable frequency, and then sold under different names and at different prices. For Exynos my guess is that any CPU that fails to pass the 1.2Ghz bar is just ditched, and they keep the others, some of which will work at 1.4Ghz, whereas some won't.
Now if you want to gain more stability, you can always try to increase the voltage, it usually gets more stable as voltage increases, but it also gets hotter (which can cause it to crash, or may even permanently damage the processor).
BlueScreenJunky said:
Because it's supposed to run at 1.2Ghz.
If every SGS2 was able to run at 1.4Ghz without any issue I guess Samsung would have set them at 1.4Ghz by default (since battery life is obviously the least of their concerns ^^). When CPUs are produced, there's always variations in quality. what usually happens on x86 CPUs is that they're tested, sorted according to their max stable frequency, and then sold under different names and at different prices. For Exynos my guess is that any CPU that fails to pass the 1.2Ghz bar is just ditched, and they keep the others, some of which will work at 1.4Ghz, whereas some won't.
Now if you want to gain more stability, you can always try to increase the voltage, it usually gets more stable as voltage increases, but it also gets hotter (which can cause it to crash, or may even permanently damage the processor).
Click to expand...
Click to collapse
At 1.4ghz the phone will also get hotter and it decreases the lifetime if you run 24/7 at 1.4ghz
Ok.. I know about the x86 cpu's.. But didn't think it was the same in ARM cpu's-
But I see ALOT SGS2 that runs 1800mhz..
I guess that I just have one of the not so OC lilkes...
Overclocking won't always work for everyone at same levels.
I've also seen evidence to suggest that OCing significantly reduces the life of the SGS2. Nobnut had his phone vastly overheating even on stock speeds, and constantly rebooting... He overclocked. A number of others reported similar.
Overclocking is not simple and it is not that you just click on 1400/1500 MHz and you are Overclocked. A lot of things matter here. When we overclock in our Desktops then we have to test it very thoroughly, setting up the right VCore, Bus voltage, Multiplier, checking the stability and temperature etc. etc. Tegrak OC is a nice and simple software to use, but it can't be perfect when you can't set all the settings manually other that just higher the clock rate. Personally I'd always stay with stock speed as incorrect OC could harm my CPU and GPU.
Regards.
If you know anything about overclocking then you'll understand that there are a variety of factors that affect the overclocking of a system. The overclock headroom you get from a processor varies, add to that the variables in component tolerance in the circuit board and you have a huge variety of factors that can limit the maximum frequency that you can overclock your system to.
I'll give you an example using my computers. Click on the images below:
Both processor overclock similarly on using the same components and that was the maximum I could get out of them. Now when I bought an EVGA X58 Classified motherboard and overclocked the Xeon W3520 I got it up to 4704 MHz with less vCore and less CPU VTT. All of this was done with aircooling.
My point is that not all systems will overclock the same even though they share the same model components.
So I followed Droidstyles "how to" guide on how to put ics on my phone.( http://forum.xda-developers.com/showthread.php?t=1238070 )
I love it so far but now it leaves me wanting more from my phone. Im trying to learn how to overclock my cpu.
I currently have Teamhacksung 6.1 on my phone. And in my "about phone" section my kernel version reads
3.0.8-g0d5605e-dirty
[email protected] #1
Not too sure if those are the same thing. Can i overclock my CPU with the current kernel i have or do i have to put another one on my phone?
Thanks alot for any replies!
Djp2012 said:
So I followed Droidstyles "how to" guide on how to put ics on my phone.( http://forum.xda-developers.com/showthread.php?t=1238070 )
I love it so far but now it leaves me wanting more from my phone. Im trying to learn how to overclock my cpu.
I currently have Teamhacksung 6.1 on my phone. And in my "about phone" section my kernel version reads
3.0.8-g0d5605e-dirty
[email protected] #1
Not too sure if those are the same thing. Can i overclock my CPU with the current kernel i have or do i have to put another one on my phone?
Thanks alot for any replies!
Click to expand...
Click to collapse
Flash Glitch v14 located in the Development forum.
Please Remember to use nstools for overclocking.
Sent from my SCH-I500 using XDA App
Wow thanks for the fast reply.
Do i have to uninstall any of the other kernels I have or go back to any versions?
Or can I download glitch v14 and use odin to flash it from the version im on?
Djp2012 said:
Wow thanks for the fast reply.
Do i have to uninstall any of the other kernels I have or go back to any versions?
Or can I download glitch v14 and use odin to flash it from the version im on?
Click to expand...
Click to collapse
Flash via CWM.
Hold power button
Select 'Reboot'
then select 'Reboot Recovery'
Then flash.
No Odin needed.
That's it.
You cant uninstall a kernel, it boots the phone. You can flash different kernels though. (e.g Glitch Kernel)
Be careful when overclocking. Especially with LiveOC.
If you do not know how liveOC works, please, do not use it.
Have fun
Sent from my SCH-I500 using XDA App
Wow so i got it to work just by doing what you said. I know there is benefits for overclocking as well as some consequences if i dont do it right.
Is there anywhere i could go to read up more on how liveOC works on the fascinate? Like i said, i really want that extra edge that I can get from doing so
Also I downloaded NSTOOLS to get me started
Djp2012 said:
Wow so i got it to work just by doing what you said. I know there is benefits for overclocking as well as some consequences if i dont do it right.
Is there anywhere i could go to read up more on how liveOC works on the fascinate? Like i said, i really want that extra edge that I can get from doing so
Also I downloaded NSTOOLS to get me started
Click to expand...
Click to collapse
Here's the thread (quoted it to save you time)
Tk-Glitch said:
LiveOC and Custom Voltage guide by TkGlitch
for Glitch kernel V14
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Warning!
Overclocking is dangerous and is meant only for experienced users!
1- Introduction :
The "normal" overclocking system on SGS til now was the addition of some frequency steps past the stock 1GHz step. V13 kernel was using 7 overclocked steps
to push the maximum selectable speed to 1.7GHz.
In V14, less overclocked steps are present, but you can still overclock to 1.7GHz if you want (and if your phone is able to do it), and even up to 2.25GHz as a maximum.
You will need NSTools to use LiveOC and custom Voltage features in Glitch kernel V14.
To begin with, I'll explain you some basic things you have to know.
2- Clocks :
The CPU speed is the result of a bus speed and a multiplier.
Bus speed is linked to and equal to GPU and RAM speed.
The multiplier is per step and hardcoded by the kernel developer.
It does look like that : CPU speed = bus speed x multiplier.
Here are my values in V14 :
1500 MHz = 200 x 7.5
1400 MHz = 200 x 7
1300 MHz = 200 x 6.5
1200 MHz = 200 x 6
1000 MHz = 200 x 5
800 MHz = 200 x 4
400 MHz = 200 x 2
200 MHz = 200 x 1
100 MHz = 100 x 1
LiveOC gives you the access to direct and on-the-fly bus overclocking by 1% steps (150% being the maximum available). I'll say it again : BUS overclocking !
Though, it'll overclock the bus on all the steps at the same time, for the same percentage.
We'll talk about that later.
So if I want to overclock my 1GHz step to 1.1GHz, I'll have to select 1GHz as max frequency, and push LiveOC to 110%.
My bus speed beeing overclocked by 10% will give the following :
220 x 5 (1GHz multiplier) = 1100 MHz.
If you want to go higher than 1.5GHz, it's the same :
Set 1500 MHz as maximum frequency (for example), and push LiveOC. Let's say to 110%. You will get the following :
220 x 7.5 (1.5GHz multiplier) = 1650 MHz.
Pushing it to 114% will give 1710 MHz (228MHz bus) and so on, up to 150% giving 2250 MHz running an inachievable 300MHz bus.
3- The limits :
THE MAIN LIMIT AND PHONE KILLER IS HIGH TEMPERATURE. WARM IS OK, HOT IS TOO HOT. DON'T PLAY STUPID.
Obviously, so much control over the bus speed, frozen til now to what the kernel developer set, will also give you the ability to find the limits of your chip.
The main clocking limit is generally the RAM, corrupting itself when the bus speed is too high. And since the GPU uses the RAM as well, it'll become crashy too. That's why I have decided to add some steps with a bigger multiplier, to lower the bus for a higher CPU frequency.
The bus speed limits for you will be anywhere between 240 and 270 Mhz, depending on your device potential (higher and lower exists but rare).
Average is 240 MHz.
The CPU speed limits will be anywhere between 1300 and 1800 MHz (higher and lower exists but rare as well).
Average is 1400 MHz.
With that in mind, I wouldn't go too far past 130% (giving 260MHz bus speed).
4- The sweet spot :
What you want when overclocking is to get the best balance for each part. Since the bus is linked to RAM and GPU, you obviously want it as high as possible for gaming, video playing, web browsing etc. (even more now with GPU acceleration in Android 4.0+). Though, as you know already if you've read this guide til now, all steps in V14 are using the stock 200MHz frequency.
So what to do if I want a lower CPU speed with a higher bus/GPU speed ? Simple ! Just select a lower frequency step as starting point.
Let's say we want 250 MHz bus speed, so we'll use 125% LiveOC :
Using 800MHz step, you'll get 1GHz.
Using 1GHz step, you'll get 1.250GHz.
Using 1.2GHz step, you'll get 1.500GHz.
Using 1.3GHz step, you'll get 1.625GHz.
Using 1.4GHz step, you'll get 1.750GHz.
Using 1.5GHz step, you'll get 1.875GHz.
5- The issues :
With a new overclocking system obviously comes some new problems related to it.
With the ability to fine tune the frequencies, you'll find that some frequencies are buggy somewhat, giving low performances. For example, using 115% Live OC with the 1.3GHz step will give some poor performances, when 114 and 116% won't. It could be a NSTools issue, but I think it has more to do with the hardware. It's well known that on CPUs some frequencies or even frequency ranges can be buggy, unstable, or slow. If you encounter that, try to add or remove a percent to LiveOC.
As said earlier, LiveOC will overclock the bus for all steps at the same time by the same amount of %.
Knowing that, you'll have to adapt your voltages for all the frequencies to stay stable, and this for any sensible change on LiveOC percentage.
6- Custom Voltage :
What would be LiveOC without Custom Voltages ?!
I did add leakage values to Glitch kernel features when I saw that some phones were overclocking much better with the right balance between ARM and Int voltages, depending on the phone, with very different results. The leakage value was basically that : balance between the two.
Well, as you probably know if you did read the changelogs, you have now the capacity to overvolt/undervolt both the ARM voltage (the CPU voltage you know well already), and the Int (internal) voltage. The last one is the voltage going to the GPU/memory controller, and will need to be tweaked accordingly to your phone.
As a starting point, here are the Int voltage values I was using for each leakage, adapted for V14 new frequency table :
HIGH LEAKAGE :
1500 : 1.225
1400 : 1.200
1300 : 1.175
1200 : 1.150
1000 : 1.125
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
MEDIUM LEAKAGE :
1500 : 1.200
1400 : 1.175
1300 : 1.150
1200 : 1.125
1000 : 1.100
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
LOW LEAKAGE :
1500 : 1.175
1400 : 1.150
1300 : 1.125
1200 : 1.100
1000 : 1.100
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
Of course, using LiveOC will force you to change these voltages accordingly.
Here are some advices about this :
- Try to stay around 1.225 - 1.250V for your highest frequencies;
- Try not to ever go past 1.300V if you don't want to kill your phone quickly;
- Be VERY gentle when tweaking it as it is VERY sensitive;
- Try to follow a more or less linear curve for Int voltage on OC frequencies;
- Going below 1.000V on 100MHz step will generally kill stability with no battery gain.
This guide may change depending on my decisions related to the Glitch kernel development, or to polish / add things to it.
Thanks to Ezekeel from Nexus S section for these awesome tools.
LiveOC : http://forum.xda-developers.com/showthread.php?t=1288015
Custom Voltages : http://forum.xda-developers.com/showthread.php?t=1331610
23/01/2012 - UPDATED TO REFLECT V14-B1 CHANGES.
09/02/2012 - UPDATED TO REFLECT V14-B3 CHANGES.
Click to expand...
Click to collapse
Sent from my SCH-I500 using XDA App
Yeah the guide is highly confusing but ill attempt to decipher it lol. As of now though ill just run the liveoc at %110
And once again thanks for the help, trying to figure it out on my own was driving me nuts
Djp2012 said:
Yeah the guide is highly confusing but ill attempt to decipher it lol. As of now though ill just run the liveoc at %110
And once again thanks for the help, trying to figure it out on my own was driving me nuts
Click to expand...
Click to collapse
I use 110%, stock voltages, and the 1200 max step
Sent from my SCH-I500 using xda premium
whats the downside to just using voltage control and keeping it simple?
droidstyle said:
whats the downside to just using voltage control and keeping it simple?
Click to expand...
Click to collapse
No downside that I can tell
Terminators run on Android
The downside is that it's just utilizing extra frequency steps for CPU overclocking as opposed to being able to fine-tune BUS (CPU+GPU+RAM) speed.
droidstyle said:
whats the downside to just using voltage control and keeping it simple?
Click to expand...
Click to collapse
A bottleneck in the buss.. The old glitch v13 overclocked the buss for you. Check the op in the v13 thread. In this kernel by just overclocking cpu I'm sure your bound to not have an efficient setup as the gpu and buss and ram will be stock
Sent from my SCH-I500 using xda premium
Think of a Manure spreader flinging crap against a brick wall, you're manure is your data, the brick wall is your bottle neck.. Well your bottle neck had a 1 foot hole in it. That's your throughput. You speeding up your spreader without making that hole bigger gives you a wall o' ****.
Just because your overclocking to 1.5ghz dont Mean you'll process any more any quicker.. I can use a performance governer and oc to 1.8 GHz then lock my screen.. What does that give me? A battery sucker that is not throughputing the amount of info the step I'm on suggests i could be
Sent from my SCH-I500 using xda premium
currently 14hrs run time @ 42% battery, 2hrs screen on time. seems fairly efficient and fast idk. I was running nstools and using live oc with no issues previously, but i noticed no improvement over using voltage control. i guess ill switch back to nstools and give live oc another go.
droidstyle said:
currently 14hrs run time @ 42% battery, 2hrs screen on time. seems fairly efficient and fast idk. I was running nstools and using live oc with no issues previously, but i noticed no improvement over using voltage control. i guess ill switch back to nstools and give live oc another go.
Click to expand...
Click to collapse
To tell you the truth, i don't think any overclock will make a noticeable difference. These ics roms with the glitch kernel are so fast to begin with. But when it comes to heavy apps i know you won't see the performance of v13 just using vc. Because v13 overclocked the buss/gpu.
And i had 84% battery after 10 hours today. With at least an hour of screen on. But I'll keep track tomorrow with some screenies if you want to compare
Sent from my SCH-I500 using xda premium
Hello,
I'm writing this thread to know which processor options would be optimal in our minis. The best settings, which give me the best performance/battery, I've found are:
CPU Governor: SMARTASSV2 (Default)
Min Freq: 19MHz
Max Freq: 748MHz
Undervolt: TRUE
I'm also using Apex Launcher. Which settings are you using?
Note: This are just my results, be careful when you change your processor settings.
fuchini said:
Hello,
I'm writing this thread to know which processor options would be optimal in our minis. The best settings, which give me the best performance/battery, I've found are:
CPU Governor: SMARTASSV2 (Default)
Min Freq: 19MHz
Max Freq: 748MHz
Undervolt: TRUE
I'm also using Apex Launcher. Which settings are you using?
Note: This are just my results, be careful when you change your processor settings.
Click to expand...
Click to collapse
Whats the purpose of Undervolting when you have it's max frequency as overclock?
zvdelossantos said:
Whats the purpose of Undervolting when you have it's max frequency as overclock?
Click to expand...
Click to collapse
Because it undervolts on every frequency below 600, and his minimum is 19, so when the phone is idle or doesn't need all of the processing power he saves battery
The SmartAss governor is very good at picking the right frequencies for any given job, so it doesn't allways run on 748Mhz, not even when you're using the phone.
SmG67 said:
because it undervolts on every frequency below 600, and his minimum is 19, so when the phone is idle or doesn't need all of the processing power he saves battery
Click to expand...
Click to collapse
That is the same very purpose of SMARTASSV2 to undervolt your device when idle or on sleepmode and overclocks it when on process. So ticking the undervolt wont affect your device because the one that manage the frequency will be the COUgovernor.
zvdelossantos said:
That is the same very purpose of SMARTASSV2 to undervolt your device when idle or on sleepmode and overclocks it when on process. So ticking the undervolt wont affect your device because the one that manage the frequency will be the COUgovernor.
Click to expand...
Click to collapse
The SmartAss Governor only governs the frequencies, not the voltage that the Processor uses. there is a difference between the speed the cpu runs on (Mhz) and the amount of Electricity (Volts) it gets fed
Say Qualcomm has said it needs 5 volts to run at the stock frequency of 600Mhz, then the processor will always get 5 Volts, no matter which frequency it uses.
Undervolting will feed it less than the 5Volts when the frequencies are lower, SmartAss won't do that, it will run the 19Mhz still on 5Volts.
(Voltages are examples, i don't know the exact values, but I know that running on 122 or less will be stable on less than half of the nominal power)
SmG67 said:
The SmartAss Governor only governs the frequencies, not the voltage that the Processor uses. there is a difference between the speed the cpu runs on (Mhz) and the amount of Electricity (Volts) it gets fed
Say Qualcomm has said it needs 5 volts to run at the stock frequency of 600Mhz, then the processor will always get 5 Volts, no matter which frequency it uses.
Undervolting will feed it less than the 5Volts when the frequencies are lower, SmartAss won't do that, it will run the 19Mhz still on 5Volts.
(Voltages are examples, i don't know the exact values, but I know that running on 122 or less will be stable on less than half of the nominal power)
Click to expand...
Click to collapse
Nice yes yes. good reply. now I know whats the use of undervolting. thanks for the explanation
SmG67 said:
The SmartAss Governor only governs the frequencies, not the voltage that the Processor uses. there is a difference between the speed the cpu runs on (Mhz) and the amount of Electricity (Volts) it gets fed
Say Qualcomm has said it needs 5 volts to run at the stock frequency of 600Mhz, then the processor will always get 5 Volts, no matter which frequency it uses.
Undervolting will feed it less than the 5Volts when the frequencies are lower, SmartAss won't do that, it will run the 19Mhz still on 5Volts.
(Voltages are examples, i don't know the exact values, but I know that running on 122 or less will be stable on less than half of the nominal power)
Click to expand...
Click to collapse
nice to see some piece of truth over here (not perfect, but well explained)
de-noobing is good from time to time
xda is overcrowded of false answers given by people thinking they know but don't
anywhere, at anytime, newbies asking get fake answers from people wanting to help but failing to do so , due to lack of knowledge.
as everyone, i might be one of these, but try not to be.
make sure you know what you are talking about before spreading your (incomplete or false) knowledge
this was my thought of the day
matmutant said:
nice to see some piece of truth over here (not perfect, but well explained)
de-noobing is good from time to time
xda is overcrowded of false answers given by people thinking they know but don't
anywhere, at anytime, newbies asking get fake answers from people wanting to help but failing to do so , due to lack of knowledge.
as everyone, i might be one of these, but try not to be.
make sure you know what you are talking about before spreading your (incomplete or false) knowledge
this was my thought of the day
Click to expand...
Click to collapse
Would you mind to add that to FAQs to avoid false answers?
Tom.K said:
Would you mind to add that to FAQs to avoid false answers?
Click to expand...
Click to collapse
of course i don't
do you mean only the explanation about oc/uv ?
i can add it, note that a while ago i wrote pieces of information about those things
Hey, thanks a lot for all the replies. I had no idea why my settings worked like i wanted.
The lowest CPU frequency my device can use is 800 MHz, which seems rather high. Lower frequencies are not even listed in apps like BBS. Can anybody confirm this or is it just me?
Since my device is completely stock and not even rooted, this seems to be the intended behavior by Samsung, but the battery suffers because of this quite a bit - the standard lowest frequency of the Snapdragon 410 (my device is G357FZ) should be around 300 MHz.
I´ve also noticed that all four CPU cores are always online.
Can somebody please reply whether this is the standard behavior, or if there is something wrong with my phone? Thanks.
knizmi said:
The lowest CPU frequency my device can use is 800 MHz, which seems rather high. Lower frequencies are not even listed in apps like BBS. Can anybody confirm this or is it just me?
Since my device is completely stock and not even rooted, this seems to be the intended behavior by Samsung, but the battery suffers because of this quite a bit - the standard lowest frequency of the Snapdragon 410 (my device is G357FZ) should be around 300 MHz.
Click to expand...
Click to collapse
your best off rooting and using setcpu to change it