Overclock Wiki

Riverstorm

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.

joel_fm

@riverstorm reading through your posts, but I didn't see which hardware you're running these settings on, Pi 3 or 2?

joel_fm

@suprjami thanks for the answers on here, made a lot of confusing documents more clear. Wondering why however, on your base settings you set total_mem, as it's default with jesse and beyond, correct?

Riverstorm

@joel_fm said in Overclock Wiki:

@riverstorm reading through your posts, but I didn't see which hardware you're running these settings on, Pi 3 or 2?

Yes, on the Pi 3. I never tried testing the 2.

theWinterDojer

@riverstorm

I just got around to creating the script and I am getting an error: "Could not find watchtemp.sh".

This is what I did:

Created a file watchtemp.sh and copied your script into it
Place watchtemp.sh in /home/pi/
Made is executable with chmod +x watchtemp.sh
Run with watch watchtemp.sh

I tried naming it something else, but still got the same error. /home/pi/ is my home folder where I have other scripts including the stress tests. Am I missing something here maybe?

Riverstorm

@thewinterdojer said in Overclock Wiki:

I just got around to creating the script and I am getting an error: "Could not find watchtemp.sh".

I have it setup as bash alias. If you're in your home directory try watch ./watchtemp.sh. The . denotes the current directory and since it's not in your $PATH you use ./ to tell it where the executable is located. Anyway I think that should work.