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.6k 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

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

      pjftP quicksilverQ 2 Replies Last reply Reply Quote 0
      • pjftP
        pjft @Brunnis
        last edited by

        @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 Reply Quote 0
        • quicksilverQ
          quicksilver @Brunnis
          last edited by

          @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

            @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

              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.

              quicksilverQ 1 Reply Last reply Reply Quote 0
              • quicksilverQ
                quicksilver @Brunnis
                last edited by

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

                B 1 Reply Last reply Reply Quote 0
                • B
                  Brunnis @quicksilver
                  last edited by Brunnis

                  @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

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

                    quicksilverQ 1 Reply Last reply Reply Quote 0
                    • EfriimE
                      Efriim
                      last edited by Efriim

                      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

                        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
                        • quicksilverQ
                          quicksilver @Brunnis
                          last edited by quicksilver

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

                          quicksilverQ 1 Reply Last reply Reply Quote 0
                          • quicksilverQ
                            quicksilver @quicksilver
                            last edited by

                            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?

                            pjftP EfriimE 2 Replies Last reply Reply Quote 0
                            • EfriimE
                              Efriim
                              last edited by Efriim

                              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 Reply Quote 0
                              • EfriimE
                                Efriim @Efriim
                                last edited by Efriim

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

                                1 Reply Last reply Reply Quote 0
                                • EfriimE
                                  Efriim
                                  last edited by Efriim

                                  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
                                  • pjftP
                                    pjft @quicksilver
                                    last edited by

                                    @quicksilver There's a log for the "current" session on ~/.emulationstation/es_log.txt (and there's a log for the previous session as well, which is likely es_log.txt.old or something, in case you restart ES before getting the log).

                                    It might not have anything useful, though, but it's certainly worth a shot.

                                    1 Reply Last reply Reply Quote 0
                                    • EfriimE
                                      Efriim @quicksilver
                                      last edited by Efriim

                                      @quicksilver
                                      Right after I replied to you about your ES crash. I have been using Ubuntu x86 Retropie for a while, anyway I booted up my raspberry pi the next morning and the first screen I see is ES has crashed. I still don't know what it was, I remember I had some experimental settings that I wanted to change first boot, but it was nothing extreme.

                                      I'm testing sdram_freq=650. P=8 I=6 C=4, schmoo=none, 0x0?

                                      I realized that all of the core frequencies have a great effect on the sdram stability.
                                      Where gpu over 500 was too much, I set it to default 300, and have not had any problems.

                                      I think the sdram controller doesn't work right at more than over voltage 4. Could use some more testing.

                                      With
                                      gpu_freq=300
                                      core_freq=600
                                      sdram_freq=650
                                      over_voltage_sdram_p=8
                                      over_voltage_sdram_i=6
                                      over_voltage_sdram_c=4

                                      So far passed memtester (100M x 3) (20M x 10), need to try more between boots.

                                      As a side note, 300GPU didn't seem to effect n64 noticeably.

                                      However switch to an x2 interlaced resolution did improve the 3d stuttering and lag by quite a lot. It didn't fix the sound stuttering during some loadscreens etc. though. nevermind, that doesn't make sense, it must have been my vm settings or some fluke.

                                      1 Reply Last reply Reply Quote 0
                                      • EfriimE
                                        Efriim
                                        last edited by Efriim

                                        I apologize for the quintuple post.

                                        I discovered last week that it is possible to dial in a specific voltage, by entering the number in micro volts to the config. For example using 31250 (1 step and 6250uV) will give you voltage 1.2313V +AVS. The only exception to this is the sdram_physical which appears to only go by step and refuses to be set to 1.2000V with sdram_min. However if you entered exactly between the steps; 37500 (1 step and 12500(1/2step)) and 37501(1.5steps+1uV); the sdram voltage will read 1.2250V and 1.2500V respectively. Suggesting it is taking some consideration in the rounding or reading.

                                        sdram_freq=667 over_voltage_sdram_(p=7)(i=7)(c=4)
                                        It passed a number of single-threaded tests, multi threaded tasks were a failure and especially with a high arm_freq. As for its usability I'd call it unreliable and not recommended until a different configuration is explored.

                                        quicksilverQ 1 Reply Last reply Reply Quote 0
                                        • quicksilverQ
                                          quicksilver @Efriim
                                          last edited by quicksilver

                                          @Efriim I haven't been on my pi since yesterday so haven't really been able to check yet but since I'm getting crashing at stock speeds I'm thinking my issue is not related to my overclock. If it crashes again I'm hoping the ES system log will note something.

                                          With recent firmware (within the last year or so?) schmoo=0x02000020 is set automatically if your sdram is overclocked to 500mhz or greater.

                                          Edit: so ES just crashed again. I don't see anything out of the ordinary in the log unfortunately. Not sure what to do next.

                                          EfriimE 1 Reply Last reply Reply Quote 0
                                          • EfriimE
                                            Efriim @quicksilver
                                            last edited by Efriim

                                            @quicksilver
                                            Did you uninstall the Carbon Default Theme? I did and I seem to remember it crashing because of that a long time ago, usually right after I update and it checks the resources there for some reason.
                                            Or it could be the OMX player or a video or another resource, try reinstalling your theme.
                                            I don't know what caused my ES crash either.

                                            I tested with the schmoo value on again, the kernel memory crashes on the first 100M run, it lets you know pretty early on. It won't crash without schmoo, but maybe I should find a different memory test app.
                                            Maybe it is auto-configured, yet not necessarily 0x02000020
                                            Maybe that it is not working with 0x02000020 is a good sign that it is bad configuration.

                                            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.