Homepage Forums RetroPie Project Everything else related to the RetroPie Project Overclocking and Stress / Reliability testing the Raspberry Pi

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #111009
    retroresolution
    Participant

    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 Successes

    In 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 cores

    Part 4, the final part covers reliability testing the SD card storage – an unreliable filesystem makes the Pi unusable.

    #111021
    zigurana
    Participant

    Cool subject, and looking at your outline here, very thorough!
    For the TLDR: what is your conclusion, how far can we go?

    #111125
    dankcushions
    Participant

    good 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

    #111217
    retroresolution
    Participant

    Thanks 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=3

    As 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=107149

    #111302
    Omnija
    Participant

    I 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?

    #111329
    retroresolution
    Participant

    Hi.
    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.

    #111349
    Omnija
    Participant

    OH 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.

    #111459
    efraimsangil
    Participant

    Congrats for your amazing article :)

    #111484
    MRKane
    Participant

    Don’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.

    #111554
    retroresolution
    Participant

    Hi 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.

    #111556
    retroresolution
    Participant

    Hi 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:

    Overview of Raspberry Pi and retro-gaming system hardware

    #111558
    retroresolution
    Participant

    Hi 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.

    #112108
    retroresolution
    Participant

    Hi,

    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

Viewing 13 posts - 1 through 13 (of 13 total)
  • The forum ‘Everything else related to the RetroPie Project’ is closed to new topics and replies.