Overclock Wiki

Riverstorm

Here's the other link that reports a bug and explains the relationship between core_freq, gpu_freq & avoid_pwm_pll=1 and gives some examples of how it works and valid values.

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=250

suprjami

Hey sorry for the delay, I don't come here much anymore, I idle on the IRC channel tho. Nice to meet you.

@riverstorm said:

core_freq and gpu_freq can be used independently if you use avoid_pwm_pll=1

Correct.

When setting the gpu_freq also setting core_freq or v3d_freq is redundant unless you want a different value

Correct.

Loosing the interrupt (analog audio) is not really relevant if you're using HDMI

Correct, although not everyone is using HDMI audio, some cabinet/CRT setups intentionally use the analog audio and even video via TRRS cable. I want to avoid suggesting settings which could ruin peoples' setups.

Here's the other link that reports a bug and explains the relationship between core_freq, gpu_freq & avoid_pwm_pll=1 and gives some examples of how it works and valid values.
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=250

Now that's interesting! That post by shalo is the first time I've seen the ability to separately set h264/isp/v3d "officially" mentioned, and contradicts the eLinux wiki, which is what I was originally going off. Maybe the ability to set those separately has been a feature added since 2012? Maybe the eLinux wiki author misunderstood?

I will correct this soon when I get around to it. Thanks very much for pointing this out.

This was the max overclock I could get...

Those are good thorough results, but documenting individual success/failure settings is beyond the scope of this wiki page and really beyond the scope of RetroPie. I'm sure you know just because your Pi can reach a certain speed doesn't mean everyone else's can. People can experiment with their own systems if they want to push the limits of their own individual Pi.

Considering the skill level of most users here, I would doubt the validity of most thorough overclocking tests beyond yours and mine and a few reliable others. If collecting such info is something you're interested in doing, the RPi Forums would be a better place to start.

However I will add that stress test thread. That looks like a nice varied set of tests which put different components through their paces. Thanks again!

My power supply is only 2A with 5.3V. I have a 4.2A 5V which vdrooped and few others that all drooped.

Yeah it's super tough to find a power supply which doesn't droop over 2A. The HP tablet charger is the only one I know which is good enough: http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple-is.html

Also note there's a polyfuse on the USB power connector which limits the amount of current you can draw from the power supply anyway. The most you can get thru the polyfuse reliably on a Pi 3 is 2.5A. That's fine because the most the SoC will draw under stress is 1.35A or so, anything over that is USB power usage, which is also limited by a 1.2A polyfuse on Pi 3. The only advantage to a higher-amperage power supply is (hopefully) more headroom before inevitable voltage droop. Nobody will ever draw 5A through the power connector on a Raspberry Pi, but I think you can supply beyond the input polyfuse limit via the 5V GPIO pins which are directly connected to the 5V power rail after the polyfuse iirc. The Pi 3 board layout diagram shows it. It's been a while since I looked.

You will likely find this page and its linked references of interest: https://github.com/superjamie/lazyweb/wiki/Raspberry-Pi-Power

suprjami

I've updated the page, you can see the changes in the most recent commit.

Evidently I had already documented setting the three components individually with the audio PLL disabled. I forget where I read that force_turbo was required, I have removed that for now as it doesn't seem to be correct.

The aim of the page is to guide the average RetroPie user, and right now I'm happy for the page to suggest overclocking by changing core_freq and gpu_freq in small increments. That's easy for most people to understand and produces "good enough" results.

Advanced users like yourself who really want to push limits and test thoroughly can steal the audio PLL to overclock the individual GPU components as required. That is documented correctly so I'm happy with it as-is.

Riverstorm

@suprjami said in Overclock Wiki:

Yeah it's super tough to find a power supply which doesn't droop over 2A. The HP tablet charger is the only one I know which is good enough:

Hey Suprjami thanks for the information. That happens to be the exact power supply I am using from the old HP tablets. It's a solid little work horse. I think they had a great tablet but it was either the wrong time or possibly a bad marketing campaign but still a shame to see it fail so spectacularly. Kind of like IBM OS/2 (Warp) vs. Windows. When they decided to discontinue the tablet I picked one up very reasonably priced for a little over $100 to check it out.

Apple's power supply was surprisingly disappointing. Anker I know makes a great little power supply I use often for charging but it suffered from the same drooping issues as Apple.

The gpu_freq I know is bumping up several parameters and that was the biggest draw I noticed. When I left gpu_freq at it's default I could bump some the other parameters and I was getting by with a 1A (just for testing).

The only advantage to a higher-amperage power supply is (hopefully) more headroom before inevitable voltage droop.

Yeah once you you start pushing things close to the amperage cap of your power supply it's quite a bit harder to maintain a consistent 5V or you need dual rails...well there seems to be arguments on both sides of that fence when it comes to 12V on PC's. A little overhead can be helpful in maintaining that consistent 5V hence a slightly larger power supply than recommended might not be a bad thing.

I think you can supply beyond the input polyfuse limit via the 5V GPIO pins which are directly connected to the 5V power rail after the polyfuse iirc.

The thought being they are protecting for things like over-voltage through USB but not directly connected to the GPIO pins which hopefully the connecting device is fused (or more Pi's would be blown). I think it's like 50mA max on the GPIO pins or something.

Thank you for the URL's. I will check out that information and updates.

suprjami

@riverstorm said in Overclock Wiki:

well there seems to be arguments on both sides of that fence when it comes to 12V on PC's

Some PC power supplies also need a rising load on the 5V rail in order to regulate the 12V rail well, the circuitry assumes the system draws 5V and 12V in a linear fashion. I am far from familiar with PC PSUs but I think that's an older pre-Haswell thing.

I think it's like 50mA max on the GPIO pins or something

Yeah that's a limitation of the SoC, you can only draw small transistor logic levels through the I/O pins and the 3.3v.

However the 5V GPIO pin is not fed by the SoC, it comes from the power connector and can supply power back to the SoC if so desired. Like this:

USB Power In ---- Polyfuse --+-- SoC
                             '-- 5V GPIO

Riverstorm

@suprjami said in Overclock Wiki:

However the 5V GPIO pin is not fed by the SoC, it comes from the power connector and can supply power back to the SoC if so desired. Like this:
USB Power In ---- Polyfuse --+-- SoC
'-- 5V GPIO

I was trying to point out the SoC is unprotected through the 5V GPIO pin you're basically circumventing the polyfuse correct?

What is the max (mA?) the 5V pin may deliver? If it's not tied in or governed by say the USB or board polyfuse? If at capacity i.e. - SoC 1.35A + USB 1.2A = 2.55A. In theory you're already over-provisioned even before using the 5V GPIO if using the recommended 2.5A power supply?

USB Power In ---- Polyfuse --+-- SoC
                             '-- 5V GPIO   <--- (SoC unprotected through 5V GPIO)

suprjami

@riverstorm said in Overclock Wiki:

I was trying to point out the SoC is unprotected through the 5V GPIO pin you're basically circumventing the polyfuse correct?

Precisely.

What is the max (mA?) the 5V pin may deliver?

I don't know of anyone who has tested this to its limit.

If you're pulling power from a USB power supply, through the MicroUSB connector, and out the 5V GPIO pin, then you're limited to the polyfuse on the USB power connector which is rated at 2.5A. Polyfuses are not an exact thing, so one Pi might have its polyfuse pop at 2.6A and another might be able to pull right up to 4.9A. The fuse is rated to be stable up to 2.5A and definitely blow at 5A.

I've heard of people actively cooling polyfuses with a heatsink and fan to allow more current to be drawn through the fuse. That's on Arduino (a 3D printer RAMPS board) not on Raspberry Pi, but the same theory should apply to any polyfuse.

If you're feeding power in via the 5V GPIO connector (so no power supply in the MicroUSB connector) the limit is theoretically the 5V pin and PCB trace, but I suspect you'd run out of ways to draw enough current before you reached the board's physical limit.

In theory you're already over-provisioned even before using the 5V GPIO if using the recommended 2.5A power supply?

Correct, which is why power-hungry USB devices (eg: cordless game controllers which draw full 500mA to charge off USB) should be used via an externally-powered USB hub.

Riverstorm

I appreciate you answering all these questions beyond the scope as they have been very beneficial. If I can throw one more out there since we're talking about polyfuse ratings.

When you trip one I know it can take days/weeks(?) to recover so how does that play into say the stable rating vs. max rating? Do you have weird things happen as to what devices might work and what might fail? At least until it heals to it's full/max rating again or is it lowered each time?

Can it be heated beyond healing I mean within reason and/or does repeated tripping break down the chemical(s). I don't mean like taking a blowtorch to it kind of current.

I try and wrap my head around the idea that it's a chemical recovery vs. say throwing it in the freezer and be good to go in a few hours. I never quite understood the chemical physics of what is happening in layman's terms or like an analogy of it! ;)

theWinterDojer

A lot of good information here, thank you. I borrowed some of your settings and I appear to be stable, but I'd like your opinion on when to know how much testing is enough testing. I ran the stress test, memtest and sdbench. Passed all loops of memtest and stayed under 66° during the stress test. I'm gonna try some games that were giving me trouble before.

Is there any other testing you would recommend I do, or can I safely say I'm stable with these settings?

arm_freq=1350
gpu_freq=525
sdram_freq=575
sdram_schmoo=0x02000020
over_voltage=4
over_voltage_sdram_p=6         
over_voltage_sdram_i=4         
over_voltage_sdram_c=4

Riverstorm

@thewinterdojer said in Overclock Wiki:

Is there any other testing you would recommend I do, or can I safely say I'm stable with these settings?

I think each boards stable settings are slightly different. There's probably a median range most boards work within but I would imagine there's plenty of variance. Even your current settings. I only managed 1260 where you're at 1350. That's a 7% increase.

The last 3 tests you didn't run would also be beneficial. Sysbench & cpuburn are going to simulate a real world load and the other is going to really heat it up. If you heat up to much with sysbench and your Pi throttles then don't even bother with cpuburn as it heats it up even more. They are more about time. Roughly 15 minutes to see where the temp caps.

While the Linpark bench (the very last test) is where I experienced most of my issues. I could play games for hours with an arm_freq=1300 and other higher settings but I couldn't pass the bench even once at 1300. It really tests the stability with your current settings.

All the other test I was able to pass too with no issues but the Linpark bench is where I crashed frequently and spent most of my time. I would dial the settings down and try again. After I found a stable overclock I ran through it about 5 times. It's only about 2 to 3 minutes for each run.

I think if you follow this guys page from about the middle where the tests start to the start of the results you'll end up with a fairly stable overclock by the time you're done. It really doesn't take to long. You can see his results at the end.

The last thing that I noticed is when I cranked my gpu_freq up to high it wouldn't boot. I believe holding the shift key down while booting bypasses the /boot/config.txt or some type of default settings.

The issue is I couldn't get RetroPie to load. I would see the RetroPie logo and also the ES logo while loading but then I would have a hodge podge of the carbon theme wallpaper like 1 inch squares spotty all over the screen and other parts where blank. Totally unresponsive to any controls.

My thought was does ES take a minimum amount of memory to load and the shift/boot settings can't accommodate it. Basically is there enough memory to load ES with the shift/boot settings. I finally gave up and reloaded my backup image.

Small overclock adjustments that crashed the Pi during testing only where fine but when I crashed it where it wouldn't bootup that was a show stopper but not exactly sure why RetroPie wouldn't load with shift/boot.

theWinterDojer

@riverstorm Thanks! I'm going to make a backup and try those last three tests, starting with sysbench and see how that goes first. This will sound stupid but could you please clarify what throttling means in this setting? I thought it was the ability for the CPU to be governed up and down based on what is being asked of it, but with overclocking throttling seems to be when it is being pushed so far the temp limit is reached?

Also, I am not knocking the testing because I am a perfectionist, and I want my settings to be the safest while squeezing out every inch of performance I can, but can you think of any real world scenario in which the pi would actually be pushed that far? I think I achieved the 1350 just because I didn't test my settings as thoroughly as you did. Personally, I think the hours of gameplay is a good indicator of the stability, and would be good enough for me in this case, but I'd like to hear your perspective on that.

I'm still going to do them however, I will report back with hopefully good results!

Riverstorm

@thewinterdojer said in Overclock Wiki:

I thought it was the ability for the CPU to be governed up and down based on what is being asked of it, but with overclocking throttling seems to be when it is being pushed so far the temp limit is reached?

That's correct. I believe it idles at 600Mhz. When needed and will boost to higher frequencies (overclock settings) as needed. The governor tells it how to use those settings such as always run at maximum or minimum speed or the default (on-demand) which depending on CPU load will throttle up when needed and back down when unnecessary.

When it hits the cap (85C) it has to throttle to reduce the temp. The temp cap is an adjustable setting. I use a PC and Putty to monitor the CPU load/temp while testing or sometimes I just hook it up to a monitor (either HDMI directly or using and DVI to HDMI adapter) and the network (no sound but it's not needed for stress testing) instead of the TV.

If you have a command or script you like to run use the watch command for monitoring.

but can you think of any real world scenario in which the pi would actually be pushed that far?

I'm not sure what you're asking you mean temp. testing?

Personally, I think the hours of gameplay is a good indicator of the stability, and would be good enough for me in this case

If it's good enough for you it's good enough for me! ;) Actually I did ran that way for a long time. I suppose one of the biggest issues might be the Pi crashing, locking up or file corruption. None of which I had an issue with. I guess it was more out of curiosity and like you being a bit of a perfectionist knowing this is a solid overclock.

Most of the games I play run perfectly well but if tweaking outside the stable overclock was the difference between making a game playable I would do it. If I start having issues I would just keep that in the back my mind.

Riverstorm

@theWinterDojer - Here's a script I use. It gives you the CPU and GPU temp in Celcius along with the CPU speed in Mhz. Real clean and readable. You can create a file like cgtemp.sh or whatever you like to name it in your home folder. Then run chmod +x cgtemp.sh to give it executable permissions. Then run it or use watch cgtemp.sh which will automatically update your screen. The refresh rate is a watch adjustable setting. I dump all my scripts in a bin folder and create bash aliases which really isn't needed.

cpuSpeed0=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
cpuSpeed1=$(($cpuSpeed0/1000))

cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))

gpuTemp0=$(/opt/vc/bin/vcgencmd measure_temp)
gpuTemp0=${gpuTemp0//\'/°}
gpuTemp0=${gpuTemp0//temp=/}

echo
echo CPU Speed: $cpuSpeed1" MHz"
echo
echo CPU Temp: $cpuTemp1"."$cpuTempM"°C"
echo GPU Temp: $gpuTemp0

theWinterDojer

@riverstorm said in Overclock Wiki:

When it hits the cap (85C) it has to throttle to reduce the temp. The temp cap is an adjustable setting.

Ah hah. Okay, this makes much more sense now, I can finally put that to rest.

but can you think of any real world scenario in which the pi would actually be pushed that far?

I was asking if you could think of any scenario in which a game or application currently attainable on the pi, would create a similar strain caused by the sysbench and cpuburn tests? It just seems that anything we encounter would not actually be as strenuous on the Pi in a real world scenario, but then again I only play games and don't do much else with it.

If it's good enough for you it's good enough for me! ;) Actually I did ran that way for a long time. I suppose one of the biggest issues might be the Pi crashing, locking up or file corruption.

That is my only concern, corrupting the data, but I'm going to back up with my current settings and then run the tests. If anything happens I will keep that in mind like you said, dial back and try again.

I had one other concern running the sdbench, wondering by chance if you knew the answer. During the test, it says that it's writing 512mb of data or something along those lines. Is it actually writing a file somewhere that I can go in and delete? Or is it maybe removed automatically or not saving at all?

Thanks again!

theWinterDojer

@riverstorm Awesome! I was looking for something like this, honestly htop is not that readable to me and does not give the temperatures if I remember correctly. I'm going to set this up when I get home.

dankcushions

@thewinterdojer

I was asking if you could think of any scenario in which a game or application currently attainable on the pi, would create a similar strain caused by the sysbench and cpuburn tests? It just seems that anything we encounter would not actually be as strenuous on the Pi in a real world scenario, but then again I only play games and don't do much else with it.

recompiling something by source. e.g. any of the experimental packages.

Riverstorm

@thewinterdojer said in Overclock Wiki:

I had one other concern running the sdbench, wondering by chance if you knew the answer. During the test, it says that it's writing 512mb of data or something along those lines.

I think it runs it's own maintenance task and cleans up after itself. No virtual sprawl of files all over! :)

I was asking if you could think of any scenario in which a game or application currently attainable on the pi, would create a similar strain caused by the sysbench and cpuburn tests?

Dank is right. I had no idea my settings were unstable until I actually encountered my problem when downloading experimental packages via source. During that process it really pushes the Pi at a time you don't want corruption.

theWinterDojer

@riverstorm Oh wow, okay then, I will probably stay clear from those unless there is something I absolutely need. To be honest I don't think I've even looked at what's there.

Edit: There was something else I meant to ask you. For gpu_mem, I've heard memory splitting hasn't really been necessary since Pi 2. Do you think it's something I should look into?

Riverstorm

@thewinterdojer said in Overclock Wiki:

Edit: There was something else I meant to ask you. For gpu_mem, I've heard memory splitting hasn't really been necessary since Pi 2. Do you think it's something I should look into?

I think there's others that can answer that better and know how much is needed for ES, fancy themes or some of the other neat things people are doing that require more memory. I don't even remember why I bumped to 320 vs the default I think is 256 which is more than adequate I am sure for most things.

If there's an experimental package like AdvMAME, Daphne, ScummVM (there's some good ones) you want to run I would still do it. What I do is add my overclock settings to /boot/config.txt but comment them out. Then setup everything the way I want, make a backup, restore to a bigger SD card, expand it, enable the settings and copy over the bigger files for Daphne, etc.

That way I have a backup but also the original SD card as a secondary backup. I experiment on the bigger "production" card until I am comfortable with additional changes and tweaks then I go back to my original card to implement those changes. Then rinse and repeat back to the production card. The only time I wipe the original card is when a new image is released and I start from scratch. Just don't forget to backup those high score files before wiping your production card which I loose all the time. :)

I worry more about crashes and corruption when my arm_freq was to high. Heat not as much. If you get throttled during an install you're probably ok even though it's running slower.

With games that may push the card to throttle due to heat will be obvious when suddenly you take a huge performance hit stuttering and wondering what just happened. Still probably ok even though annoying. :)

If that's that case then you could look into some cooling solution either passive (i.e. - lower your overclock) or active (heatsink, fan, water). I suppose water is reserved for the elite building custom loops. I remember when it was that way with computers.

Now with these sealed closed loop systems being so cheap, readily available and easy to install it really puts them into the hands of the average consumer that doesn't need to have any fancy skills or knowledge. Just don't buy a Pi secondhand from the guy who was water cooling it. He probably pushed it way beyond spec! :)

theWinterDojer

@riverstorm

I'm going to look into some of the experimental stuff, I haven't heard of Daphne or ScummVM. That's actually a really good idea having a test and production card, I have an extra one lying around so I think I may do that as well!

Heat doesn't appear to be an issue with my build yet, got some high quality thermal tape w/ heatsinks and fan, it does the job just fine. I'm curious to see how it will go tonight when I run the tests. Thanks for all the info, I appreciate it.