Overclocking the Pi3b+ GPU (Results)

Brunnis

@quicksilver Thanks for the results! Out of curiosity, how does the instability manifest itself when you push the core_freq too far? I'm asking because I just changed from using a large heatsink sandwich to a Flirc case and I'm having issues. With the previous heatsink, I had run stability tests for days in total and saw no issues at all. With the Flirc case, I quickly ran into a few issues:

Crash (black screen) while at Raspbian desktop
Floating point error while running sysbench (within 30 minutes)
Tainted kernel (memory paging issue) while idling in RetroPie over night. EmulationStation still running, but not responding to input.

My current quess is that these issues have mainly cropped up due to a temperature difference. The Flirc case is not as good at cooling the Pi as the heatsink sandwich and this probably pushes the system over the edge. It still doesn't explain the tainted kernel issue at idle, though. Maybe that issue was there before changing case.

I'm going to try three things:

Increase CPU voltage one step
Lower core_freq overclock from 600 to 550 MHz
Increase SDRAM voltage one step

Brunnis

A small FYI (I think we've touched on this before in this thread):

On my Pi 3B+, only over_voltage=1 has an effect. Increasing over_voltage setting to 2 or more has no effect at all. Maximum allowed CPU voltage is 1.4V and since my Pi already runs at 1.375V, it makes sense that any setting higher than 1 (which adds 0.025V) would have no effect.
Default SDRAM voltages on my Pi are: sdram_c=1.25V, sdram_i=1.25V, sdram_p=1.225V. The over_voltage_sdram setting assumes 1.20V is default. So, using over_voltage_sdram=1 has no effect on my board (since it's 1.225V, which is the same or lower than the defaults). Using over_voltage_sdram=2 only affects sdram_p (it's raised to 1.25V). Using over_voltage_sdram=3 finally increases voltage on all three SDRAM rails to 1.275V.

I don't know if the defaults are the same for all Pi 3B+ boards. Check your voltages with:

for id in core sdram_c sdram_i sdram_p ; do echo -e "$id:\t$(vcgencmd measure_volts $id)" ; done

Please note that you should put a load on the CPU before running this command, otherwise you'll just see the default 1.2V used in downclocked state.

quicksilver

@Brunnis instability from having core freq too high has always shown up for me as a freeze. Quake 3 is running but suddenly locks up, though I can still ssh in and reboot my pi. I should note that my max overclock is only achievable with maximum overvoltage (1.397v, not sure why your pi won't go this high), anything less will freeze very quickly at these speeds. If I overclock v3d frequency too high I get visual artifacts onscreen followed by a freeze.

Twice I encountered an issue where I left my pi idle in emulation station to find that it had frozen hours later. One of those times my pi was overheating and my case fan which is programed to turn on at 65C was not on. Not entirely sure what would cause the pi to overheat when idle. But after removing my sdram and CPU overclocks I have not had that issue since. I haven't had time to thoroughly test them yet so I'll just leave them off for now.

Brunnis

@quicksilver No, you misunderstood me. My Pi also goes up to 1.39V. However, since default voltage is 1.375V, the only over_voltage setting that does anything is over_voltage=1 (which will give 1.39V). The Pi is not allowed to go over 1.4V, so setting over_voltage to 2 or higher will still result in the same 1.39V as over_voltage=1.

Thanks for sharing your experience. That over heating condition sounds...weird. I have modified a few of my overclock settings and will see if that helps (lowered core_freq from 600 to 550, lowered video related clocks from 400 to 367 and increased SDRAM voltages by 0.025V).

arm_freq=1475
core_freq=550
v3d_freq=367
h264_freq=367
isp_freq=367
sdram_freq=550
over_voltage=1
over_voltage_sdram_c=3
over_voltage_sdram_i=3
over_voltage_sdram_p=2
temp_soft_limit=70

quicksilver

@Brunnis are you sure about the over voltage values? I just did a test and this is what I got on my pi3b+:

No over voltage= 1.344V
Over_voltage 1= 1.369V
Over_voltage 2= 1.388V
Over_voltage 3= 1.394V (not 1.397v like I said earlier)

So for me over_voltage 3 is max setting. Are you sure yours is different?

Brunnis

@quicksilver Yep, absolutely sure. Default voltage for mine is 1.375V. They probably bin the chips with different default voltages during production, just like AMD and Intel do.

So, you're lucky and have received a chip that's two bins lower on the voltage scale than mine!

quicksilver

@Brunnis the official raspberry pi documentation is very vague about this. I see it uses adaptive voltage scaling (is this used based on CPU load?) but their default voltage table doesn't seem very accurate:

"This table describes the overvoltage settings for the various Pi models. The firmware uses Adaptive Voltage Scaling (AVS) to determine the optimum voltage to set. Note that for each integer rise in over_voltage, the voltage will be 25mV higher."

Version Default Overvoltage Setting
Pi 1 1.2V 0
Pi 2 1.2-1.3125V 0
Pi 3 1.2-1.3125V 0
Pi Zero 1.35V 6

Brunnis

@quicksilver Yup, the documentation doesn't really go into details on that. Would be interesting if others reported their default voltages.

By the way, I let my Pi stand on the EmulationStation main menu over night, using the revised overclocking settings posted above. No issues this time. I'll let it run continuously and let you know if the issue is 100% fixed. If so, I don't think I'll investigate which exact setting it was that provided stability. Already spent too much time tinkering with this overclock...

Brunnis

Ugh... Just locked up again. Video is outputting fine, but USB is down (at the very least). Nothing in /var/log/messages or /var/log/syslog this time. I'll remove overclock settings one by one to see what fixes it. Actually, I should probably start by removing all overclock settings to see if it's even stable at stock...

quicksilver

@Brunnis Im am curious about this as well so please report back if you find anything out. Im wondering if the ES freeze issues I have had could be the same or related to yours. Odd that we can hammer the pi with quake 3+sysbench+memtester and run for hours but sitting idle in ES would lock things up?

Brunnis

@quicksilver Yeah, it is quite odd, really. That's why I'll probably let it sit at stock settings over the weekend and see if it can survive that. Then I'll start adding back the overclock. I'll let you know how it goes.

hhromic

@Brunnis @quicksilver In case you are not aware, check the EmulationStation Power Saver feature. It was implemented in this PR: https://github.com/RetroPie/EmulationStation/pull/172

In summary, if disabled, ES keeps animating objects even if they don't move, loading the CPU/GPU. If power saver is activated, these animations are suspended at different degrees depending on the power saver option selected.

quicksilver

@hhromic I checked and the PS feature is disabled on my pi. However the freeze has occurred each time for me just sitting idle on the systems select carousel so there shouldn't be anything to animate.

Brunnis

@quicksilver A small update: I've been running my Pi at the EmulationStation main menu since Friday. Findings so far:

No overclock: Stable (3 days)
core_freq=600 + over_voltage=1: Stable (2 days)
sdram_freq=550: Freeze within 4 hours (unusually quick this time)

Now testing with SDRAM @ 500 MHz. It should be mentioned that 500 MHz was the default SDRAM frequency when the Pi 3B+ launched. It was later lowered to 450 MHz (same as the 3B) via a software update, along with introducing the temp_soft_limit and setting it to 60C (to make the CPU throttle down from 1.4GHz to 1.2GHz if it exceeds 60C). These measures were put in place because people were reporting strange stability issues, with 3B+ Pis becoming unresponsive or rebooting. The Pi Foundation determined that this could be due to a temperature dependence and/or SDRAM being pushed too far. Those changes are of course not very nice for the user, since they largely remove the performance improvement the 3B+ was supposed to bring. Keeping the SoC below 60C requires decent cooling, even without loading all four cores or the GPU.

So, it's of course entirely possible that I'm running into such an issue. This is one of the reasons I generally don't overclock anymore (it used to be one of my main hobbies). It can be very hard to get a system fully stable, even if you are quite serious at testing the overclock.

We'll see where this ends up. If 500 MHz is stable on the SDRAM, I'll keep increasing it to see where instability occurs. I'll also try with some extra voltage.

hhromic

@Brunnis said in Overclocking the Pi3b+ GPU (Results):

It should be mentioned that 500 MHz was the default SDRAM frequency when the Pi 3B+ launched. It was later lowered to 450 MHz (same as the 3B) via a software update, along with introducing the temp_soft_limit and setting it to 60C (to make the CPU throttle down from 1.4GHz to 1.2GHz if it exceeds 60C). These measures were put in place because people were reporting strange stability issues, with 3B+ Pis becoming unresponsive or rebooting. The Pi Foundation determined that this could be due to a temperature dependence and/or SDRAM being pushed too far. Those changes are of course not very nice for the user, since they largely remove the performance improvement the 3B+ was supposed to bring. Keeping the SoC below 60C requires decent cooling, even without loading all four cores or the GPU.

That is very dissappointing indeed :(. I can confirm that indeed my RPI 3B+ tends to hit the default soft-limit quite often without a heatsink and without overclocking inside a NesPi Case. I should monitor more carefully how often and for how long it does this and re-install a basic heatsink despite the "enhanced thermal management" of the chipset. Thanks for bringing this up.

quicksilver

@Brunnis I read through the whole thread on the official raspberry pi forums that discussed the issues with the sdram freq. They only lowered the pi3b+ sdram freq to 450mhz temporarily. Current firmware should have it back at 500mhz. Judging by that thread it looks like the issue was resolved sometime late summer of this past year.

@hhromic being confined in a case with no fan or poor ventilation is sure to hinder even the improved thermals of the pi3b+. At some point the little heatspreader isnt going to be able to do much if that heat has nowhere to go. My kintaro snes case has a beefy heatsink plus the ability to turn a small case fan on/off automatically based on CPU temp. What I did was increase the temp soft limit to 70C and set that fan to turn on at 60C. That way my pi would stay nice and cool and never get thermal throttled.

Brunnis

@quicksilver said in Overclocking the Pi3b+ GPU (Results):

I read through the whole thread on the official raspberry pi forums that discussed the issues with the sdram freq. They only lowered the pi3b+ sdram freq to 450mhz temporarily. Current firmware should have it back at 500mhz. Judging by that thread it looks like the issue was resolved sometime late summer of this past year.

Thanks for the info. I read through large parts of that thread, but must have missed that. Did they say what they did to fix it? Or maybe they determined that the temp_soft_limit=60 was enough?

EDIT: It's this thread, right? I read it from page 15 to the end (June 13 2018 and onwards), but didn't see any mention of reverting back to 500 MHz as default value...

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=208821

@quicksilver said in Overclocking the Pi3b+ GPU (Results):

being confined in a case with no fan or poor ventilation is sure to hinder even the improved thermals of the pi3b+. At some point the little heatspreader isnt going to be able to do much if that heat has nowhere to go. My kintaro snes case has a beefy heatsink plus the ability to turn a small case fan on/off automatically based on CPU temp. What I did was increase the temp soft limit to 70C and set that fan to turn on at 60C. That way my pi would stay nice and cool and never get thermal throttled.

I should mention that in my own tests, without overclocking and with 20C room temp, my Pi 3B+ exceeds 60C with just two CPU threads loaded while installed in a Flirc case. Using an even beefier "armor case" (heatsink sandwich that covers the whole pi, including bottom side), loading up two threads leads to 57C. Three threads leads to 62C.

I'd say the Pi 3B+ is slightly harder to cool than many people seem to think. Even with a good heatsink, most people will see throttling even at moderate CPU loads. Unless you install a really large heatsink, a fan will be needed to prevent throttling (like you've done).

quicksilver

@Brunnis looks like I may have been mistaken. At one point in that thread they started discussing a different issue with Ethernet that was resolved. It looks like the sdram issue "fix" was to lower the default to 450mhz and leave it there (as you said). It should be noted though that it was a very small percentage of boards that couldnt handle 500mhz according to that thread so most people shouldn't have any issues at 500mhz. Also interesting that their official documentation still lists 500mhz as default sdram frequency for the 3b+.

My best 3b+ can pass memtester test at 630mhz but in practical usage it will freeze up after a period of time so I have dropped it down to 550mhz. I have noticed a slight improvement on some N64 games with the sdram freq set higher but it's maybe a one fps increase at best so it's not worth pushing too far and risking instability.

Brunnis

@quicksilver I get some weird results from my stability tests. I’ve been testing with SDRAM at 500 MHz for several days (everything else at default). During this time, I’ve had EmulationStation crash two times (message shows up that says ES has crashed) and one instance of being thrown out from ES to the terminal with a stack trace printed. What’s weird is that I’ve previously tested extensively with Quake 3, sysbench and memtester and couldn’t find any instabilities even at 550 MHz. And now this.

I’ll re-test at default 450 MHz for a week. If that’s stable, my Pi’s memory simply can’t handle 500 MHz, at least not without jacking up the voltage.

pjft

@Brunnis if you'd want to share those stack traces I'd be happy to see if there's anything that can be learned from them.

Not that I don't trust ES to be stable, but since those reports aren't unheard of (only hard to actually systematically reproduce), maybe trying out Kodi could be a better/alternative test to confirm that the issue is not really ES.