shalo
Posts: 74
Joined: Tue May 08, 2012 7:25 pm

Re: Overclocking

Fri Jul 20, 2012 8:56 pm

Wolfram23 wrote:This topic is relevant to my interests.

Many people have posted how they raised arm, ram, and core freqs but no mention of gpu freq, so that's why I wonder. If it just sticks to 250 without manual modification, then it seems that it would be less stable with a raised core_freq.
That's pretty much right. Though I would suggest most people have been just using gpu_freq.

Anyone using just core_freq and not applying optimal subsettings are probably not actually using the 3d block et al so not running into issues with the stability or lack of.

Bergie5737
Posts: 17
Joined: Sun Jun 17, 2012 4:09 pm

Re: Overclocking

Fri Jul 20, 2012 9:03 pm

After I did an "rpi-update" my C++ code runs through about 10% less iterations in the same time for my current overclock config. It looks like browsing etc. is a bit faster though. Anyone else see a drop in their "old" benchmarks?

Wolfram23
Posts: 73
Joined: Thu Jul 19, 2012 6:50 pm

Re: Overclocking

Fri Jul 20, 2012 9:07 pm

shalo wrote:
Wolfram23 wrote:This topic is relevant to my interests.

Many people have posted how they raised arm, ram, and core freqs but no mention of gpu freq, so that's why I wonder. If it just sticks to 250 without manual modification, then it seems that it would be less stable with a raised core_freq.
That's pretty much right. Though I would suggest most people have been just using gpu_freq.

Anyone using just core_freq and not applying optimal subsettings are probably not actually using the 3d block et al so not running into issues with the stability or lack of.
Ok, thanks for the clarification. Won't have my RPi for a while but I'm sure I'll fool around with OCing so good to know the right way to do it!

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Fri Jul 20, 2012 9:49 pm

Bergie5737 wrote:After I did an "rpi-update" my C++ code runs through about 10% less iterations in the same time for my current overclock config. It looks like browsing etc. is a bit faster though. Anyone else see a drop in their "old" benchmarks?
What was the previous firmware version?

You can see the kernel version with:
uname -a
and the start.elf version with:
/opt/vc/bin/vcgencmd version

You should have the old files in /boot.bak. Can you try reverting start.elf and kernel.img (one at a time) to confirm which makes a difference.

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.

Re: Overclocking

Sat Jul 21, 2012 12:48 am

Wolfram23 wrote:This topic is relevant to my interests.

Just curious, as this doesn't seem to have been explicitely covered. Dom, and others, have mentioned the way core_freq ties into gpu_freq via an integer dividor of the pll, which is based on the core_freq. So my question is, when you set the core_freq higher, do you not have to adjust the gpu_freq as well? Or if left default, does it simply go by the same integer dividor and therefore is automatically raised with core_freq?

Many people have posted how they raised arm, ram, and core freqs but no mention of gpu freq, so that's why I wonder. If it just sticks to 250 without manual modification, then it seems that it would be less stable with a raised core_freq.
gpu_freq should also be set to an integer divisor if core_freq is used. gpu_freq raises all of the video related frequencies to what it is set at. see comments above for how to figure the correct setting for it.
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
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!

shalo
Posts: 74
Joined: Tue May 08, 2012 7:25 pm

Re: Overclocking

Sat Jul 21, 2012 9:17 am

Lob0426 wrote:This is my current config. Seems to be working fine. I cannot get arm_freq to be stable at 850.
I am trying to get quake or openarena working to test the gpu settings. Trying Quake3 from memetic.org which is supposed to work with raspianhf with sound. Openarena from Synaptic is giving video mode errors.

Code: Select all

arm_freq=800

# pll_freq=Core_freq*2^n if core=480, then pll=960 gpu=320 or 480
# pll must be 600 or more
[b]core_freq=480
gpu_freq=320[/b]
# probably do not need to specify all if gpu_freq specified.
h264_freq=320
v3d_freq=320
isp_freq=320

sdram_freq=500
hdmi_force_hotplug=1
# enable hdmi sound =2
hdmi_drive=2
hdmi_group=2
config_hdmi_boost=4
disable_overscan=1
framebuffer_width=1366
framebuffer_height=768

# settings for Motorola Lapdock
dom wrote:
ZirconiumX wrote:Question to dom: Would core_freq be set to 320 or 480 with this setup?
Both are valid in terms of integer ratios of clocks and PLL.

I'd expect 480 will only work with overvolting, but otherwise pick the highest one that is stable for you.
Lob0426 wrote: gpu_freq should also be set to an integer divisor if core_freq is used. gpu_freq raises all of the video related frequencies to what it is set at. see comments above for how to figure the correct setting for it.
I think you are missing the nuance to his question here and also missing something pretty important. Looking at that config you are specifying core_freq of 480. Then you are specifying gpu_freq of 320 later on in the same config file.

Given that gpu_freq INCLUDES core_freq, you can now see that his question takes on a very different meaning.

When he asks if that config is setting a core_freq of 480 or 320 he is not asking if they are valid, he is asking if your config is correct because it appears you have not set it up properly.

You should probably be specifying gpu_freq FIRST, then later core_freq because currently it appears your core_freq is redundant.

If you read his original post again and look at your config more closely, you'll probably understand why he suggested bumping core to 375 (you have it at 320 not 480) and leaving the others at 250 (which you have at 320).

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Sat Jul 21, 2012 9:30 am

shalo wrote: I think you are missing the nuance to his question here and also missing something pretty important. Looking at that config you are specifying core_freq of 480. Then you are specifying gpu_freq of 320 later on in the same config file.

Given that gpu_freq INCLUDES core_freq, you can now see that his question takes on a very different meaning.
gpu_freq sets all the otherwise unset core,h264,v3d,ISP clocks.

So
core_freq=480
gpu_freq=320

Will set core to 480, and h264,v3d,ISP to 320

Order is unimportant in config.txt, as the whole file is parsed to a structure, then the values are looked at.

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.

Re: Overclocking

Sat Jul 21, 2012 4:54 pm

shalo wrote:
Lob0426 wrote:This is my current config. Seems to be working fine. I cannot get arm_freq to be stable at 850.
I am trying to get quake or openarena working to test the gpu settings. Trying Quake3 from memetic.org which is supposed to work with raspianhf with sound. Openarena from Synaptic is giving video mode errors.

Code: Select all

arm_freq=800

# pll_freq=Core_freq*2^n if core=480, then pll=960 gpu=320 or 480
# pll must be 600 or more
[b]core_freq=480
gpu_freq=320[/b]
# probably do not need to specify all if gpu_freq specified.
h264_freq=320
v3d_freq=320
isp_freq=320

sdram_freq=500
hdmi_force_hotplug=1
# enable hdmi sound =2
hdmi_drive=2
hdmi_group=2
config_hdmi_boost=4
disable_overscan=1
framebuffer_width=1366
framebuffer_height=768

# settings for Motorola Lapdock
dom wrote:
ZirconiumX wrote:Question to dom: Would core_freq be set to 320 or 480 with this setup?
Both are valid in terms of integer ratios of clocks and PLL.

I'd expect 480 will only work with overvolting, but otherwise pick the highest one that is stable for you.
Lob0426 wrote: gpu_freq should also be set to an integer divisor if core_freq is used. gpu_freq raises all of the video related frequencies to what it is set at. see comments above for how to figure the correct setting for it.
I think you are missing the nuance to his question here and also missing something pretty important. Looking at that config you are specifying core_freq of 480. Then you are specifying gpu_freq of 320 later on in the same config file.

Given that gpu_freq INCLUDES core_freq, you can now see that his question takes on a very different meaning.

When he asks if that config is setting a core_freq of 480 or 320 he is not asking if they are valid, he is asking if your config is correct because it appears you have not set it up properly.

You should probably be specifying gpu_freq FIRST, then later core_freq because currently it appears your core_freq is redundant.

If you read his original post again and look at your config more closely, you'll probably understand why he suggested bumping core to 375 (you have it at 320 not 480) and leaving the others at 250 (which you have at 320).
I was hoping that he had read through the prior posts that really do explain it. But are kind of dis-associated from each other. I did miss covering the point that core_freq can change with gpu_freq, but core_freq can be set independent of GPU if it is specified. Of course each of these semantics discussions can confuse the issue worse rather than clarify. We need a chart and explanations in the wiki. For all of this so it can be seen in whole, rather than piecemeal. I am pretty sure I have it right now, but it would be a lot easier if we had some representations of real working clock settings and their relationships to each other in the wiki.
It would have been clearer to explain that the integer divisor is of the pll that is double (x2) of core_freq also. Which I forgot to add in anyplace. And that is what had me confused until @dom showed that formula. So the numbers given do not appear to have any connection.
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
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!

shalo
Posts: 74
Joined: Tue May 08, 2012 7:25 pm

Re: Overclocking

Sun Jul 22, 2012 11:34 am

Lob0426 wrote: It would have been clearer to explain that the integer divisor is of the pll that is double (x2) of core_freq also. Which I forgot to add in anyplace. And that is what had me confused until @dom showed that formula. So the numbers given do not appear to have any connection.
I got the impression that dom was working from memory and only recently double-checked.

Need to keep the formula intact though since for 250-300 core_freq then the pll is x4 the core_freq. (since 2x core equates to 500-600 which is not greater than 600). Though I would guess below clock(s) of 300mhz there is not much to be gained running them out of unison but you would have a few more options of acceptable settings.

I guess if anyone hits 601+mhz core_freq then 601 x 2^0 = 601mhz pll? I don't know if there is any practical reason to start considering that sort of level either. 630 core only leaves 315 as a sub option and not 252....yeah that's probably not going to happen or matter.

Anything that fitted the old explanation should fit the newer more detailed one, but there are some extra useful possibilities by knowing the formula.

portets
Posts: 186
Joined: Sat Oct 29, 2011 6:24 am

Re: Overclocking

Fri Jul 27, 2012 3:33 am

Am I the first person to reach 1000 arm clock with no overvolt? Been running at 100% cpu for over 20 minutes. Compiling fceux, running top, file manager open, and midori has 10 tabs open. All while I'm writing this. And this is on a cheap 4.8 volt phone charger.

Have yet to take it higher :twisted:

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Fri Jul 27, 2012 10:58 am

portets wrote:Am I the first person to reach 1000 arm clock with no overvolt? Been running at 100% cpu for over 20 minutes. Compiling fceux, running top, file manager open, and midori has 10 tabs open. All while I'm writing this. And this is on a cheap 4.8 volt phone charger.

Have yet to take it higher :twisted:
Quake is a pretty good overclock test. Can you run that with ARM at 1GHz?

portets
Posts: 186
Joined: Sat Oct 29, 2011 6:24 am

Re: Overclocking

Fri Jul 27, 2012 11:18 am

I tried quake a little bit ago and found my actual stable overclock is 990. :cry:

My (very accurate) test meter reports the pi is only receiving 4.76 volts, the 3v3 regulator is putting out 3.268v, and the 1v8 regulator is only putting out 1.784 :? . When i get a new adapter or wire up my own switching regulator, I'll have to see if I can hit higher.

So completely stable for me at stock voltages:

Code: Select all

arm_freq=990
core_freq=420
gpu_freq=280
ram_freq seems to either be capped or currently broken? I could set it anywhere above 400 with no effect, even 1600, but setting it at 20 made the system boot in 10 minutes. Running kernel #202 and whatever firmware came with it in the raspbian testing repository.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Fri Jul 27, 2012 11:51 am

portets wrote: ram_freq seems to either be capped or currently broken? I could set it anywhere above 400 with no effect, even 1600, but setting it at 20 made the system boot in 10 minutes. Running kernel #202 and whatever firmware came with it in the raspbian testing repository.
How are you testing is sdram freq has an effect? Note: small tests will run from L2 cache and won't see the effect of sdram freq.
Something like https://github.com/ssvb/ssvb-membench should see an effect.

portets
Posts: 186
Joined: Sat Oct 29, 2011 6:24 am

Re: Overclocking

Fri Jul 27, 2012 1:04 pm

Thanks for the link. I was just using quake3 to test if the memory was stable. Just compiled that program and got some results.

stock:

Code: Select all

    C copy backwards                                       :   128.27 MB/s
    C copy                                                 :   168.85 MB/s
    C copy prefetched (32 bytes step)                      :   279.29 MB/s
    C copy prefetched (64 bytes step)                      :   248.10 MB/s
    C copy via tmp buffer                                  :   139.51 MB/s
    C copy via tmp buffer prefetched (32 bytes step)       :   157.93 MB/s
    C copy via tmp buffer prefetched (64 bytes step)       :   157.94 MB/s
    C fill                                                 :   198.65 MB/s
    ---
    standard memcpy                                        :   316.08 MB/s
    standard memset                                        :  1315.26 MB/s
    ---
    ARM fill (STRD)                                        :   196.84 MB/s
    ARM fill (STM with 8 registers)                        :   896.42 MB/s
    ARM fill (STM with 4 registers)                        :  1225.34 MB/s
    ARM copy prefetched                                    :   312.29 MB/s

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

block size : read access time (single random read / dual random read)
         2 :   11.8 ns  /     0.0 ns 
         4 :   12.2 ns  /     0.0 ns 
         8 :   12.0 ns  /     0.0 ns 
        16 :   11.8 ns  /     0.0 ns 
        32 :   13.4 ns  /     0.2 ns 
        64 :   10.3 ns  /     0.2 ns 
       128 :   10.5 ns  /     0.3 ns 
       256 :   10.2 ns  /     0.5 ns 
       512 :   10.0 ns  /     0.4 ns 
      1024 :    9.9 ns  /     0.4 ns 
      2048 :    9.5 ns  /     0.4 ns 
      4096 :   10.9 ns  /     0.0 ns 
      8192 :   10.9 ns  /     0.0 ns 
     16384 :   17.7 ns  /    11.0 ns 
     32768 :   49.1 ns  /    62.7 ns 
     65536 :   69.4 ns  /    85.2 ns 
    131072 :   88.5 ns  /   109.9 ns 
    262144 :  161.1 ns  /   240.0 ns 
    524288 :  261.3 ns  /   442.3 ns 
   1048576 :  311.5 ns  /   546.5 ns 
   2097152 :  335.1 ns  /   600.3 ns 
   4194304 :  349.0 ns  /   628.9 ns 
   8388608 :  356.4 ns  /   643.4 ns 
  16777216 :  363.8 ns  /   660.1 ns 
  33554432 :  385.4 ns  /   704.1 ns 
  67108864 :  421.8 ns  /   777.4 ns 
500:

Code: Select all

    C copy backwards                                       :   110.36 MB/s
    C copy                                                 :   180.28 MB/s
    C copy prefetched (32 bytes step)                      :   297.25 MB/s
    C copy prefetched (64 bytes step)                      :   297.47 MB/s
    C copy via tmp buffer                                  :   147.81 MB/s
    C copy via tmp buffer prefetched (32 bytes step)       :   168.25 MB/s
    C copy via tmp buffer prefetched (64 bytes step)       :   168.47 MB/s
    C fill                                                 :   210.51 MB/s
    ---
    standard memcpy                                        :   337.47 MB/s
    standard memset                                        :  1330.26 MB/s
    ---
    ARM fill (STRD)                                        :   209.20 MB/s
    ARM fill (STM with 8 registers)                        :   910.31 MB/s
    ARM fill (STM with 4 registers)                        :  1258.19 MB/s
    ARM copy prefetched                                    :   330.09 MB/s

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

block size : read access time (single random read / dual random read)
         2 :   10.4 ns  /     0.2 ns 
         4 :   10.8 ns  /     1.4 ns 
         8 :    9.8 ns  /     1.3 ns 
        16 :    9.4 ns  /     1.3 ns 
        32 :    9.6 ns  /     1.4 ns 
        64 :    8.8 ns  /     1.8 ns 
       128 :    9.0 ns  /     1.5 ns 
       256 :    8.8 ns  /     3.0 ns 
       512 :    9.6 ns  /     0.4 ns 
      1024 :    9.3 ns  /     0.4 ns 
      2048 :    9.5 ns  /     0.4 ns 
      4096 :    9.6 ns  /     0.5 ns 
      8192 :    9.5 ns  /     0.8 ns 
     16384 :   16.4 ns  /    13.0 ns 
     32768 :   47.1 ns  /    62.2 ns 
     65536 :   68.0 ns  /    85.5 ns 
    131072 :   87.5 ns  /   107.7 ns 
    262144 :  153.3 ns  /   229.2 ns 
    524288 :  250.2 ns  /   425.3 ns 
   1048576 :  298.1 ns  /   525.2 ns 
   2097152 :  322.4 ns  /   576.3 ns 
   4194304 :  334.0 ns  /   601.8 ns 
   8388608 :  341.9 ns  /   617.0 ns 
  16777216 :  349.7 ns  /   635.3 ns 
  33554432 :  368.8 ns  /   674.8 ns 
  67108864 :  403.7 ns  /   744.8 ns 
600:

Code: Select all

    C copy backwards                                       :   145.51 MB/s
    C copy                                                 :   167.76 MB/s
    C copy prefetched (32 bytes step)                      :   303.85 MB/s
    C copy prefetched (64 bytes step)                      :   304.13 MB/s
    C copy via tmp buffer                                  :   153.55 MB/s
    C copy via tmp buffer prefetched (32 bytes step)       :   176.83 MB/s
    C copy via tmp buffer prefetched (64 bytes step)       :   176.30 MB/s
    C fill                                                 :   223.25 MB/s
    ---
    standard memcpy                                        :   348.23 MB/s
    standard memset                                        :  1345.41 MB/s
    ---
    ARM fill (STRD)                                        :   221.92 MB/s
    ARM fill (STM with 8 registers)                        :   920.69 MB/s
    ARM fill (STM with 4 registers)                        :  1267.09 MB/s
    ARM copy prefetched                                    :   345.26 MB/s

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

block size : read access time (single random read / dual random read)
         2 :   10.7 ns  /     1.1 ns 
         4 :    9.4 ns  /     1.0 ns 
         8 :    9.6 ns  /     0.9 ns 
        16 :    9.4 ns  /     0.9 ns 
        32 :    9.4 ns  /     0.9 ns 
        64 :    9.3 ns  /     1.1 ns 
       128 :    8.6 ns  /     1.0 ns 
       256 :    8.7 ns  /     1.0 ns 
       512 :    9.6 ns  /     0.0 ns 
      1024 :    9.6 ns  /     0.0 ns 
      2048 :    9.1 ns  /     0.2 ns 
      4096 :    9.4 ns  /     0.1 ns 
      8192 :    9.2 ns  /     0.6 ns 
     16384 :   16.3 ns  /    12.5 ns 
     32768 :   47.0 ns  /    61.4 ns 
     65536 :   67.3 ns  /    85.4 ns 
    131072 :   85.2 ns  /   106.6 ns 
    262144 :  149.4 ns  /   220.2 ns 
    524288 :  244.4 ns  /   412.0 ns 
   1048576 :  293.3 ns  /   510.8 ns 
   2097152 :  315.7 ns  /   561.8 ns 
   4194304 :  327.5 ns  /   587.0 ns 
   8388608 :  334.0 ns  /   603.4 ns 
  16777216 :  339.8 ns  /   618.0 ns 
  33554432 :  362.4 ns  /   659.6 ns 
  67108864 :  392.2 ns  /   715.1 ns 
700:

Code: Select all

    C copy backwards                                       :   133.46 MB/s
    C copy                                                 :   187.65 MB/s
    C copy prefetched (32 bytes step)                      :   304.32 MB/s
    C copy prefetched (64 bytes step)                      :   304.52 MB/s
    C copy via tmp buffer                                  :   153.36 MB/s
    C copy via tmp buffer prefetched (32 bytes step)       :   176.56 MB/s
    C copy via tmp buffer prefetched (64 bytes step)       :   176.45 MB/s
    C fill                                                 :   222.95 MB/s
    ---
    standard memcpy                                        :   348.53 MB/s
    standard memset                                        :  1343.98 MB/s
    ---
    ARM fill (STRD)                                        :   221.41 MB/s
    ARM fill (STM with 8 registers)                        :   917.18 MB/s
    ARM fill (STM with 4 registers)                        :  1271.27 MB/s
    ARM copy prefetched                                    :   345.19 MB/s

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

block size : read access time (single random read / dual random read)
         2 :   10.1 ns  /     0.1 ns 
         4 :    8.9 ns  /     0.2 ns 
         8 :    8.9 ns  /     0.3 ns 
        16 :    8.6 ns  /     0.3 ns 
        32 :    8.7 ns  /     0.3 ns 
        64 :    8.4 ns  /     0.3 ns 
       128 :    7.9 ns  /     0.3 ns 
       256 :    8.0 ns  /     0.4 ns 
       512 :    9.0 ns  /     0.0 ns 
      1024 :    9.0 ns  /     0.0 ns 
      2048 :    8.6 ns  /     0.0 ns 
      4096 :    9.0 ns  /     0.0 ns 
      8192 :    8.8 ns  /     0.0 ns 
     16384 :   15.8 ns  /    11.8 ns 
     32768 :   46.3 ns  /    61.5 ns 
     65536 :   66.7 ns  /    84.6 ns 
    131072 :   85.9 ns  /   105.1 ns 
    262144 :  148.9 ns  /   219.6 ns 
    524288 :  244.1 ns  /   411.9 ns 
   1048576 :  292.0 ns  /   511.3 ns 
   2097152 :  316.1 ns  /   561.7 ns 
   4194304 :  327.5 ns  /   588.6 ns 
   8388608 :  333.4 ns  /   601.9 ns 
  16777216 :  338.1 ns  /   615.0 ns 
  33554432 :  356.4 ns  /   647.8 ns 
  67108864 :  390.2 ns  /   714.4 ns 
1600:

Code: Select all

    C copy backwards                                       :   145.55 MB/s
    C copy                                                 :   187.19 MB/s
    C copy prefetched (32 bytes step)                      :   306.01 MB/s
    C copy prefetched (64 bytes step)                      :   305.87 MB/s
    C copy via tmp buffer                                  :   153.21 MB/s
    C copy via tmp buffer prefetched (32 bytes step)       :   176.42 MB/s
    C copy via tmp buffer prefetched (64 bytes step)       :   176.23 MB/s
    C fill                                                 :   222.68 MB/s
    ---
    standard memcpy                                        :   349.81 MB/s
    standard memset                                        :  1335.12 MB/s
    ---
    ARM fill (STRD)                                        :   221.31 MB/s
    ARM fill (STM with 8 registers)                        :   925.30 MB/s
    ARM fill (STM with 4 registers)                        :  1267.24 MB/s
    ARM copy prefetched                                    :   345.77 MB/s

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

block size : read access time (single random read / dual random read)
         2 :   10.5 ns  /     0.0 ns 
         4 :   10.2 ns  /     0.0 ns 
         8 :   10.5 ns  /     0.0 ns 
        16 :   10.2 ns  /     0.0 ns 
        32 :   10.2 ns  /     0.1 ns 
        64 :    9.8 ns  /     0.1 ns 
       128 :    9.3 ns  /     0.1 ns 
       256 :   10.7 ns  /     0.5 ns 
       512 :   10.4 ns  /     0.0 ns 
      1024 :   10.6 ns  /     0.0 ns 
      2048 :   10.4 ns  /     0.0 ns 
      4096 :   10.0 ns  /     0.0 ns 
      8192 :   10.4 ns  /     0.9 ns 
     16384 :   15.9 ns  /    11.1 ns 
     32768 :   48.2 ns  /    60.4 ns 
     65536 :   68.1 ns  /    84.0 ns 
    131072 :   87.1 ns  /   105.8 ns 
    262144 :  150.4 ns  /   219.4 ns 
    524288 :  245.7 ns  /   411.9 ns 
   1048576 :  293.3 ns  /   511.4 ns 
   2097152 :  317.3 ns  /   562.0 ns 
   4194304 :  329.1 ns  /   587.4 ns 
   8388608 :  334.8 ns  /   603.4 ns 
  16777216 :  341.9 ns  /   614.9 ns 
  33554432 :  365.4 ns  /   663.5 ns 
  67108864 :  392.3 ns  /   718.7 ns 
There were actually quite a few variations. To me it didn't seem to improve as much after 600. Would this be a program limitation or a firmware/hardware block? I haven't found anything saying the RAM speed is supposed to self-limit.

gazmandev
Posts: 12
Joined: Wed Jul 11, 2012 10:12 am

Re: Overclocking

Sat Jul 28, 2012 6:28 am

I have managed to overclock my Pi using the following settings.

Code: Select all

ARM:  900
Core: 275
SDRAM:500
Benchmarking using the Python script found here: http://www.raspberrypi-spy.co.uk/2012/0 ... pberry-pi/ resulted in around a 30-second improvement (averaged over three runs) from 7:18 to 6:55. I will try to tweak these settings a bit more.

colbhaidh
Posts: 10
Joined: Tue Oct 25, 2011 7:16 am

Re: Overclocking

Sat Jul 28, 2012 10:34 am

Over voltage is the really dangerous move. At final test after the IC is packaged, the test will guard band the speed. So, for example, it may be tested at 1GHz to guarantee that anything that would fail at 900MHz (if that was the spec) would never get through. So you may find your IC works OK at 950 but fails beyond that, while the guy next to you has one that works at 1.1GHz. Just your luck.
But for over voltage, this will stress every single transistor in the IC. It causes a degradation called hot carrier injection (HCI) which causes the transistor to change over time. The threshold voltage will change causing performance issues and can lead to catastrophic break down of the transistors gate oxide which causes the transistor to die (awwww...). Now the spec for HCI is typically 10% degradation over 10 years. PMOS transistors typically exceed this by 10x although they have another degradation known as Negative Bias Temperature Instability (NBTI). NMOS sometimes just make 10 years.

Anyway 10 years could be a long time for the lifetime of a Pi - but my BBC B is still running just now!
And so does my my Sinclair QL which used really dodgey 16K DRAMS bought from a semiconductor company who used to reside in Scotland (now how did I know that??).
Another hidden problem is latch-up. Where the voltage overstress causes a condition where the voltage supply could be shorted by a thyristor type action. This would likely toast the Pi immediately. You should see black marks on the crust!

Heck! Just get the cheque book oot and get another one.

User avatar
reiuyi
Posts: 165
Joined: Sun Oct 09, 2011 4:59 pm

Re: Overclocking

Sat Jul 28, 2012 10:19 pm

I'm convinced the MTBF of the bcm2835 is several decades. There's a bcm70012 in my notebook (same h264 core as bcm2835, I believe) and it's been cooking inside for years now. The machine is always on, runs quite hot inside.

No need to worry about hot carrier injection, Negative Bias Temperature Instability or any of those strange electronics engineering terms. If we were sending raspberries to the moon and beyond, using them in military vehicles, medical equipment or any situation where longevity and stability is required, those kinds of things become a real big issue. In everyday use, I don't see why anyone should care at all. Devices from the past like SNES, BBC Micro, etc all have their own issues like SRAM modules failing (empty batteries), exploding capacitors, magnetic discs losing their data integrity (haha.. R: Tape Loading Error).

I hope the Raspberry Pi doesn't have any of those silly issues. The large smd capacitor is likely to fail long before the bcm2835 starts poisoning itself with bad transistors. Heck, one of the connectors are likely to break off before the capacitor fails (I'm looking at you; SD card slot!!).

Overclock your raspberry pi to the max for your own enjoyment.

adamdbz
Posts: 15
Joined: Thu Jul 19, 2012 8:40 am

Re: Overclocking

Sun Jul 29, 2012 6:01 pm

i want to oc my new pi i don't want to over volt it
how can i stress test the pi
is there a software like prime95?

-Adam Ericson

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK

Re: Overclocking

Sun Jul 29, 2012 6:37 pm

adamdbz wrote:i want to oc my new pi i don't want to over volt it
how can i stress test the pi
is there a software like prime95?
There's probably quite a few suggestions if you read this entire thread, e.g. http://www.raspberrypi.org/phpBB3/viewt ... 43#p134343

zomzilla
Posts: 42
Joined: Wed Nov 16, 2011 3:04 pm

Mon Jul 30, 2012 2:10 pm

It would appear I have the Pi of the Gods

Currently at
Arm 1100
GPU 350
Sdram 500

All with an over volt of 6.

The Arm_freq is the highest possible before bizarre errors
Still pushing the other 2 settings


Anyone have an idea the over volt will have on the life of the Pi?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re:

Mon Jul 30, 2012 3:42 pm

zomzilla wrote:Anyone have an idea the over volt will have on the life of the Pi?
Best guess is that with maximum overvolt, it will still last for many years.
Almost certain it will mecahnically fail or becore technologically obsolete well before the SoC expires.

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.

Re: Re:

Mon Jul 30, 2012 6:35 pm

dom wrote:
zomzilla wrote:Anyone have an idea the over volt will have on the life of the Pi?
Best guess is that with maximum overvolt, it will still last for many years.
Almost certain it will mecahnically fail or becore technologically obsolete well before the SoC expires.
Makes me wonder why Broadcom did not bump the specs a bit!
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
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!

FX4
Posts: 64
Joined: Fri Jul 27, 2012 2:39 pm

Re: Overclocking

Mon Jul 30, 2012 7:51 pm

Well I have made 950Mhz without a problem but 1GHz seems to kill it.

zomzilla
Posts: 42
Joined: Wed Nov 16, 2011 3:04 pm

Re: Overclocking

Mon Jul 30, 2012 7:58 pm

950 MHz seems to be the maximum without an over volt.
With overvolt6 I got to 1050 and any ram OC at all crashed

With my nice new heatsink, paste and diddly 5V fan I get 1100mhz, 500mhz ram and 350gpu (need to stress test the GPU and find the full maximum)

FX4
Posts: 64
Joined: Fri Jul 27, 2012 2:39 pm

Re: Overclocking

Mon Jul 30, 2012 7:59 pm

Cool I was wondering how a heat synch would work.

Return to “Advanced users”