Overclocking


915 posts   Page 3 of 37   1, 2, 3, 4, 5, 6 ... 37
by shalo » Fri Jun 15, 2012 9:25 pm
I'll have another go at this. So far I have gone 840/275/440 with no overvolting with no issues but anyway.

I've noticed a number of people are overclocking the gpu and using gpu_freq which I'm not sure I really follow to be honest. It seems there is more mileage in the subset of settings. I assume there isn't much point to altering h264_freq or isp_freq currently. This leaves v3d_freq and core_freq.

As someone not currently playing q3 or using any 3d features, I presume I have no need to alter the v3d_freq. The core_freq on the other hand will affect my CPU use since this will help out when there is L2 cache on the GPU access from the CPU. Correct?

Now, there's postings saying gpu_freq is likely to be unstable at some of the values listed in quake3? But dom said he is running with core_freq at 500mhz, which is double the 250mhz stock?

So I guess two questions. Was that correct, or was it a duplication of the ram speed? Is that realistic? and as someone not using the 3d features or indeed video decoding currently should I be looking to just find the limit of core_freq and is such a high overclock more likely if I only really using it in the way mentioned.

I guess I'll find out soon enough but I'm nailing down some other issue I am having currently and I am interested in a heads up. Cheers.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by dom » Fri Jun 15, 2012 10:00 pm
You will have faster overall performance with core_freq=500 and the othe GPU freqs left at 250,
than with gpu=350.

core_freq includes the L2 cache and several of the clock cycles to SDRAM, so increasing this is good for the ARM.

Note: all GPU freqs come from a single PLL with separate fractional dividers.
This basically means you should make all GPU freqs the same or integer multiples.
If core_freq=500 and v3d_freq=300, the v3d will get a mixture of 2ns and 4ns pulses, so will actually fail in the same way as running it at 500. Run it at 250 and all pulses will be 4ns which is fine.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4030
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by shalo » Fri Jun 15, 2012 10:15 pm
dom wrote:You will have faster overall performance with core_freq=500 and the othe GPU freqs left at 250,
than with gpu=350.

core_freq includes the L2 cache and several of the clock cycles to SDRAM, so increasing this is good for the ARM.

Note: all GPU freqs come from a single PLL with separate fractional dividers.
This basically means you should make all GPU freqs the same or integer multiples.
If core_freq=500 and v3d_freq=300, the v3d will get a mixture of 2ns and 4ns pulses, so will actually fail in the same way as running it at 500. Run it at 250 and all pulses will be 4ns which is fine.


Thanks, that is really good to know and exactly what I was looking for.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Lob0426 » Fri Jun 15, 2012 11:59 pm
Thanks @dom for explaining that. If the other settings are divisors then good old round numbers are going to be better. 300 instead of 315.
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1935
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by shalo » Sat Jun 16, 2012 12:51 am
Lob0426 wrote:Thanks @dom for explaining that. If the other settings are divisors then good old round numbers are going to be better. 300 instead of 315.


You haven't really specified which numbers you are talking about. If you are talking about gpu_freq then 315 is better than 300. If you are talking about another setting, then we need to know which and what it compares to because it is not as simple as even numbers.

The approach to take appears to be to decide from the outset which circumstance you want to get the performance from. If you want CPU performance then you should set core_freq as high as stably possible and work back from this figure to get v3d as a round fraction of that core_freq. This is why he specifies 500 as the core and he leaves the others at the default of 250.

If however you are concerned with 3d performance as priority, then you probably want to set v3d as high as possible but now you need to ensure the value chosen plays nicely with the core figure.

Hypothetically if core_freq is ok up to 530mhz and v3d_freq is ok up to 330mhz, you would either set the core and v3d to 330mhz for 3d performance or the core to 530mhz and v3d to half that at 265mhz for cpu performance. As you move away from a direct fraction of the core, you will be getting differing numbers of pulses that are the equivalent of running v3d at either the same speed or half speed of the core. As you can see 300 is not inherently a better number than 315 unless it specifically relates to a core of 600.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Flojer0 » Sat Jun 16, 2012 2:30 am
As I understand it a decreased lifespan due to overvolting is caused by electromigration:

http://en.wikipedia.org/wiki/Electromigration

When you increase the voltage the speed at which materials will move around increases. At normal operating levels a chip will last years but some chips if overvolted too far can fall to days or even hours. Heat also contributes to electromigration, lower temps slow it down, higher will speed it up.

the 1st reply in this thread by CTho9305 has a very good explanation (found through google):

http://forums.anandtech.com/showthread.php?t=116058

I'm not an electrical engineer, but I've dabbled with overclocking. I wasn't considering overclocking my pi (not here yet, acouple more weeks) but if a community is forming around it I might be tempted to give it a try.

one more thing, I don't know how much good it will do without a heatsink but a small fan blowing on the board could go a long way to removing hot air and lowing the temperature.
Posts: 31
Joined: Sun Jun 10, 2012 8:10 am
by Lob0426 » Sat Jun 16, 2012 6:34 am
dom wrote:You will have faster overall performance with core_freq=500 and the othe GPU freqs left at 250,
than with gpu=350.

core_freq includes the L2 cache and several of the clock cycles to SDRAM, so increasing this is good for the ARM.

Note: all GPU freqs come from a single PLL with separate fractional dividers.
This basically means you should make all GPU freqs the same or integer multiples.
If core_freq=500 and v3d_freq=300, the v3d will get a mixture of 2ns and 4ns pulses, so will actually fail in the same way as running it at 500. Run it at 250 and all pulses will be 4ns which is fine.


@shalo: i was referrring to @dom post. the numbers were for gpu_freq. he states it is better to use the default of 250, then using core_freq=500. the other freq are divisors of core. So something like 315 comes out at a decimal value rather than a non decimal value. This causes it to hunt between 2ns and 4ns pulses. It is best if it just runs at one or the other not trying to run at both..
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1935
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by dom » Sat Jun 16, 2012 8:54 am
Lob0426 wrote:@shalo: i was referrring to @dom post. the numbers were for gpu_freq. he states it is better to use the default of 250, then using core_freq=500. the other freq are divisors of core. So something like 315 comes out at a decimal value rather than a non decimal value. This causes it to hunt between 2ns and 4ns pulses. It is best if it just runs at one or the other not trying to run at both..


What shalo wrote is completely correct. For maximum overlock, the only interesting values for v3d_freq are core_freq or core_freq/2.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4030
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by JollyRoger » Sat Jun 16, 2012 9:04 am
My Pi won't run with core_freq set to 500. So I've set it to what was earlier suggested:
arm_freq=850
gpu_freq=325
sdram_freq=500
This gives a respectable improvement in performance with no apparent ill effects. I've been running it with these settings for a couple of hours now and can't detect any overheating.
Posts: 154
Joined: Wed Feb 01, 2012 9:48 am
by shalo » Sat Jun 16, 2012 2:04 pm
JollyRoger wrote:My Pi won't run with core_freq set to 500. So I've set it to what was earlier suggested:
arm_freq=850
gpu_freq=325
sdram_freq=500
This gives a respectable improvement in performance with no apparent ill effects. I've been running it with these settings for a couple of hours now and can't detect any overheating.


You don't say what you have been doing for a couple of hours or what your aim is. If you aren't stressing the 3d performance then you don't really know if gpu_freq is stable at all.

Your settings don't show overvolting and dom is overvolting his pi, which probably makes sense if you want to go from 250 core to 500 core on the gpu. As an aside I would assume from reading other experiments that his pi might actually be "stable" if he ran gpu_freq at 500mhz but only if he didn't try to actually use the 3d block/h264/camera interface.

You have to experiment to find your own limits (and there will be two limits. One where gpu_freq is as high as possible and stable in 3d performance et al and another limit where core_freq is as high as possible and other settings are half (or 1/3rd if you desire and manage to reach 501mhz, 504mhz core etc) that of core_freq and again stable in 3d performance et al.

It sounds counter-intuitive but Quake 3 as an example might benefit by prioritising the CPU in this way. The pi has a very powerful gpu and an underpowered cpu. Think back to how we played that game originally. We wanted the highest fps possible. The gpu is kind of overkill and the cpu will be the limiting factor. You can even compound this disparity. Remember turning off all the dynamic lighting and anti-aliasing and playing at 640x480 to improve both performance and visibility? This probably holds up now. We're on a modern gpu that is way overkill but our cpu is actually slower than the overclocked 300mhz celeron A we were all using at the time. Timerefresh and possibly the default timedemo would probably benefit from gpu performance but load up crusher demo and you'll be soooo cpu limited that underclocking the v3d_freq to get a high core_freq to eek out more cpu performance is desirable because you are seeking not to get the highest average or peek framerate in quake 3 but to get the highest minimum framerate.

I rambled enough.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Lob0426 » Sun Jun 17, 2012 5:16 am
So the question is, if gpu_freq is left at 250 and I push up the core frequency to 375 am I in the right ballpark or not. I have not overvolted. This would be a raise of 1/3 of default GPU value, or am I going in the wrong direction?
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1935
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by shalo » Sun Jun 17, 2012 12:50 pm
Lob0426 wrote:So the question is, if gpu_freq is left at 250 and I push up the core frequency to 375 am I in the right ballpark or not. I have not overvolted. This would be a raise of 1/3 of default GPU value, or am I going in the wrong direction?


Well, in that case gpu_freq can pretty much be ignored. By setting the core frequency to 375, you leave the 3d block, h264 and image sensoring in the odd situation.

Here is another way to think about it:
The core is running at 375mhz, which with 1000ms in a second means a pulse every ~2.67ms.

The 3d/h264/image processing running at 250mhz has trouble playing nicely with this. Ideally these would want a pulse every (1000ms/250mhz) 4ms. But this isn't an option since the pulses are fixed by the core at 2.67ms. Eg: You will now get a mixture of pulses at either ~2.67ms or ~5.34ms that average out at the desired 4ms. If this is stable, you might as well run these blocks at entirely 2.67ms pulses in the first place. Eg: 375mhz.

The caveat to this is presumably that gpu_freq and core_freq are somewhat interchangeable, if you are not using the 3d/h264/image sensing at all.

If you are running core_freq at 375mhz then you really only have ~two options for v3d/h264/isp and these are either 375 (which may or may not work if you are actually using these blocks) or 187.5mhz, which is exactly half the core.

Conversely if you are running gpu_freq/not specifying it at the default of 250mhz, then you only really have two interesting choices for the core_freq. Eg: 250mhz or 500mhz (exactly double).

If you look back in the thread, you will see "mcfundash" is running a gpu_freq at 538mhz and then dom doubting this will work in a 3d application. This is what made me curious in the first place for a number of reasons. But what mcfundash will presumably need to do, if he wants to actually use the gpu for 3d/h264 is change his settings.

Instead of gpu_freq = 538 (and thus all the other blocks at 538mhz also)
He should do core_freq = 538
v3d_freq and h246_freq should probably be specified at 269mhz.

This would leave him with the improved cpu performance and presumably a stable 3d/h264 if he were to actually use them. Say for some reason it were still unstable in 3d because of the 19mhz overclock, he could still do something like a core of 537mhz and then v3d/h264 at 179mhz (exactly 1/3rd) though this is an unlikely scenario.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Lob0426 » Sun Jun 17, 2012 3:52 pm
@Shalo: highest stable core_freq for me is at 350. No over volt. Quake3 appears to run fine at this, but have only played a couple of minutes so far. Anything higher and I have shutdown problems in LXDE. I was running just gpu_freq at this before. So leave all at 350 since they are all derived from core? Do you have specify for each or will they all follow core? And then you specify, say 3d if you are having crashes in quake3 or other 3d?

Is it possible to come up with a table of compatible frequency timings as a guide for Overclocking the GPU?

It appears, to get much out of the GPU, you will need to overvolt.
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1935
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by shalo » Sun Jun 17, 2012 4:19 pm
Lob0426 wrote:@Shalo: highest stable core_freq for me is at 350. No over volt. Quake3 appears to run fine at this, but have only played a couple of minutes so far. Anything higher and I have shutdown problems in LXDE. I was running just gpu_freq at this before. So leave all at 350 since they are all derived from core? Do you have specify for each or will they all follow core? And then you specify, say 3d if you are having crashes in quake3 or other 3d?

Is it possible to come up with a table of compatible frequency timings as a guide for Overclocking the GPU?

It appears, to get much out of the GPU, you will need to overvolt.


You have the settings slightly mixed. You can use gpu_freq in isolation of all other settings. Whatever you set this to, each function of the gpu and the gpu core itself will run at. So 350 will run everything on the gpu at 350. The caveat here, is that if you are not using the 3d/h264 at all, you have no idea if this setting is stable for those features.

The second option involves not using gpu_freq at all. Now you have core_freq as the core speed, you will then need to set each of the other options: v3d_freq, h264_freq and isp_freq separately. To keep things simple the only options for these three settings should either be the same as core_freq or exactly half of core_freq. There is no sense leaving these settings at the default of 250mhz UNLESS you are running the core_freq at either 250mhz or 500mhz.

It's perfectly safe to stick with setting a gpu_freq to be honest, as long as you are stressing all the features you use.

The only reason this is of particular interest is the observation that the core can be run much faster than the 3d block et al and this will benefit the CPU because of how it is attached to the GPU. But in order to ramp up the core speed beyond the 3d et al, you have to set these subsettings properly if you use them at all.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Yoriku » Mon Jun 18, 2012 7:26 pm
Are all clocks based on the same PLL or just certain sets? Which freq's are tied together?
Posts: 3
Joined: Mon Jun 18, 2012 7:24 pm
by dom » Tue Jun 19, 2012 9:22 am
Yoriku wrote:Are all clocks based on the same PLL or just certain sets? Which freq's are tied together?


There are 3 independent PLLs of interest here. Arm. Sdram. GPU.
(where GPU PLL drives core, h264, v3d, ISP).

I could split GPU core from h264/v3d/ISP which would allow more control of overclock, but I need to take a PLL from elsewhere. The analogue PWM audio is the obvious choice. (there is also one used by hdmi/composite).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4030
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Bjarkeah » Tue Jun 19, 2012 3:11 pm
arm_freq=1100
core_freq=500
sdram_freq=400
over_voltage=6 (1,35 v)

These are my best stable results so far. Have been running quite a bunch of cpu-intensive stuff on it, and it does get somewhat hot. I put a little heatsink on it, but of course I don't know the specific temps. sr_ram overclocks at 500 or even 450 are very unstable. But I don't think there's too much sense in getting the ram- and gpu-frequencies up, as they don't seem to be bottlenecks. Therefore I'm only focusing on the cpu_freq - that's the one really making a difference when using this little gem.
Raspi @ 1100 mhz
3,5" LCD @ 640x480
8 gb class 6
User avatar
Posts: 5
Joined: Tue Jun 19, 2012 3:03 pm
Location: Denmark
by zeeteex » Wed Jun 20, 2012 1:01 pm
I just hit

arm_freq=1100
sdram_freq=600
core_freq=300
over_voltage=6

Core doesn't like going up much on mine... But just ran an hours worth of video playback using xbmc and it worked really well, more responsive than usual. Although it does get a tad hotter, its no problem.
Raspi
arm_freq=1150
sdram_freq=600
gpu_freq=500
over_voltage=8
Posts: 43
Joined: Sun Dec 25, 2011 10:59 am
by shalo » Wed Jun 20, 2012 1:13 pm
zeeteex wrote:I just hit

arm_freq=1100
sdram_freq=600
core_freq=300
over_voltage=6

Core doesn't like going up much on mine... But just ran an hours worth of video playback using xbmc and it worked really well, more responsive than usual. Although it does get a tad hotter, its no problem.


Now I am a sad panda :(
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by zeeteex » Wed Jun 20, 2012 2:00 pm
shalo wrote:Now I am a sad panda :(


Tough little pi :D
Raspi
arm_freq=1150
sdram_freq=600
gpu_freq=500
over_voltage=8
Posts: 43
Joined: Sun Dec 25, 2011 10:59 am
by shalo » Wed Jun 20, 2012 2:51 pm
zeeteex wrote:
shalo wrote:Now I am a sad panda :(


Tough little pi :D


When you mention enpassant that "it doesn't like a high core" you make me a sad panda.

Currently when you are watching videos with xbmc you are doing so with a mixture of 150mhz 1/3rd of the time and 300mhz 2/3rds of the time. You might as well just run it at 300mhz with gpu_freq instead, it's all explained on this page in quite some detail. Just stick to using gpu_freq if you aren't sure what you are doing currently :(
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by Herbi » Thu Jun 21, 2012 7:15 pm
I just started to overclock my Pi. Do you have any advice on benachmark the outcome of the overclocking and performing a stress test?
I also wanted to overclock the Pi when running OpenELEC. Should I overclock the core_freq or gpu_freq to get best results for video playback?
Posts: 1
Joined: Tue Jun 19, 2012 10:59 am
by Lob0426 » Mon Jun 25, 2012 10:16 pm
gpu_freq overclocks all of the GPU related stuff. core_freq raises the core and the cache speed, but then you have to set your gpu at 1/2 or 1/3 of the core_freq speed. I am sticking with gpu_freq for now. So far stable at 325. No overclock yet.

Hopefully @shalo: or @dom: will weigh in they seem to understand the core_freq details. I am still trying to get it straight. :oops:
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1935
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by Wozza63 » Tue Jun 26, 2012 8:20 am
Hi guys, I got my RPi yesterday and one of the first things I tried was overclocking I did all what was said in the tutorial on the previous page but I get no difference in benchmark times, does anyone know why? These are the steps I took
Open Terminal
Code: Select all
sudo nano /boot/config.txt

Code: Select all
arm_freq=800

Code: Select all
sdram_freq=500


Ctrl X and then Y and then press enter to finish saving it

then sudo reboot and then once i log in i redo the benchmark and its no different, done it multiple times but no different
Posts: 11
Joined: Tue Jun 26, 2012 8:08 am
by zeeteex » Tue Jun 26, 2012 9:04 am
Wozza63 wrote:then sudo reboot and then once i log in i redo the benchmark and its no different, done it multiple times but no different


How are you measuring your benchmark?
Raspi
arm_freq=1150
sdram_freq=600
gpu_freq=500
over_voltage=8
Posts: 43
Joined: Sun Dec 25, 2011 10:59 am