• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login

Overclocking the Pi3b+ GPU (Results)

Scheduled Pinned Locked Moved General Discussion and Gaming
pi3 b+overclockgpu
133 Posts 18 Posters 39.5k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B
    Brunnis @quicksilver
    last edited by 6 Mar 2019, 11:15

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

    H Q 2 Replies Last reply 6 Mar 2019, 11:53 Reply Quote 1
    • H
      hhromic @Brunnis
      last edited by 6 Mar 2019, 11:53

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

      1 Reply Last reply Reply Quote 0
      • Q
        quicksilver @Brunnis
        last edited by quicksilver 3 Jun 2019, 12:21 6 Mar 2019, 12:18

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

        B 1 Reply Last reply 6 Mar 2019, 12:33 Reply Quote 0
        • B
          Brunnis @quicksilver
          last edited by Brunnis 3 Jun 2019, 13:21 6 Mar 2019, 12:33

          @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).

          Q 1 Reply Last reply 6 Mar 2019, 13:56 Reply Quote 0
          • Q
            quicksilver @Brunnis
            last edited by quicksilver 3 Jun 2019, 15:49 6 Mar 2019, 13:56

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

            B 1 Reply Last reply 10 Mar 2019, 09:49 Reply Quote 0
            • B
              Brunnis @quicksilver
              last edited by 10 Mar 2019, 09:49

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

              P Q 2 Replies Last reply 10 Mar 2019, 10:31 Reply Quote 0
              • P
                pjft @Brunnis
                last edited by 10 Mar 2019, 10:31

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

                B 1 Reply Last reply 14 Mar 2019, 09:02 Reply Quote 0
                • Q
                  quicksilver @Brunnis
                  last edited by 10 Mar 2019, 21:27

                  @Brunnis I have had emulation station crash twice as well (same message). Nothing since I've turned my sdram from 600mhz to 550mhz (coincidence?) Ill continue to monitor as well. If it happens again I'll turn off all overclocks to verify if it's an overclock issue or ES issue.

                  1 Reply Last reply Reply Quote 0
                  • B
                    Brunnis @pjft
                    last edited by 14 Mar 2019, 09:02

                    @pjft I'll see if I can get this for you when I've run the current test. Then again, it might not be necessary, since the Pi indeed seems to be stable with default 450 MHz SDRAM. I've run it for four days straight and no issue so far. This is longer than I've managed with 500 or 550 MHz previously, so I'm hopeful. On Sunday, if the board is still stable, I plan to jack SDRAM voltage up to 1.325V and run a new test at 500 MHz. If that's stable, I'll continue to increase the frequency and see where I'll end up.

                    1 Reply Last reply Reply Quote 2
                    • B
                      Brunnis
                      last edited by 17 Mar 2019, 22:29

                      I ran a week-long test at default settings and experienced no crashes. So, I think we can rule out software issues. My Pi 3B+ is simply not stable at 500 MHz SDRAM without extra voltage. I decided to push the sdram_over_voltage_p setting to 4, which means 1.3V. That's +0.075V over default and it's the maximum allowed value according to the memory module's datasheet (although a maximum of 1.4V is actually supported by the Pi). I've now started a new test at 550 MHz and it's been running for 24h without crashing.

                      Q 1 Reply Last reply 18 Mar 2019, 01:53 Reply Quote 0
                      • Q
                        quicksilver @Brunnis
                        last edited by 18 Mar 2019, 01:53

                        @Brunnis are you doing anything specific to test? Are you just running memtester on a continuous loop?

                        B 1 Reply Last reply 18 Mar 2019, 07:10 Reply Quote 0
                        • B
                          Brunnis @quicksilver
                          last edited by Brunnis 18 Mar 2019, 07:10

                          @quicksilver Memtester did not catch this. I just let it sit at the EmulationStation menu, since that seemed very effective at uncovering the instability. I had tested for at least 24h at 550 MHz and Memtester did not find any issues. Could be because the troublesome address(es) are located in an area used by Raspbian (I believe I tested 800 MB). Or the load put on the RAM by EmulationStation is just what’s needed to lure out the failure condition in this specific hardware sample.

                          This is one of the insidious aspects of overclocking: you test the overclock with something considered as ”high load” and then end up having issues in comparably ”low load” scenarios. Instruction mix and access patterns are key here. What I usually do when I overclock desktops is that I find the highest stable frequency at a specific voltage, using a few different tests. I then increase the voltage by 0.05. This reduces the likelihood that you’re operating on the verge of stability and ensures that you have some headroom for transistors that did not get exercised enough (or at all) by whatever test you ran.

                          1 Reply Last reply Reply Quote 1
                          • B
                            Brunnis
                            last edited by 25 Mar 2019, 07:21

                            Quick update: The board is not stable with SDRAM @ 550 MHz and 1.35V. So, time to test lower frequencies. I haven't bothered starting another test yet, though. Either way, this board is not all that fond of higher frequencies. Guess that's to be expected, given that the PI 3B+ can pretty much be considered overclocked from the factory (there's a very small margin for higher frequencies on the CPU and the memory is actually only specified for 400 MHz operation).

                            Q 1 Reply Last reply 29 Mar 2019, 18:12 Reply Quote 0
                            • EfriimE
                              Efriim
                              last edited by Efriim 25 Mar 2019, 21:16

                              RPI3B+
                              I did some under clocking to see where I am

                              arm_freq=900
                              gpu_freq=250
                              sdram_freq=400
                              over_voltage=-2 #Drop voltage to the default over_voltage_minimum 1.2000V*
                              #over_voltage_sdram_min=-17**
                              

                              I was surprised as the emulations are largely the same all around, comparatively.
                              Most noticeably sound will drop during reads, in about every other game that is written that way.
                              The slowdown in Metal Gear Solid is exactly the same.
                              Dreamcast, Deadly skies, has its moments with I guess 15-30fps though I don't know how to display fps for reicast.
                              Armored Core 3 for PSP, drops down to a cool almost manageable 15fps.
                              GLideN64, Castlevania, nearly perfect.
                              Boot time lengthened maybe 2 seconds, and another 2 seconds loading ES.

                              Impressive results, probably because of the L2 cache that it is alone better than the rpi2.
                              I double checked the config with vcgencmd.

                              *The ARM CPU and the AVS.
                              I'll add a table(a.) to make this information easier to assess and analyze, I collected a lot of data including over_voltage_avs with vcgencmd get_config int | grep -E 'over_voltage'
                              **The over_voltage_sdram_min
                              This wholly took me a day, I tested a lot of values. I'll add a second table(b.) for the significant ones. I need to get some sleep before I do that.

                              1 Reply Last reply Reply Quote 0
                              • EfriimE
                                Efriim
                                last edited by Efriim 26 Mar 2019, 12:27

                                Here it is I'm finally done.
                                You can use spread32 or OpenOffice to view the book1voltage.xls
                                I thought I was going to learn more about the AVS but it was much too inconsistent to make progress yet. There are some maxims that are easy to read and may be useful.

                                There are a few save utilities, save files, a font pack and and PSP compatibility sheet. I have internet no longer, so this is my goodbye gift and farewell.

                                I have internet again, what was only a day... I added a revision with more room to add variables.

                                1 Reply Last reply Reply Quote 0
                                • Q
                                  quicksilver @Brunnis
                                  last edited by quicksilver 29 Mar 2019, 18:12

                                  @Brunnis For a while it seemed like everything was ok but now I am getting "Emulation Station Crashed" messages again, about once per day. Almost always seems to occur when I have left my pi idle in ES and then come back to see that message on my screen and the pi is unresponsive (have to reboot via SSH). Im completely removing my overclock now to see if this is in anyway the issue.

                                  The interesting thing is that I have overclocked all the pi's I have ever owned and have done extensive stability testing on all of them but I have never seen this ES crashing issue before I updated to the 4.4 stretch image needed for my 3b+.

                                  Q 1 Reply Last reply 30 Mar 2019, 01:33 Reply Quote 0
                                  • Q
                                    quicksilver @quicksilver
                                    last edited by 30 Mar 2019, 01:33

                                    Well, emulation station just crashed again for me. This time with no overclock. Each time it crashes I get a little pop up suggesting to check ROM folder permissions and GPU split.

                                    @pjft is there a log I can check to see why ES keeps crashing for me?

                                    P EfriimE 2 Replies Last reply 30 Mar 2019, 07:02 Reply Quote 0
                                    • EfriimE
                                      Efriim
                                      last edited by Efriim 30 Mar 2019, 01:56

                                      Increase the virtual memory that ES uses in the "start" menu. "other settings"; "vram limit"

                                      Reset rom folder permissions is in RetroPie Setup >> Configuration / tools >> resetromdirs
                                      and it should be safe to use.

                                      I don't know about the logs, there may be one in /dev/shm/ after a crash.

                                      There could be a bad video, you could try changing "UI Settings" ;; "GamelistView Style" to "detailed".

                                      I usually have to increase the v-ram limit.

                                      EfriimE 1 Reply Last reply 30 Mar 2019, 02:55 Reply Quote 0
                                      • EfriimE
                                        Efriim @Efriim
                                        last edited by Efriim 4 Jan 2019, 14:17 30 Mar 2019, 02:55

                                        sdram_freq=600
                                        p=7
                                        i=3
                                        c=3

                                        1 Reply Last reply Reply Quote 0
                                        • EfriimE
                                          Efriim
                                          last edited by Efriim 30 Mar 2019, 03:35

                                          Also the RPi3B and RPi2Bv1.2 use the BCM2837A0 with Cortex-A53
                                          The RPi3B+ uses the BCM2837B0 a revision with fundamentally the same quad-core ArmV8 Cortex A53 but with power optimizations all around and for the dual-core videocoreIV, aswell the obvious heatspreader over the top.

                                          I originally thought they were the same too.

                                          I read also that the 3B used armv7 with the older firmwares although it had support for the 64 bit armv8. I can't say that was a reliable source though.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post

                                          Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                                          Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.

                                            This community forum collects and processes your personal information.
                                            consent.not_received