Overclocking

[Trixster]

925mhz here with no overvolt, perfectly stable. Pretty pleased with that.

[lapoltba]

Running Xbian (XBMC) on my Pi. It was rather sluggish and menus took forever to load.
Overclocked today for the first time:

over_voltage = 4
arm_freq = 1000
sdram_freq = 500
gpu_freq = 500
core_freq = 500
h264_freq = 500
isp_freq = 500
v3d_freq = 500

Seemed stable for now. I may try dropping the voltage a bit. What a difference it made. Menus are much snappier and boot is about half the time it was before. Amazing what this little board can do.

[Lob0426]

Running Xbian (XBMC) on my Pi. It was rather sluggish and menus took forever to load.
Overclocked today for the first time:

over_voltage = 4
arm_freq = 1000
sdram_freq = 500
gpu_freq = 500
core_freq = 500
h264_freq = 500
isp_freq = 500
v3d_freq = 500

Seemed stable for now. I may try dropping the voltage a bit. What a difference it made. Menus are much snappier and boot is about half the time it was before. Amazing what this little board can do.

Though there is technically nothing wrong with your settings! You would get the same effect with:
over_voltage=4
arm_freq=1000
sdram_freq=500
gpu_freq=500

core_freq, h264_freq, isp_freq and v3d_freq are tied together under gpu_freq when it is used.

[lapoltba]

The only reason I didn't do that was because I had changed one at some point and wasn't sure if it was loaded every time or if it was "sticky". Wasn't sure if it would configure properly with only GPU_FREQ.

As of this morning I have been running for several hours with Over_voltage = 2 with no issues.

[wollac11]

Mine will boot and run arm_freq up to a max of 985MHz at stock voltage. I haven't tried overvolting yet but at stock voltage any more than 985 will just refuse to boot. However, more than 960 can cause issues on occasion when running intensive tasks for a long while so I run at 950 at which is is rock solid.

The gpu_freq will go up to 550 (that's as much as I've attempted so far) and still boot and seemingly run fine but some games will eventually cause the system to lock up when it's at 500 or 550 so I may need to look into lowering that setting until I find an overclock that's suitable.

The ram seems to be able to overclock endlessly so I'm guessing something is wrong. I started at 500 and worked up to 800 without any issues which made me suspicious so I randomly tried 1400 and guess what? yep, it booted and ran fine! This leads be to believe that something is not right with my pi or it's config because there is no way that the RAM would run at 1000MHz more than the stock frequency. Is there any way I can check this? Maybe a tool that could tell me what it is actually running at?

Also I don't know how much difference it would make in this case but my Pi has the Samsung memory chip rather than the Hynix one.

[MaxK1]

I'm a little hesitant to post this one as things have moved back and forth between my 2 pi's over
the last couple of months, and I can't swear I have everything back the way it was 2 months ago.
Pi #1 overclocked to 920 without overvolting, even on a crappy phone charger. (long since switched to powering via GPIO header due to other "issues") Samsung memory.

Pi #2 would not overclock reliably past 850 when I first got it. Would crash during boot or shortly after.
This one has Hynix memory and also powered through the GPIO header. X was a no-go at 850 as I recall (I received it on June 28 - Tau Day - so I had high hopes for it)

Long story, short version:
Due to "operator error" I wound up booting the SD card from pi #1 in pi #2. And it worked. Yeah, but not for long or so I thought. Built a kernel - no problem. Did it again - no problem. Rebooted new kernel. No problem. Still running fine at 920.

Is there a break in period on memory? They have both been running since I got them, pretty much constantly. I don't want raise any false hopes here for anyone disappointed they couldn't OC as much as they had hoped with Hynix memory...

FWIW, YMMV, "It worked for me", etc.

[lapoltba]

Sounds like a typical computer problem. If something isn't working, turn it off, wait a while, then try again.

Glad you're crunching numbers still!

[shalo]

The gpu_freq will go up to 550 (that's as much as I've attempted so far) and still boot and seemingly run fine but some games will eventually cause the system to lock up when it's at 500 or 550 so I may need to look into lowering that setting until I find an overclock that's suitable.

Have you tried this with Quake3?

The ram seems to be able to overclock endlessly so I'm guessing something is wrong. I started at 500 and worked up to 800 without any issues which made me suspicious so I randomly tried 1400 and guess what? yep, it booted and ran fine! This leads be to believe that something is not right with my pi or it's config because there is no way that the RAM would run at 1000MHz more than the stock frequency. Is there any way I can check this? Maybe a tool that could tell me what it is actually running at?

Also I don't know how much difference it would make in this case but my Pi has the Samsung memory chip rather than the Hynix one.

As mentioned in this thread I'm pretty certain that a number of the Pis with Samsung RAM has the stuff rated for 533mhz which is why they overclock so easily. Also already stated in this thread, all the boards currently have a cap based on a PLL that from my tests are around ~575mhz but certainly under 600mhz for the RAM. Setting it any higher in the config will result in just getting the max allowed by the PLL.

[lapoltba]

Not to rub it in... But here's what i've been running for the past several hours while streaming BBC news....

over_voltage = 0
arm_freq = 1000
sdram_freq = 600
gpu_freq = 550

I just read about the High limit on PLL. Is there any way to check what you are actually running?

I'm going to be trying to bump up the ARM_FREQ and see how high I can get on stock voltage. This $35 piece of Pi is getting more and more awesome every day!

[wollac11]

Have you tried this with Quake3?

No not yet but I'll definitely try getting that installed on my Pi soon and giving it a shot! I'll post back my results once I do

As mentioned in this thread I'm pretty certain that a number of the Pis with Samsung RAM has the stuff rated for 533mhz which is why they overclock so easily. Also already stated in this thread, all the boards currently have a cap based on a PLL that from my tests are around ~575mhz but certainly under 600mhz for the RAM. Setting it any higher in the config will result in just getting the max allowed by the PLL.

Ah okay that makes sense, thank you! I must have just missed earlier mentions of this. Anyway, that's a better case scenario than a feared (whereby it was simply ignoring the overclock for some reason). In that case I'll leave it set on 600 for good measure and that should ensure I get the max out of it.

[MaxK1]

[quote="lapoltba"]Sounds like a typical computer problem. If something isn't working, turn it off, wait a while, then try again.

Ah yes - The Microsoft approach. Glad they don't build passenger jets...

And pi # 2 is still happy at 920. Wish I had kept better notes from when I tested 2 + months ago.

[shalo]

I just read about the High limit on PLL. Is there any way to check what you are actually running?

You can only really test it. The difference in memory bandwidth from 550 to 600 appears to be marginal though does seem to exist. I believe dom was going to look into it and see what the exact situation is but I doubt it is high priority. The only time you tend to see any difference is in synthetic benchmarks anyway.

Ah okay that makes sense, thank you! I must have just missed earlier mentions of this. Anyway, that's a better case scenario than a feared (whereby it was simply ignoring the overclock for some reason). In that case I'll leave it set on 600 for good measure and that should ensure I get the max out of it.

Just remember to check when new firmware comes out that the limit wasn't sneakily removed and that it is stable at 600.

[ricsi]

here are my settings:
arm_freq=1000
sdram_freq=500
core_freq=375
over_voltage=6

They seem to be stable in Quake3.
The only problem I have is that the sound dies sometimes. Meaning that the pi is accessible via SSH and continues to run quake, but there is no sound, or only small pieces here and there. the rest is silence.

I hope GPU is OK: 2*375 =PLL /3 = 250 GPU Freq
tried below, settings, but they were not stable (other settings as above)
#core_freq=390
#h264_freq=260
#isp_freq=260
#v3d_freq=260

Also SDRAM clocking is veeeery strange. I seem to have samsung, and I get this results with the mem bench posted here:
RAM 400MHz
C copy : 190.95 MB/s
C copy via tmp buffer : 165.98 MB/s
standard memcpy : 357.96 MB/s
ARM copy prefetched : 357.71 MB/s


RAM 450MHz
C copy : 187.67 MB/s
C copy via tmp buffer : 165.90 MB/s
standard memcpy : 359.46 MB/s
ARM copy prefetched : 351.33 MB/s

RAM 500MHz
C copy : 189.88 MB/s
C copy via tmp buffer : 166.01 MB/s
standard memcpy : 384.74 MB/s
ARM copy prefetched : 364.01 MB/s

RAM 550MHz
C copy : 180.34 MB/s
C copy via tmp buffer : 165.61 MB/s
standard memcpy : 361.19 MB/s
ARM copy prefetched : 384.26 MB/s

RAM 600MHZ
C copy : 188.30 MB/s
C copy via tmp buffer : 164.26 MB/s
standard memcpy : 385.12 MB/s
ARM copy prefetched : 364.03 MB/s

Any ideas why??

BTW I like my pi ... great little playground

Interestingly it can even power a keyboard wireless dongle and a WiFi Dongle with a Galaxy S3 PSU.
http://www.dealextreme.com/p/102969

[shalo]

<Q3, gpu, ram>

On quake3 with sound, you can use the ingame command at the console /snd_restart I remember it being a touch flakey when using analogue audio at times. Usually requiring a /snd_restart soon after launch.

Your gpu observations match mine also. I find almost no way leeway on the gpu_freq and yet core_freq at 375 (500 is actually fine on my pi with over_voltage 6).

Those ram benches look like a setting hasn't taken. Assuming no typo on sdram_freq in your config it does seems strange.

Something I neglected to mention with my chart were that they were all headless, when I run a 1080p display there is less memory bandwidth.

[dom]

Also SDRAM clocking is veeeery strange. I seem to have samsung, and I get this results with the mem bench posted here:
...
Any ideas why??

How big is the buffer membench uses?
Note: there is a 128K L2 cache in between the ARM and SDRAM. If the test uses less RAM than that, then SDRAM will not be accessed...

[ricsi]

I did my tests with HDMI enabled (1280x768) 60Hz

It indeed looks like sdram freq is not taken over.
I have this in my config.txt:
#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1000
sdram_freq=200
core_freq=375
#core_freq=390
#avoid_pwm_pll=1
#h264_freq=260
#isp_freq=260
#v3d_freq=260
over_voltage=6

I tried the benchmark and got below results (for supposedly 200 MHz SDRAM Freq).
So it seems the pi has 16KB L1 and 128KB L2 cache.

Any idea why it ignores the sdram_freq??
All other frequencies seem to work as expected!


ssvb-membench v0.1.9 (simple benchmark for memory throughput and latency)

===================================================================
== Memory bandwidth tests (non-aliased buffers) ==
== ==
== Note 1: 1MB = 1000000 bytes ==
== Note 2: Results for 'copy' tests show how many bytes can be ==
== copied per second (adding together read and writen ==
== bytes would have provided twice higher numbers) ==
===================================================================

C copy backwards : 154.17 MB/s
C copy : 190.89 MB/s
C copy prefetched (32 bytes step) : 295.37 MB/s
C copy prefetched (64 bytes step) : 306.98 MB/s
C copy via tmp buffer : 162.47 MB/s
x C copy via tmp buffer prefetched (32 bytes step) : 183.95 MB/s C copy via tmp buffer prefetched (64 bytes step) : 179.79 MB/s
C fill : 195.74 MB/s
---
standard memcpy : 364.71 MB/s
standard memset : 1687.00 MB/s
---
ARM fill (STRD) : 195.84 MB/s
ARM fill (STM with 8 registers) : 1399.68 MB/s
ARM fill (STM with 4 registers) : 1431.62 MB/s
ARM copy prefetched : 381.57 MB/s

==========================
== Memory latency test ===
==========================

block size : read access time (single random read / dual random read)
2 : 0.1 ns / 0.0 ns
4 : 0.0 ns / 0.0 ns
8 : 0.0 ns / 0.0 ns
16 : 0.0 ns / 0.0 ns
32 : 0.0 ns / 0.0 ns
64 : 0.0 ns / 0.0 ns
128 : 0.0 ns / 0.0 ns
256 : 0.0 ns / 0.0 ns
512 : 0.0 ns / 0.0 ns
1024 : 0.0 ns / 0.0 ns
2048 : 0.0 ns / 0.0 ns
4096 : 0.0 ns / 0.0 ns
8192 : 0.0 ns / 0.0 ns
16384 : 3.5 ns / 3.5 ns
32768 : 24.8 ns / 15.8 ns
65536 : 39.0 ns / 32.3 ns
131072 : 53.8 ns / 66.9 ns
262144 : 120.4 ns / 168.9 ns
524288 : 211.5 ns / 341.8 ns
1048576 : 232.9 ns / 413.5 ns
2097152 : 273.9 ns / 456.6 ns
4194304 : 260.9 ns / 484.0 ns
8388608 : 288.1 ns / 490.2 ns
16777216 : 299.4 ns / 508.5 ns
33554432 : 312.4 ns / 549.8 ns
67108864 : 354.9 ns / 628.7 ns

[shuckle]

The new kernel version and the usb patch are impressive.

I did the 2000 test with vanilla rasbian 3.1.9:
time echo "scale=2000;4*a(1)" | bc -l
real 0m26.488s
user 0m26.360s
sys 0m0.030s

and then again after upgrading to kernel 3.2.27:
real 0m25.009s
user 0m24.940s
sys 0m0.020s

and then using the usb-fix (dwc_otg.fiq_fix_enable=1):
real 0m23.727s
user 0m23.660s
sys 0m0.010s

That is 10% better compared to the starting point without any tuning.

My latest result with the following overclocking:
arm_freq=900
sdram_freq=500
gpu_freq=400
#BogoMIPS : 898.66


real 0m18.213s
user 0m18.160s
sys 0m0.010s

That is not bad at all and that is without over voltage, so it should be safe and it certainly seems to be stable.

[Pihkal]

Hi,

quick question:

do the core_freq and arm_freq have to be related?
As i understand it,they don't but i'm confused with everybody talking about pll and dividers.
Also if i raise my core freq just a little (50 Mhz) the pi crashes.
I'm now running at

• over_voltage=6
  arm_freq=1000

Greetz

[dom]

do the core_freq and arm_freq have to be related?

No.

[dom]

Latest firmware changes the PLL frequency used.
The PLL is set to the largest N such that core_freq*2*N <= 2.4G. This should give a bit more freedom when choosing the h264/isp/v3d clock.
Also, I force the fractional bits of the divisor for h264/isp/v3d to 0, meaning you always get an integer divisor.
This alows combinations like:
core_freq=500 # PLL=2000
gpu_freq=333 # will now use a divisor of 6, rather than 6.0006 which results in a non uniform clock period

In fact it rounds to nearest even integer, so asking for gpu_freq=300 will result in divisor of 2000/300 = 6.666 => 6 and so 333.33MHz
(Note in past you would have got on average 300MHz, based on a mixture of 333.33MHz and 250MHz pulses which has no advantages over 333.33MHz).

I'm not sure if the change in PLL freq has an effect on max overclock possible. If it does please report what the highest reliable overclock was before and after this change.

[shalo]

Latest firmware changes the PLL frequency used.
The PLL is set to the largest N such that core_freq*2*N < 2.4G.

In fact it rounds to nearest even integer, so asking for gpu_freq=300 will result in divisor of 2000/300 = 6.666 => 6 and so 333.33MHz

I'm just going to go ahead and reiterate, it can't hurt.

1. Your PLL will be set from your core_freq. So once you have set your core_freq in your config you will now know your PLL from that first formula.

2. Now you have your PLL, you can divide it by whatever you have set your gpu_freq in your config as. The answer to this step should be rounded to the nearest even number. Then you should divide your PLL again by this new, even number and that is what your gpu is really running at despite what you have set in your config. At this point, you should probably go back into your config and change the gpu_freq to the nearest integer to this if only to show you understand how it works.


Config example: core_freq=455, gpu_freq=270

1.)
My PLL will be 455 x 2 x 2 = 1820 (x3 would be 2730 and greater than 2400)

2.)
a) 1820 / 270 = 6.74 (so 6, since 7 is an odd number)
b) 1820 / 6 = 303.33...
c) At this point, I should probably go into my config file and change gpu_freq to 303 since that is what I have actually set it at in reality. If nothing else, it will show that I know what I am doing.

[dom]

I'm just going to go ahead and reiterate, it can't hurt.

1. Your PLL will be set from your core_freq. So once you have set your core_freq in your config you will now know your PLL from that first formula.

2. Now you have your PLL, you can divide it by whatever you have set your gpu_freq in your config as. The answer to this step should be rounded to the nearest even number. Then you should divide your PLL again by this new, even number and that is what your gpu is really running at despite what you have set in your config. At this point, you should probably go back into your config and change the gpu_freq to the nearest integer to this if only to show you understand how it works.


Config example: core_freq=455, gpu_freq=270

1.)
My PLL will be 455 x 2 x 2 = 1820 (x3 would be 2730 and greater than 2400)

2.)
a) 1820 / 270 = 6.74 (so 6, since 7 is an odd number)
b) 1820 / 6 = 303.33...
c) At this point, I should probably go into my config file and change gpu_freq to 303 since that is what I have actually set it at in reality. If nothing else, it will show that I know what I am doing.

That sounds correct. I'll see if I can expose a way to actually measure some of these clocks. We have a way on GPU to feed to clock into a counter and see how high it gets in say 1ms.
Something like

Code: Select all

vcgencmd measure_clock V3D
result=303334000

Will allow some sanity tests to be done.

[TarjeiB]

My settings of:

Code: Select all

arm_freq=800
sdram_freq=450
gpu_freq=300

No longer boots with the new firmware. Commenting them all out boots fine, I have not yet done further tests.

*EDIT* Commenting out

Code: Select all

sdram_freq=450

made it work again, was the ram overclock also changed?

[fjen]

Latest firmware changes the PLL frequency used.

i added that to the wiki.
http://elinux.org/RPi_config.txt#For_fi ... _Sep._2012

[dom]

No longer boots with the new firmware. Commenting them all out boots fine, I have not yet done further tests.

*EDIT* Commenting out

Code: Select all

sdram_freq=450

made it work again, was the ram overclock also changed?

No, I don't think SDRAM overclock has changed. How does boot fail - does it do a reboot loop? Stuck at coloured square? Hangs during linux messages?
Does boot_delay=1 affect it?