Homepage › Forums › RetroPie Project › Everything else related to the RetroPie Project › Overclocking and Stress / Reliability testing the Raspberry Pi
- This topic has 12 replies, 6 voices, and was last updated 9 years ago by retroresolution.
-
AuthorPosts
-
12/01/2015 at 14:27 #111009retroresolutionParticipant
Hi all,
Thoughts on Overclocking the Pi and Stability Testing:
I’m using a Pi 2 to run emulators using RetroPie, and have spent considerable time setting up and optimising the system, which lead me to write up some aspects of the process on a (non commercial) blog. The aim was to go beyond simply selecting an option in raspi-config and hoping for stability…
I hope this is useful for some of you:
Part One: Over clocking the Pi
– why overclock
– how to overclock using raspi-config
– manually setting overclock parameters using config.txt
[url]http://retroresolution.com/2015/11/21/overclocking-and-stability-testing-the-raspberry-pi-2-part-1/[/url]Part Two: Reliability / Stress testing
– overview of stress testing
– CPU testing with mprime
– obtaining, installing and running mprime
[url]http://retroresolution.com/2015/11/27/overclocking-and-stability-testing-the-raspberry-pi-2-part-2-mprime/[/url]Part Three: RAM testing with Memtester
– obtaining and installing Memtester
– single core testing and multicore running
[url]http://retroresolution.com/2015/11/28/overclocking-and-stability-testing-the-raspberry-pi-2-part-3-ram-check-with-memtester/[/url]Part Four: SD card storage reliability testing using the Stability Test Script
[url]http://retroresolution.com/2015/11/29/overclocking-and-stability-testing-the-raspberry-pi-2-part-4-sd-storage-testing/[/url]The topics I cover are:
Part One:
Why Overclock?
Raspberry Pi System Architecture
Overclocking, Hardware Lifespan, and Your Raspberry Pi’s Warranty
A Note On Overclocking and SD Card Stability
Raspi-Config Overclock Options
Editing Overclock Settings Within the Config.txt File
Help! What To Do If The Pi No Longer Boots After Applying Overclock Changes
Tested Overclock Values – Failures and SuccessesIn part 2 I look at stability testing in general, and introduce three tools.
Stress-testing the CPU with mprime (using all cores)In part 3: RAM testing with Memtester
-Obtaining and installing Memtester
-Running Memtester on a single core
-Running on multiple cores using several remote SSH shell confections
-Using the Screen tool to create multiple virtual shells in which to run Memtester on multiple coresPart 4, the final part covers reliability testing the SD card storage – an unreliable filesystem makes the Pi unusable.
12/01/2015 at 18:01 #111021ziguranaParticipantCool subject, and looking at your outline here, very thorough!
For the TLDR: what is your conclusion, how far can we go?12/03/2015 at 14:42 #111125dankcushionsParticipantgood work, thanks :) i do think the raspi-config default ‘pi2’ overclock is bad – SDRAM at 500 is very aggressive and caused instability on my system, whilst the cpu/core can run at 1000/500 without any voltage increase for me.
i’m interested in some more specific benchmarking. eg, with n64 performance i get sound and frame-rate issues on occasion, but i’ve not experimented enough to prove whether it’s GPU/CPU/core/memory/etc bound. i think mostly with emulation it’s likely to be CPU-bound, but when running shaders or 3d emulators at 1080p (how i run n64), that could change.
there’s a lot of GPU overclock options that i haven’t really looked at yet: http://elinux.org/RPiconfig#Overclocking_options
12/04/2015 at 17:41 #111217retroresolutionParticipantThanks for the positive feedback zigurana and dankcushions.
Regarding the TLDR ‘how fast can we go’, I wasn’t aiming to overclock to extreme limits, only to get my stock Pi 2 to run as fast as possible, whilst being as stable as I could make it (although I realise now that I haven’t included any GPU specific tests alongside the CPU, RAM, and SD card)
The final maximum settings I was able to achieve were:arm_freq=1050
core_freq=525
sdram_freq=450
over_voltage=3As dankcushions also discovered the raspi-config Pi 2 settings had an sdram_freq that was too high for the silicon in my particular Pi to handle; I was able to push the GPU and CPU higher than the raspi-config settings, albeit with slightly more over_voltage.
I did review extreme overclocking, and found one guy who really took this seriously, getting the CPU up to 1500mhz; he used a combination of liquid nitrogen on the CPU, and heating on the RAM to prevent it literally freezing!
He provides information in several posts on the Raspberrypi.org forums in a thread that can be found here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=10714912/06/2015 at 13:58 #111302OmnijaParticipantI tested using mprime and ended up with \Found 525 primes.
Wasn’t sure what the meaning of it is, since there wasn’t any elaborations on results and meanings?12/06/2015 at 20:31 #111329retroresolutionParticipantHi.
Assuming there were no error messages, that indicates all is okay with that test – mprime is searching for prime numbers in the range you specify; what matters is that the programme runs to completion without problems. It’s a very CPU intensive task, hence very useful for overclock testing.12/06/2015 at 22:39 #111349OmnijaParticipantOH ok thanks, i could only imagine how extensive it is when i noticed the cpu heat raising. Usually bays at around 50 but was raised to 70 during testing.
12/08/2015 at 18:10 #111459efraimsangilParticipantCongrats for your amazing article :)
12/09/2015 at 02:23 #111484MRKaneParticipantDon’t have anything to add, but just want to say that I love the article and “tinkering” as getting every stitch of performance out of a system really makes the difference!
EDIT:
I forgot that I do have something to add. When I was tinkering with this on my setup I found that having a larger than standard power supply (I’m now running a 3A one) appeared to improve stability while running overclocked with a full set of peripherals. It could have also been that my 2A supply wasn’t up to spec.12/10/2015 at 15:03 #111554retroresolutionParticipantHi Omninja,
Regarding temperatures, from my notes it seems that my Pi 2 would generally peak around 73 degrees Celsius when testing with mprime, with an ambient temperature somewhere between 20c and 25c. This is with the system overclocked with the settings I finally settled on (overvolt is +3, which increases the heat somewhat).
As long as the force_turbo option hasn’t been used (which at the time of writing will invalidate the warranty), the Pi’s governor will shut off the overclock if the temperature hits 85c, returning everything to the default values, until the temperature drops.
Running a real-world application, for example Rage Racer on the RetroPie Playstation emulator, it was around 50c. It seems that other emulators were also hitting about the same temp, including the megadrive 32x and Mupen64 N64 emulators. I believe all of these are single-core emulators, so they don’t drive the CPU as hard as the mprime test.
12/10/2015 at 15:04 #111556retroresolutionParticipantHi MRKane,
Thanks for the very positive feedback, it’s great to hear.
Regarding voltage, I’m using a well-built 2Amp psu, with in-built cable – As you note, this is critical for the Pi to work reliably, especially when overclocking. I wrote a blog post on the importance of the PSU, and some information regarding the quality of usb cables:
Looking after your Pi – Part 1 – The Importance of a Quality Power Supply (PSU)
The hardware I’m using is detailed in this post:
12/10/2015 at 15:06 #111558retroresolutionParticipantHi efraimsangil,
Many thanks for the congrats, it’s great to get positive feedback.
There’s more Pi / RetroPie posts in progress. Currently I’m adding articles on using the Raspbian command shell for those not used to Linux, or for command lines at all.
12/19/2015 at 15:57 #112108retroresolutionParticipantHi,
As mentioned above, I’ve now added posts on basic usage of the Command Shell for those not used to Linux, or for command lines at all:
The first post introduces various tools for monitoring the Raspberry Pi’s hardware and running programmes, and covers basic usage of the Package Manager (APT) tool for installing software from the command line:
Don’t Fear The Command Line: Raspbian Linux Shell Commands and Tools – Part 1
The second post focuses solely on navigating the file system from the shell, along with a useful package which can be installed to help visualise the file tree structure (as it’s very easy to get lost without a GUI to help guide you):
Navigating the Raspberry Pi’s File System. Raspbian Linux Shell Commands and Tools – Part 2
-
AuthorPosts
- The forum ‘Everything else related to the RetroPie Project’ is closed to new topics and replies.