Overclocking

[FX4]

Short answer, because I used to do this. Random sample of boards, crank up the clock, crank up the the voltage. Wait for them to fail. Document the failure points and then look for trends. It is a lot more complicated than this but a high level it is how destructive testing performed.

But you cannot stress test a raspberry pi without stress testing a raspberry pi. You're in an overclocking thread so it is a given that people here and interested in overclocking and you are saying not to stress test the raspberry pi.

You are likely to cause yourself way more problems running an unstable pi than ensuring it is stable. When it crashes say once every couple of weeks, you will have a nightmare trying to narrow down exactly what the cause was and of course, the crash might just be inconvenient.

The people who designed and work with these very chips on a daily basis are telling you that heat is basically not an issue, if they can't then I obviously can't convince you otherwise

I'm genuinely not sure I understand what point you are trying to convey other than you worked in a related field 15 years ago back when the first 3D gpus were only just becoming mainstream. I don't think overclocking is for you and that's fine too.

I don't see anything from those quotes that disagrees with anything I have posted. Nice to see that they have done a good amount of bench testing. One thing I will add to their testing is more than likely they have not drilled down through the package and measured temps a specific PN junctions. That is something you do in the semiconductor industry testing but is almost never done outside of the manufacturer. The over voltage causes temperatures to rise at specific locations resulting in eventual junction failure. I would have to acid etch the package and use an scanning tunneling microscope to tell you the exact failure but almost always it is heat related in these cases. In the past I have performed a lot of this kind of work. I proved we had an ESD problem when the design engineers insisted it was not possible. X company was changing the geometry on X company's ESD structure that rendered the structure non-functional. Anyhow getting back to this topic, the over voltage is more than likely causing transistors to heat up one way or another. If voltage was causing noise, a short, or race condition you would see that pretty quick in my experience. Of course YMMV.

[emba]

These Cambridge people that live at 69F (20.5C) all year round just do not agree with me

sorry i had to laugh at that one, its not that often we see temps as high as 20C for extended periods here in the uk! but i think if you are going to overclock a heatsink couldnt hurt any, i havent found the limit on mine yet but its running at 850/475 at the moment and im sticking with that until the weekend when i can get a heatsink.

[Flojer0]

Shalo, if I could up-vote users here I would do so for you. You handled the whole "heat not being an issue here" much more thoroughly than I would have.

People do have to remember too, this isn't some 130W TDP hex core, it's a cell phone chip. it's not going to heat up much.

[robwriter]

Short answer, because I used to do this. Random sample of boards, crank up the clock, crank up the the voltage. Wait for them to fail. Document the failure points and then look for trends. It is a lot more complicated than this but a high level it is how destructive testing performed.

But you cannot stress test a raspberry pi without stress testing a raspberry pi. You're in an overclocking thread so it is a given that people here and interested in overclocking and you are saying not to stress test the raspberry pi.

You are likely to cause yourself way more problems running an unstable pi than ensuring it is stable. When it crashes say once every couple of weeks, you will have a nightmare trying to narrow down exactly what the cause was and of course, the crash might just be inconvenient.

The people who designed and work with these very chips on a daily basis are telling you that heat is basically not an issue, if they can't then I obviously can't convince you otherwise

I'm genuinely not sure I understand what point you are trying to convey other than you worked in a related field 15 years ago back when the first 3D gpus were only just becoming mainstream. I don't think overclocking is for you and that's fine too.

I don't see anything from those quotes that disagrees with anything I have posted. Nice to see that they have done a good amount of bench testing. One thing I will add to their testing is more than likely they have not drilled down through the package and measured temps a specific PN junctions. That is something you do in the semiconductor industry testing but is almost never done outside of the manufacturer. The over voltage causes temperatures to rise at specific locations resulting in eventual junction failure. I would have to acid etch the package and use an scanning tunneling microscope to tell you the exact failure but almost always it is heat related in these cases. In the past I have performed a lot of this kind of work. I proved we had an ESD problem when the design engineers insisted it was not possible. X company was changing the geometry on X company's ESD structure that rendered the structure non-functional. Anyhow getting back to this topic, the over voltage is more than likely causing transistors to heat up one way or another. If voltage was causing noise, a short, or race condition you would see that pretty quick in my experience. Of course YMMV.

But wouldn't it always be the case that more voltage is worse? So a 10% overvolt may kill the chip, but a 1% wouldn't as bad.

My point is, what makes you think that the amount of overvolting the Pi has accessible can cause problems?

[shalo]

Soooo, "Allow PWM PLL to be repurposed for H264/ISP/V3D."

I guess this might be a way to unlink H264/ISP/V3D from core_freq?

[dom]

Soooo, "Allow PWM PLL to be repurposed for H264/ISP/V3D."

I guess this might be a way to unlink H264/ISP/V3D from core_freq?

Yes,
avoid_pwm_pll=1

in config.txt. The PWM PLL will be freed up (anlogue audio should still work, but from a fractional divider, so lower quality).

H264/ISP/V3D are tied together, but now are unrelated to GPU core freq. So this is valid:
gpu_freq=320
core_freq=450

[Lob0426]

There was discussion about the fact that the RAM package sits atop the SoC. My opinion has always been, remove heat from the RAM package and it will lower the SoC temps, even if there is an insulating layer of air between. That layer of air is probably under a couple of thousandths, probably less.

Thanks @dom, Now you have added a new complication to Overclocking. Dang It Shalo will have to straighten me out all over again!

I thought I had found my Raspi's limit arm_freq at 800. After dropping the gpu_freq to 320 I am now stable at arm_freq=850 with no overvolt. sdram_freq=500 has not been an issue at all so far. The other two I just received today fired up at the first RasPi's settings with no problems also. Only have tried Quake 3 for a few minutes each so far for the new ones. Stable so far in Quake3 and LXDE. More than a few minutes each is needed to really make sure.

[AndrewS]

One thing I will add to their testing is more than likely they have not drilled down through the package and measured temps a specific PN junctions.

Maybe they have? http://www.raspberrypi.org/phpBB3/viewt ... 76#p126876

One thing to bear in mind is that the BCM2835 != the Raspberry Pi.
The way I understand it, the BCM2835 SoC (made by Broadcom) has had *lots* of testing (baking in ovens, etc.) - as it's used in cellphones it needs to be super-reliable. But I expect the versions used in cellphones don't get overclocked. The Raspberry Pi (made by the Raspberry Pi Foundation) has had much less extensive testing (as a charity, I assume it's received less testing than typical commercial devices would get), although it offers much more 'user control' over the BCM2835 settings than most devices offer

[emba]

But I expect the versions used in cellphones don't get overclocked.

i wouldnt say that, ive overclocked my last 3 phones (my current desire z runs a 1.2ghz clock up from its original 800mhz and my touchpad at 1.5ghz which runs at 1.2ghz stock) so i imagine plenty of people have clocked it when used in a mobile.

a question on how the chip can be clocked for the experts here though, on a phone the clock can be varied by screen state and such, so does the pi respond immediately to changes to config.txt if it is edited on the machine or does it load at boot only and need a reboot to make the new settings active?

[itimpi]

The values in config.txt are only read at boot time, so after making changes a reboot is required before they take effect.

[emba]

ah ok, its not too bad really, its not like a boot takes long but it would have been nice to be able to clock in os. one thing i have noticed though is that raspbian seems to clock fine, but a few days ago i built the latest openELEC from source, it runs very well at stock but for some reason it wont boot with a clock at all, in fact it wont boot with a config.txt even if it just has arm_freq=700

[roobarb!]

After a good bit of playing around, the best my Pi can cope with is this:

Code: Select all

arm_freq=911
core_freq=422
sdram_freq=500
over_voltage=0
over_voltage_sdram=1

These values are backed off a little bit from what appeared to be stable and are the best mix of CPU and GPU performance I could manage. Note that I did have to apply a slight overvolt to the SDRAM, otherwise it would always fall over at 500.

Quake 3 (which I've been using as a stress test) averages about 27fps on a 1280x1024 display running the 'demo four' timedemo with the 'Very High Quality' settings. It's now really pretty smooth, and I'm rather impressed!

[shalo]

After a good bit of playing around, the best my Pi can cope with is this:

Code: Select all

arm_freq=911
core_freq=422
sdram_freq=500
over_voltage=0
over_voltage_sdram=1

These values are backed off a little bit from what appeared to be stable and are the best mix of CPU and GPU performance I could manage. Note that I did have to apply a slight overvolt to the SDRAM, otherwise it would always fall over at 500.

Quake 3 (which I've been using as a stress test) averages about 27fps on a 1280x1024 display running the 'demo four' timedemo with the 'Very High Quality' settings. It's now really pretty smooth, and I'm rather impressed!

Do you have no more settings to go with that config? Isn't that running the gpu at a mixture of 211mhz and ~281mhz to average out at the desired 250mhz? If that is really stable might I suggest trying the following instead for what should reap significant benefits in Q3:

core_freq 420
gpu_freq 280

If you've run rpi-update you could just add the new setting for in theory no real net gain but you'll make me happier:

avoid_pwm_pll=1

[Lob0426]

Talk about different batches and overclocking!
My first RasPi received in june (6/8/12)
with heat sinks
over_voltage=8
arm_freq=900
core_freq=320
gpu_freq=320
sdram_freq=500

before overvolt
arm_freq=800 has been running at 850 today after overvolt was taken off.
core_freq=320
gpu_freq=320
sdram_freq=500
As high as it will run stable in quake3. Might still be able to get a little more out of it. Could not enter a match until core clock came down to 420, RasPi would reset.

The 2 new RasPi Recieved 8/1/12
no overvolt set
No heatsinks
#2
arm_freq=900 crashed Q3 immediately at 950
core_freq=320 did not like 350 reset
gpu_freq=320 did not like 350 reset
sdram_freq=500
#3
no overvolt set
heat sinks
arm_freq=900 950 played for a bit then froze
core_freq=320 did not like 350 crash
gpu_freq=320 did not like 350 crash
sdram_freq=500
Have not really pushed them without overvolt yet.
They run faster with no overvolt at all. Guess which RasPi is getting the soldering Iron put to it when the parts get here?

[portets]

I got extremely lucky . Stable for me with no overvolt and thorough testing:

Code: Select all

arm_freq=990
sdram_freq=600
core_freq=420
gpu_freq=280

And no, there are no typo's there. My ram could be clocked higher, but dom said the sdram_freq currently maxes out at 600.

[beautifulsmall]

ive looked right through this forum and cant find any mention of exactly what DDR is fitted to the pi. Does anyone know the manufacturer and speed grade is fitted. Often manufacturers like BCM will dual source so some could be hynix, others elpida ? Also there are many other settings related to memory speed like refresh rate which needs to be increased above 85C . Good discussion on Hot carrier and Junctions by people who have done real bench lab testing but just turning up the clock as someone said depends on if your chip is a middle wafer or a circumference cut. Memory chips are speed grade binned by testing not by exact manufacturer. its a yield thing. What works for one person wont work for another.
One real possibility would be very short term overclocking , ie a few us/ ms at a time to burst which is quiet feasable but again it wont work for everyone.

[beautifulsmall]

Looks like Hynix and Samsung have been used so far . I would have you now issuing xlophones if you want to go faster.

[AndrewS]

ive looked right through this forum and cant find any mention of exactly what DDR is fitted to the pi. Does anyone know the manufacturer and speed grade is fitted.

http://elinux.org/RPi_Hardware#Components

Often manufacturers like BCM will dual source so some could be hynix, others elpida ?

Broadcom are only the suppliers of the SoC - the RaspberryPis are being manufactured by RS and Farnell (or whichever Chinese factories they've subcontracted to).

You might be interested in this too http://elinux.org/RaspberryPi_Boards

One real possibility would be very short term overclocking , ie a few us/ ms at a time to burst which is quiet feasable but again it wont work for everyone.

As already mentioned the clock speeds can only be changed at powerup, not at runtime. And doing a reboot (so that config.txt gets re-read) takes a lot longer than a few milliseconds

[roobarb!]

After a good bit of playing around, the best my Pi can cope with is this:

Code: Select all

arm_freq=911
core_freq=422
sdram_freq=500
over_voltage=0
over_voltage_sdram=1

These values are backed off a little bit from what appeared to be stable and are the best mix of CPU and GPU performance I could manage. Note that I did have to apply a slight overvolt to the SDRAM, otherwise it would always fall over at 500.

Quake 3 (which I've been using as a stress test) averages about 27fps on a 1280x1024 display running the 'demo four' timedemo with the 'Very High Quality' settings. It's now really pretty smooth, and I'm rather impressed!

Do you have no more settings to go with that config? Isn't that running the gpu at a mixture of 211mhz and ~281mhz to average out at the desired 250mhz? If that is really stable might I suggest trying the following instead for what should reap significant benefits in Q3:

core_freq 420
gpu_freq 280

If you've run rpi-update you could just add the new setting for in theory no real net gain but you'll make me happier:

avoid_pwm_pll=1

Nope, that's all the settings. I've tried the mix of core at 420 and gpu at 280, but any push beyond 250 on the gpu and it falls over. Sometimes immediately, sometimes after a bit of load.

I'll certainly pop avoid_pwm_pll=1 in if you believe it should be there. I'll be honest, in my rush to test I keep forgetting which values have which relationship.

[jerrylamos]

This one's running at
arm_freq=900
core_freq=450
sdram_freq=450
Do note re-boot filled the screen with error messages. Power off/power on worked.

Also note at defaults the screen was filled with 1280x720 while overclocked it's at 1366x768 which is the TV's rating.

A little bit of underscan vertically so let me try some overscan...

Jerry

[shalo]

After a good bit of playing around, the best my Pi can cope with is this:

Code: Select all

arm_freq=911
core_freq=422
sdram_freq=500
over_voltage=0
over_voltage_sdram=1

These values are backed off a little bit from what appeared to be stable and are the best mix of CPU and GPU performance I could manage. Note that I did have to apply a slight overvolt to the SDRAM, otherwise it would always fall over at 500.

Quake 3 (which I've been using as a stress test) averages about 27fps on a 1280x1024 display running the 'demo four' timedemo with the 'Very High Quality' settings. It's now really pretty smooth, and I'm rather impressed!

Do you have no more settings to go with that config? Isn't that running the gpu at a mixture of 211mhz and ~281mhz to average out at the desired 250mhz? If that is really stable might I suggest trying the following instead for what should reap significant benefits in Q3:

core_freq 420
gpu_freq 280

If you've run rpi-update you could just add the new setting for in theory no real net gain but you'll make me happier:

avoid_pwm_pll=1

Nope, that's all the settings. I've tried the mix of core at 420 and gpu at 280, but any push beyond 250 on the gpu and it falls over. Sometimes immediately, sometimes after a bit of load.

I'll certainly pop avoid_pwm_pll=1 in if you believe it should be there. I'll be honest, in my rush to test I keep forgetting which values have which relationship.

Well, unless someone spots something I have missed you are saying your gpu is perfectly stable while running the gpu at a mix of what equates to 211mhz and ~281mhz. So uhm. Power might be an issue rather than anything else but I'd just suggest learning what the settings do. (I also wouldn't blindly add the avoid_pwm_pll setting because how can you trust me at face value when you aren't sure why I am even suggesting to do it?)

[shalo]

This one's running at
arm_freq=900
core_freq=450
sdram_freq=450
Do note re-boot filled the screen with error messages. Power off/power on worked.

Also note at defaults the screen was filled with 1280x720 while overclocked it's at 1366x768 which is the TV's rating.

A little bit of underscan vertically so let me try some overscan...

Jerry

I take it you are not using the gpu's 3d or h264? 1/3 x 300 and 2/3 x 225 = 250?

Someone smack me if I try to make sense of anyone elses config again.

[jerrylamos]

Overclocked at 900/450/450 (see post preceding) the desktop margins were wide so
changed 1280/720 to 1366/768 which is what I wanted anyway
and set overscan top & bottom to -16 each.

Looks fine with Midori.

No overvolt. I'll see if the chips get hot to touch. Room temperatures here are running 80's F about 27C.

Good response to keyboard and mouse.

Mostly interested in Raspberry Pi for the lively forums. I'm usually on Ubuntu Alpha's and Beta's. so Debian Raspberry Pi is familiar.

Having fun. Jerry

[shalo]

No overvolt. I'll see if the chips get hot to touch. Room temperatures here are running 80's F about 27C.

Remember, the SOC is designed for cellphones and that as I understand it, these cell phones even work near the Equator. I've seen people leave their cell phones out in direct sunlight all day long while trying to get skin cancer. They still work. In the interest of disclosure, it is only 20C here in Blighty but that is pleasant enough for me and my naturally cheery disposition.

[jerrylamos]

This one's running at
arm_freq=900
core_freq=450
sdram_freq=450
Do note re-boot filled the screen with error messages. Power off/power on worked.

Also note at defaults the screen was filled with 1280x720 while overclocked it's at 1366x768 which is the TV's rating.

A little bit of underscan vertically so let me try some overscan...

Jerry

I take it you are not using the gpu's 3d or h264? 1/3 x 300 and 2/3 x 225 = 250?

Someone smack me if I try to make sense of anyone elses config again.