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

    Input Lag guide

    Scheduled Pinned Locked Moved Ideas and Development
    input lagwikidocumentationdocs
    56 Posts 19 Posters 24.8k 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
      last edited by

      Good job, @dankcushions !

      I mostly agree with what you wrote. The "dangerous tweaks" should really not be applied without fully understanding what you're doing and I'm guessing most people don't.

      Personally, I kind of regret that I've never tested the actual effect on input lag from enabling video_threaded. I've always had it set to false and haven't seen it cause any negative side effects at all, but that's probably because I just run NES/SNES which is fairly simple to emulate.

      In the end, I decided to move on from the Raspberry Pi due to the low performance preventing the use of the settings you list. I'm now running a Pentium J4205 system with RetroArch under Ubuntu using DRM/KMS mode. To start with, the Intel video driver has 1 frame lower input lag than the Pi's OpenGL driver, therefore matching the Dispmanx driver. On top of that, the Pentium can handle video_max_swapchain_images = 2 and video_frame_delay = 8. All in all, I've measured a reduction in input lag of 33%, or ~2.5 frames/42 ms. That's for my very specific use case, though (NES/SNES). For more demanding emulation, I'd have to relax the settings.

      dankcushionsD 1 Reply Last reply Reply Quote 0
      • dankcushionsD
        dankcushions Global Moderator @Brunnis
        last edited by

        @brunnis said in Input Lag guide:

        Good job, @dankcushions !

        I mostly agree with what you wrote. The "dangerous tweaks" should really not be applied without fully understanding what you're doing and I'm guessing most people don't.

        Personally, I kind of regret that I've never tested the actual effect on input lag from enabling video_threaded. I've always had it set to false and haven't seen it cause any negative side effects at all, but that's probably because I just run NES/SNES which is fairly simple to emulate.

        yeah i think it's one of those settings that is 'free' until it's not. so much of retropie is pushing close to 100% of one core even on a pi3.

        i'd really like to get an automated performance testing suite set-up for retropie (i think it would be possible because you get avg framerates outputted via console logs), so I can get some real data on this. i think a lot of these things could be ok IF you enabled them for only pi 3 (or maybe 2) and only for certain emulators. i think this would be scriptable.

        at the same time, we'd need some conclusive input lag testing as to which setting(s) give the best input lag improvement, as to which ones we should prioritize.

        In the end, I decided to move on from the Raspberry Pi due to the low performance preventing the use of the settings you list. I'm now running a Pentium J4205 system with RetroArch under Ubuntu using DRM/KMS mode. To start with, the Intel video driver has 1 frame lower input lag than the Pi's OpenGL driver, therefore matching the Dispmanx driver. On top of that, the Pentium can handle video_max_swapchain_images = 2 and video_frame_delay = 8. All in all, I've measured a reduction in input lag of 33%, or ~2.5 frames/42 ms. That's for my very specific use case, though (NES/SNES). For more demanding emulation, I'd have to relax the settings.

        yep, that's fair! after we move to raspbian stretch we can use the drm driver which i'm hoping gives a boost. right now dispmanx has too many limitations.

        1 Reply Last reply Reply Quote 1
        • RionR
          Rion @dankcushions
          last edited by Rion

          @dankcushions said in Input Lag guide:

          thanks!

          @sirhenrythe5th said in Input Lag guide:

          Personelly i would recommend using a CRT.
          No tweaks, parameters or tools gave me this experience, totally awesome.

          I am not 100% sure on CRT - I realise CRTs themselves have no 'post processing', but I believe digital-to-analogue conversion between pi and composite output adds some latency(?). I also heard that doing it via the GPIO might be quicker(?) - eg http://www.rgb-pi.com/.

          As far as I know there should be no input lag when using the GPIO. Rgb-pi is not the best product out there so I would highly recommend RetroThink over Rgb-pi or pi2scart.

          @mikechi2 could explain this better for you.

          Ps I would also recommend to read @Brunnis thread over at the Libretro forums. An input lag investigation

          FBNeo rom filtering
          Mame2003 Arcade Bezels
          Fba Arcade Bezels
          Fba NeoGeo Bezels

          1 Reply Last reply Reply Quote 0
          • CapemanC
            Capeman
            last edited by Capeman

            @dankcushions You wrote DISPMANX as a do-not-use, but if it cuts lag with only the side effects you listed, this actually sounds like a good option for one of my boxes that only runs console games with no rotation, always turn off the OSD and never uses shaders.

            Can you offer any insight as to any other side effects, because from what you wrote, i feel like i want to turn this on, haha!

            Vector Artist, Designer and Maker of Stuff: Laser Cut Atari / Pixel Theme Bartop

            1 Reply Last reply Reply Quote 0
            • pjftP
              pjft @dankcushions
              last edited by

              @dankcushions thanks for putting this together. A few weeks ago there was a thread about improving Bluetooth controller lag, which included disabling wifi and potentially making it slave rather than master.

              I tried it out and the ping results for the Bluetooth connection certainly improved. Unsure if that's something you'd want to include, but wanted to mention it.

              Here it is in case you'd want to use any of it:

              https://retropie.org.uk/forum/topic/7712/fixing-dualshock-3-bluetooth-lag/27

              Thanks for documenting this.

              1 Reply Last reply Reply Quote 0
              • mediamogulM
                mediamogul Global Moderator @dankcushions
                last edited by mediamogul

                @dankcushions said in Input Lag guide:

                it's possible that you can enable some or even all of these tweaks for certain emulators/games and have no adverse effects. my problem with them is that retropie on a raspberry pi 3 has very little headroom.

                I reworked the wiki entry to reflect this and added a real world use case of NES-specific titles with a solution that shouldn't affect performance. I also changed 'Dangerous Tweaks' to 'Cautionary Tweaks' to prevent users from potentially mistaking the warning for something that might irreparably damage their setup. Finally, I added a graph that reflects the potential benefits of the settings when applicable. I was mindful as I went along to add that these settings are always conditional.

                RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                dankcushionsD 1 Reply Last reply Reply Quote 1
                • dankcushionsD
                  dankcushions Global Moderator @mediamogul
                  last edited by

                  @mediamogul said in Input Lag guide:

                  @dankcushions said in Input Lag guide:

                  it's possible that you can enable some or even all of these tweaks for certain emulators/games and have no adverse effects. my problem with them is that retropie on a raspberry pi 3 has very little headroom.

                  I reworked the wiki entry to reflect this and added a real world use case of NES-specific titles with a solution that shouldn't affect performance. I also changed 'Dangerous Tweaks' to 'Cautionary Tweaks' to prevent users from potentially mistaking the warning for something that might irreparably damage their setup. Finally, I added a graph that reflects the potential benefits of the settings when applicable. I was mindful as I went along to add that these settings are always conditional.

                  i don't like 'cautionary tweaks' as it now implies that we endorse them, even tacitly. that is the opposite of my intention in documenting them. i don't think anyone should use these tweaks under any circumstances. if they do use them, they are now using their own version of retropie and should ask themselves for help from now on :)

                  for example, those settings will get you lost frames when you use even the light crt-pi, etc shaders we suggest elsewhere in the wiki. likely same with overlays. what about with bluetooth, or wifi, or anything else that puts (slight) added load to the CPU/bus?

                  this is the kind of thing i wouldn't feel confident endorsing without a full test using a benchmarking suite: https://github.com/dankcushions/retropie-auto-testing (which i must finish... someday!).

                  mediamogulM 1 Reply Last reply Reply Quote 0
                  • mediamogulM
                    mediamogul Global Moderator @dankcushions
                    last edited by mediamogul

                    @dankcushions said in Input Lag guide:

                    i don't like 'cautionary tweaks' as it now implies that we endorse them, even tacitly. that is the opposite of my intention in documenting them. i don't think anyone should use these tweaks under any circumstances. if they do use them, they are now using their own version of retropie and should ask themselves for help from now on :)

                    Maybe I'm underestimating the situation, but surely these settings don't qualify as being particularly dangerous do they? I mean, they're not really anywhere near the level of caution that should be observed from an overclock and we support those users who have chosen to do so. Granted, if they come here with troubles related to overclocking we should always recommend they be adjusted, or abandoned outright, but I've never seen it as being grounds to prohibit support altogether.

                    for example, those settings will get you lost frames when you use even the light crt-pi, etc shaders we suggest elsewhere in the wiki.

                    I had first posted about Brunnis' initial findings regarding limited shader impact, but missed where he has since rethought the issue. Still, with dispmax enabled, shaders aren't going to be an issue, as they aren't supported with that particular driver. Also, the worst that can happen if performance is affected by shaders is that the user has to make a decision whether input lag, or visual presentation is more important to them. Personally, I prefer to prioritize how a game plays, but each user is going to be different. Allowing a choice here would seem ideal.

                    what about with bluetooth, or wifi, or anything else that puts (slight) added load to the CPU/bus?

                    I make use of both and have been actively testing the NES-specific settings I posted on the wiki for several months and I've never dipped below 60fps on a Pi 3.

                    RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                    dankcushionsD 1 Reply Last reply Reply Quote 0
                    • dankcushionsD
                      dankcushions Global Moderator @mediamogul
                      last edited by

                      @mediamogul said in Input Lag guide:

                      @dankcushions said in Input Lag guide:

                      i don't like 'cautionary tweaks' as it now implies that we endorse them, even tacitly. that is the opposite of my intention in documenting them. i don't think anyone should use these tweaks under any circumstances. if they do use them, they are now using their own version of retropie and should ask themselves for help from now on :)

                      Maybe I'm underestimating the situation, but surely these settings don't qualify as being particularly dangerous do they? I mean, they're not really anywhere near the level of caution that should be observed from an overclock and we support those users who have chosen to do so.

                      perhaps “dangerous” is the wrong word. a moderate overclock can provide a totally safe global benefit (typically invisible but anyway). even an extreme/unsafe overclock cannot damage your system (pi will downclock, etc) so is not “dangerous”.

                      none of these tweaks can give a wholesale global benefit - they all have a performance cost which will cause a subset of games to drop frames.

                      i don’t know of a better way of heading that section.

                      Granted, if they come here with troubles related to overclocking we should always recommend they be adjusted, or abandoned outright, but I've never seen it as being grounds to prohibit support altogether.

                      i guess i have been doing the support dance for a while now and i find overclocking and input tweaks to be the most tedious to support. they are blindly added and presumed safe, so hard to diagnose. i really like having a link i can just paste in that broadly says “here’s why you messed up”. i think now the link says “here, let us help you mess up” :)

                      for example, those settings will get you lost frames when you use even the light crt-pi, etc shaders we suggest elsewhere in the wiki.

                      I had first posted about Brunnis' initial findings regarding limited shader impact, but missed where he has since rethought the issue. Still, with dispmax enabled, shaders aren't going to be an issue, as they aren't supported with that particular driver. Also, the worst that can happen if performance is affected by shaders is that the user has to make a decision whether input lag, or visual presentation is more important to them. Personally, I prefer to prioritize how authentically a game plays, but each user is going to be different. Allowing a choice here would seem ideal.

                      i don’t think the typical user will connect the dots. same with overclocking. our wiki pages on overclocking/n64 tweaks are a weapon as far as i’m concerned. the benefit is approaching zero, yet the crashing threads are legion.

                      what about with bluetooth, or wifi, or anything else that puts (slight) added load to the CPU/bus?

                      I make use of both and have been actively testing the NES-specific settings I posted on the wiki for several months and I've never dipped below 60fps.

                      are you sure? because it can be subtle. the clouds during motion in mario is a good test. i need to get the benchmarking suite done...

                      if we’re confident that the settings are safe for pi3 + nes, then they should be defaulted for pi3 + nes (not dispmanx), right? we all run the same hardware.

                      mediamogulM 1 Reply Last reply Reply Quote 0
                      • mediamogulM
                        mediamogul Global Moderator @dankcushions
                        last edited by

                        @dankcushions

                        You make strong points and beyond anything else, you're the original author of the article. I was hoping that by reworking it, we might open up a few advantages to those extra difficult games that need tighter input timing, but it may very well be that no matter how it's worded, users will apply them without care. I certainly don't want to make support any more difficult and I completely understand that it might. I'm about to sit down to eat, but I'll look into reverting the changes later this evening.

                        RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                        1 Reply Last reply Reply Quote 0
                        • DarksaviorD
                          Darksavior
                          last edited by Darksavior

                          Maybe change it to unsupported tweaks or have the word "unsupported" mentioned in there.

                          dankcushionsD J 2 Replies Last reply Reply Quote 0
                          • herb_fargusH
                            herb_fargus administrators
                            last edited by

                            I think generally over clock/input lag are "advanced user" stuff. That's kinda why I put them in that section(or thought i did) in the wiki. Fact is people are trying to use an underpowered device to do things it's not really meant to do and then wonder why it sploded. I'm personally fine with a giant disclaimer on both pages saying : UNSTABLE: ADVANCED USERS ONLY! then in fine print: if you break it don't come the forum- just reimage and stop while you're ahead ;)

                            If you read the documentation it will answer 99% of your questions: https://retropie.org.uk/docs/

                            Also if you want a solution to your problems read this first: https://retropie.org.uk/forum/topic/3/read-this-first

                            mediamogulM 1 Reply Last reply Reply Quote 0
                            • mediamogulM
                              mediamogul Global Moderator @herb_fargus
                              last edited by mediamogul

                              @herb_fargus said in Input Lag guide:

                              I'm personally fine with a giant disclaimer on both pages saying : UNSTABLE: ADVANCED USERS ONLY!

                              I'm fine with disclaimers as well, but shouldn't they read as being 'potentially unstable', given that they're also potentially stable under the right circumstances? Something akin to @Darksavior's suggestion of labeling the tweaks as simply being unsupported would remain neutral to the potential outcome, no matter what.

                              RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                              lilbudL 1 Reply Last reply Reply Quote 0
                              • lilbudL
                                lilbud @mediamogul
                                last edited by

                                @mediamogul I personally think the potentially unstable tweaks shouldn't even be on the page in the first place. Because Gods perfect idiot will come along, screw up their build using settings from the do not use section, then come to the forum kicking and screaming about how their build is screwed.

                                But, ya know, just my silly personal opinion.

                                Creator of the Radiocade: https://retropie.org.uk/forum/topic/6077/radiocade

                                Backlog: http://backloggery.com/lilbud

                                mediamogulM 1 Reply Last reply Reply Quote 0
                                • mediamogulM
                                  mediamogul Global Moderator @lilbud
                                  last edited by mediamogul

                                  @lilbud

                                  That is one way to go. I mean, there are a few suggestions for reducing input lag listed above that are guaranteed not to cause trouble. Although games like 'Battletoads' and 'Mike Tyson's Punch-Out!!' become considerably easier with the adjustments, I'm fairly confident both games could be beaten without them given some extra practice and memorization. In fact, outside of those two examples and perhaps a few more, there's really no other situations where this is even an issue.

                                  RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                                  1 Reply Last reply Reply Quote 0
                                  • markwkiddM
                                    markwkidd
                                    last edited by

                                    Have you all been tracking the new run-ahead lag reducer function for libretro/RetroArch cores that just debuted around the beginning of the month?

                                    My understanding is that it should be able to shave a frame or two off of the lag for older console emulators even with low-power architectures like rpi.

                                    mediamogulM dankcushionsD 2 Replies Last reply Reply Quote 1
                                    • mediamogulM
                                      mediamogul Global Moderator @markwkidd
                                      last edited by

                                      @markwkidd said in Input Lag guide:

                                      Have you all been tracking the new run-ahead lag reducer function

                                      I have to say I have not, but it sounds like the cat's pajamas. I take it that this is it in action?

                                      RetroPie v4.5 • RPi3 Model B • 5.1V 2.5A PSU • 16GB SanDisk microSD • 512GB External Drive

                                      1 Reply Last reply Reply Quote 0
                                      • markwkiddM
                                        markwkidd
                                        last edited by

                                        That's the very one!

                                        caver01C 1 Reply Last reply Reply Quote 0
                                        • caver01C
                                          caver01 @markwkidd
                                          last edited by

                                          @markwkidd And this wasn't an April Fool's joke?

                                          My 4-player cocktail style cabinet built as a custom "roadcase"

                                          markwkiddM 1 Reply Last reply Reply Quote 0
                                          • markwkiddM
                                            markwkidd @caver01
                                            last edited by markwkidd

                                            @caver01 said in Input Lag guide:

                                            @markwkidd And this wasn't an April Fool's joke?

                                            nope, it's real. this functionality is IMO a landmark in emulation but it happened so recently that history hasn't quite noticed yet

                                            there has been quite a bit of testing. there are likely some bugs still to be found but I think things are reasonably proven in terms of the major classic consoles and the higher performance libretro emulators for NES/Famicom, Genesis/Megadrive, SNES/Super Famicom

                                            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.