Raspberry Pi overclocking - the definitive thread

There are few threads about overclocking Raspberry Pi but unfortunately none of them seems to summarize the issue and some of them are quite old (maybe something has changed in the meantime). I’ve decided to re-ask some questions then.

1. GNU/Linux pays attention to force_turbo=0 mode setting in config.txt on boot partition (system scheduler will temporarily jump to higher frequencies instead of keeping maximum non-stop). Does RISC OS (at least 5.23 2015-09-27 or newer) obey that setting too?

2. There exists some form of clocks relationship. Therefore, can I simply set them in 10% percentage increments on my B+ (840MHz as 120% of base CPU clock, 440MHZ as 110% of base RAM clock and 300MHZ as 120% of base GPU clock)?

3. Aren’t settings above simply too much for 24/7 use in very well ventilated case (many airholes, much of free space inside case)?

4. Is it still true that it’s not possible to monitor CPU temperature (and clock but it’s different issue) from RISC OS? That would make measuring air temperature (using this CJE Micro’s product for example) the only remaining solution.

5. Is there still a possibility that using moderate overclocking values SD card filesystem will become corrupted (even with init_emmc_clock=100000000 in config.txt)? I’ve been running for around one month on 800MHz CPU/300MHz GPU/default for RAM without any problems (Verify runs through card without problems everyday) so far.

Disclaimer: I’m not an expert. ;-)

The wimp ought to speed up and slow down the machine depending on how “busy” the system is. Not sure what happens if you go to the command line, maybe the kernel ought to be aware of this.

No, we still can’t access the GPU temperature. Maybe soon?

Some SD cards will work better than others; I think it’s a case of suck-it-and-see along with make-backups.

1. No.
2. CPU: free choice. The other parts: that depends :)
3. A Pi stay cold even at 850-900 MHz.
4. At 800 MHz, there is nothing to monitor :)
5. Problem solved a long time ago.

I use 800 MHz without any problem inside a flat case (width; around 1.5 cm). There is even no room for USB ports. And it stays cold.

The wimp ought to speed up and slow down the machine depending on how “busy” the system is. Not sure what happens if you go to the command line, maybe the kernel ought to be aware of this.

yet

1. No.

As far as I understand CPU will stay on default 700MHz even with configured to be 840MHz but with force_turbo=0. Is that correct?

2. CPU: free choice. The other parts: that depends :)

Could you please expand? As far as I know gpu_freq handles PLL clocks (because it sets core_freq, h264_freq, isp_freq and v3d_freq at once to use the same frequency).

As far as I understand CPU will stay on default 700MHz even with configured to be 840MHz but with force_turbo=0. Is that correct?

Yes. Dynamic clock is not supported under RISC OS.
So force_turbo=0 means no overclock at all.

Could you please expand?

CPU = heat. I use 800 MHz (I did use 900 MHz too).
GPU = not a lot of effects. Can generate heat, but boost L2 cache. 275 to 350 MHz is OK.
SDRAM = 450 or 500 MHz, depending of chips. No need to use only 450 MHz if 500 MHz works.
Core = due to past sync issues, I use only 250 MHz or 500 MHz.

900 (CPU), 300 (GPU) and 450 (SDRAM) should be OK on most computers. For core… 450?
I have a small heat sink, but it’s always cold…

Core and GPU are linked. If you use Core = 500, GPU will be rounded to 275 MHz.

So 900(CPU)/500(Core)/500(SDRAM) means GPU at 275 MHz — 900/450/450 means GPU at 257 MHz
The second is probably safer.

You could probably opt too for 900(CPU)/300(GPU)/450(Core)/450(SDRAM).
That’s really a lot :)

See : http://elinux.org/RPiconfig
and… http://hwbot.org/news/9769_raspberry_pi_overclocking_%E2%80%93_cheap_fun_and_hwbot_prime_oc_guide_page_2

SDRAM = 450 or 500 MHz, depending of chips. No need to use only 450 MHz if 500 MHz works.

Is there any reason to overclock RAM in 50MHz increments? Do Samsung chips cope better with overclocking?

Core = due to past sync issues, I use only 250 MHz or 500 MHz.

Is it a bad idea to use only gpu_freq and let all other (core, h264 etc) just use the same? What exactly were those sync issues? Maybe it’s something already resolved?

Most important: how much moderate overclocking will affect lifespan (especially when leaving Pi to run 24/7 like I do)?

You could probably opt too for 900(CPU)/300(GPU)/450(Core)/450(SDRAM).

longevity > speed in my case :-)

If it is running 24/7, is it some sort of server?
If so you might like to consider no overclock as surely reliability and longevity are more important than processing speed?

If it is running 24/7, is it some sort of server?

No, it’s desktop. I just don’t like turning my computers off (mostly because I set them to backup to FTP server running on another Raspberry Pi, this one without o/c). Also, RISC OS (and Raspberry Pi as a hardware platfom) does not have sleep and/or hibernate modes allowing me to resume whatever I was doing in few seconds.

If so you might like to consider no overclock as surely reliability and longevity are more important than processing speed?

Well, current computers aren’t as good quality as they used to be… I just want that particular Raspberry Pi to live more than few months (preferably over two years) yet I like my current 840MHz performance boost (it just doesn’t feel blazing fast without it).

Samsung chips cope better with overclocking?

Yes, lot of other chips have problem at 500 MHz.

Maybe it’s something already resolved?

It is. But, who knows if regression could not occur in firmware?
I tend not to touch core freq. Only SDRAM and GPU.

longevity > speed in my case :-)

Then don’t overclock it at all.
There is no overclock without lower lifespan.
Just a matter of performance VS price.

I think that at 900 MHz, the Pi should run for at least two year. Probably more.
I’ll try 850/300/450/450. Because it’s less than 900/350/500/500 :)

There is no overclock without lower lifespan.

There’s the golden mean too, overclock low enough to let it live happily for two years ;-)

IIRC overclocking doesn’t now invalidate the warranty because they believe it will crash before it does permanent damage. Though over Voltage does invalidate the warranty.

FWIW, I’ve been running my Pi 1B since April 2014 at 900/333/450 (Arm/core/sdram) with over-voltage=2 and force-turbo=1 without any issues of stability or reliability*. I use it daily for 12+ hours. It has heatsinks on both cpu and graphics chip and is housed in an open-sided VESA mount on the back of my monitor. (*Having said that it’ll probably now expire in a cloud of smoke….)

I use it daily for 12+ hours.

24/7

It has heatsinks on both cpu and graphics chip

I don’t have any. Do they make noticeable difference? As far as I know this SoC was designed to run without them.

and is housed in an open-sided VESA mount on the back of my monitor

I also have VESA enclosure but with closed sides (yet full of ventilation holes).

(*Having said that it’ll probably now expire in a cloud of smoke….)

connection reset by peer ;-)

Though over Voltage does invalidate the warranty.

That’s why I’ve never used it (and never will).

FWIW, I’ve been running my Pi 1B since April 2014 at 900/333/450 (Arm/core/sdram)

My Pi B (issue 2) runs RISC OS at the default speed.
RaspBMC (no longer supported, it’s something else?) would overclock to 800MHz.
Playing a 720P video, the thing would maybe warm up by a single solitary degree. This is with it in a little orange plastic case and no heatsinks.

I tried RISC OS at 800MHz. To be honest, the slow part of RISC OS is the filesystem and there’s only so fast you can get data shifted to/from the SD card. As such, the overclocking didn’t appear to make a significant impact in speed when used as a user (and not as a benchmark test), so I reverted back to “normal” speed. What is that, 700MHz or so? Yes, it made the machine faster, but no, the general day to day use wasn’t automatically 14% quicker; the file operations bottleneck was the obvious hold up, but otherwise the machine spends an awful lot of time contemplating its naval. Does it matter if it executed fifty billion instructions in between each keypress instead of merely 40 billion? It’s still effectively “doing nothing” except waiting for me to press a key…

I choose reliability and stability over speed.
Remember, the RISC OS FS is fragile and pretty much incapable of fixing itself. If you’re going to try overclocking, you do have a copy of DiscKnight, right?

PS:

It has heatsinks on both cpu and graphics chip

You mean network chip, don’t you? The CPU and GPU are in the same place in the Pi (1B) – underneath the SDRAM.

If you’re going to try overclocking, you do have a copy of DiscKnight, right?

I think !CloneDisc and !SafeStore are good enough :-)

but no, the general day to day use wasn’t automatically 14% quicker

Web browser speeds up a bit, compressing files speeds up a bit (especially if you compress to RAM drive and/or network drive), any data crunching stuff speeds up (GnuPG, compression again).

Remember, the RISC OS FS is fragile and pretty much incapable of fixing itself.

After around one month of running the board overclocked there’s absolutely no problems with file system (or at least so Verify thinks). Basically nothing crashed so far :-)

By the way I had other RPi running overclocked as a server 24/7 for last 6 months or so – no problems too (but I’ve decided that 57*C CPU temperature was a bit too hot for a server).

(or at least so Verify thinks).

*Verify checks that the sectors are not physically damaged. It does not check the filesystem itself.
Try *CheckMap

Basically nothing crashed so far :-)

Doesn’t need to crash. Errant memory access? Messed up pointer? Fringe level due to slightly inadequate power supply?

I think Jeffrey fixed something about a year ago (rough guess) and that’s about when I changed to a better power supply. Since then, things have been more reliable, but I do think my “Map is inconsistent with directory tree” so I’ll either have to buy DiscKnight myself or copy stuff to a fresh SD card. Given that I build my own RISC OS and unpacking/building that absolutely clobbers the FS (thousands of files), I rather suspect that DiscKnight is going to be the more sensible option. That and regular SD card images…

no problems too (but I’ve decided that 57*C CPU temperature was a bit too hot for a server).

For an ARM, I guess, yes. Still, it makes me smile. My PC (1.6GHz Atom with execrable Intel GPU/chipset) is running at a steady 47C with the fan hacked to be at 80%. Now if I start to play a video (and push the fan to 100%) I can pretty much guarantee that I’ll be in the mid-60s within seconds.
I do my DVD rips now on the Pentium4 box as it can manage to XviD at ~14fps; it has a heatsink that looks like Trump Tower with an ass-kicking fan on either side of it and a plastic frame to guide the air right towards the heatsink. I don’t have an on-screen temperature monitor. Probably just as well. The BIOS will throttle if it gets too hot, so I’ll leave it at that…

My Pi’s box, meanwhile, with no heatsink and having been on all week…is barely warm to the touch.

I rather suspect that DiscKnight is going to be the more sensible option. That and regular SD card images…

Well, you’ve just convinced me to buy it. Seriously.

I do my DVD rips now on the Pentium4

ROTFL that epic computing power to power consumption ratio LOL

Errant memory access? Messed up pointer? Fringe level due to slightly inadequate power supply?

So far nothing like this happened (fortunately).

Back to overclocking stuff:

1. Should I put heatsing on voltage regulator chip (especially on B+ or 2 models where this one was improved afair)? Or maybe (just for peace of mind, although I know that SoC was designed to be used without one) it’ll be just ok to place them just on SoC and net chips?

2. How bad is idea of using Raspberry Pi 2 in wooden enclosure (again, full of ventilation holes)? I’m probably buying another Pi soon and I’d like to put it in wooden case (just because it looks good). Yes, it’ll run overclocked a bit too.

850/300/450/450 works well here. With the compression of 1 GB of data, chip stays almost cold.

I think !CloneDisc and !SafeStore are good enough :-)

Not the same use.
DiscKnight is a must have.

1. I have only one, and it’s enough. The only piece overclocked is the SoC anyway.
2. Not bad at all. Pi and Pi 2 are cold products. They are not smartphone’s chips.

@Rick: yes, the heatsink’s on the network chip – my mistake.
Re heatsinks generally: they may be redundant on a reasonably well-ventilated Pi, or even a not well-ventilated one, but for a few quid (mine cost less than 6 quid if memory serves), why not have some insurance?
Re overclocking generally: I find across-the-board performance improves in direct relation to the increase in clock speed (providing the core and sdram speeds are adjusted proportionally). So @ 900 MHz things get done about 30% faster than at the default speed.
Re Disknight: absolutely essential IMHO.
(Sent from my Pi using Otter browser :-) )

Re Disknight: absolutely essential IMHO.

now I understand ;-)

2. Not bad at all. Pi and Pi 2 are cold products.

Wasn’t that 900MHz on Pi 2 factory overclock by 100MHz?

why not have some insurance?

Will it make any noticeable difference to use copper heatsinks instead of random cheapskate ones? Price will rise around five times.

(sent from “og” NetSurf on Pi B+ ;-) )

Will it make any noticeable difference to use copper heatsinks instead of random cheapskate ones?

On the network chip? Perhaps – though I think the way the heatsink is actually bonded to the chip may be more important. I’ve actually seen a good solid copper heatsink scuppered by somebody that applied the gunk “around the edges” of a large Pentium type processor, thus leaving an air gap between the centre of the processor itself and the bottom of the heatsink. Their computer didn’t last long, they offloaded it to me for salvage.

As for the Pi’s heart – please PLEASE everybody remember that the cores of the Pi 1 and the Beagle/xM (maybe Panda?) are stacked so that big chip you can see is actually the memory. The processor core (GPU, etc) is underneath that. The SoC itself has an array of little beads on top, which match up with beads on the bottom of the memory. They are electrically joined using a hellishly complicated process.
So the heat from your processor/GPU needs to travel through the solder joins into the memory, through the memory, and out to the top. Then a heatsink might have something to do.

I apologise if I sound a little patronising here, but I don’t want anybody to think that whacking a big heatsink onto the chip they can see means they can run the machine hard – the heatsink isn’t good insurance as the chip you can see is not the SoC itself.

I’ve not looked at the Pi2 in much detail, but I think I remember the memory and SoC are no longer stacked?

(sent from my XP box using Firefox 12 as I got fed up of everything changing seemingly each month… I wish RISC OS had a stable release cycle like Firefox’s! Scratch that, no I don’t. I wish they’d fix bugs and vulns and leave the UI the hell alone. Ditto RISC OS, fix what needs fixed, don’t mess with it for the sake of messing with it!)

sent from my XP box

I’d rather die than use that shi^H^H^H worst OS in history again… MS should’ve killed it sooner.

I’ve not looked at the Pi2 in much detail, but I think I remember the memory and SoC are no longer stacked?

That’s probably correct, on every single photo (including official one) there’s clearly visible Broadcom logo instead of usual Samsung/Hynix/whatever text.

I apologise if I sound a little patronising here, but I don’t want anybody to think that whacking a big heatsink onto the chip they can see means they can run the machine hard – the heatsink isn’t good insurance as the chip you can see is not the SoC itself.

No you don’t :-) it’s all about explaination of any overclocking related doubts. I was actually convinced that heatsink is a good idea (even if it doesn’t dissipate heat from CPU directly but only from double-heated RAM chip on top). Unfortunately I’m still afraid that someday it’ll fail (thermally conductive adhesive might simply let go and then falling* heatsing might cause fatal shortage).

• - yup, VESA mount case with Raspberry Pi positioned USB/ethernet ports down