Yeah but it makes no difference. At least on the core/my system.
You probably have the equivalent of that playing with the “frame delay” value.
But that’s still really stressful on the cpu anyway.
Does enabling rewind increase the input lag?
Enabling rewind adds a savestate to every frame, which increases processing time by a very small amount. Saving state is usually far less work than emulating a frame.
It’s so insignificant that it only matters for people who are using the Frame Delay feature, and might need to turn that down a notch.
Processing time as in additional input lag or additional cpu usage? I’m aware that it increases the cpu requirements for a core but didn’t know if it increased input latency.
Rewind does have a significant performance hit though. It may depend on how the savestate code is implemented in each core I guess.
If you’re using frame delay, at worst, rewind is going to cost you a couple of milliseconds for most cores (i.e., you might only get up to frame delay 8 instead of 10 or whatever). So, that’s a couple more milliseconds of latency. If you’re not using frame delay, there won’t be any increase at all.
How does it impact run ahead?
It shouldn’t have any effect at all, as both rewind and runahead require taking states on each frame.
Does using either gsync or freesync decrease input lag? I know that in traditional pc games, using either helps to eliminate most of regular vsync lag.
edit: Wow, using scan line sync from RTSS with SSF brings the input lag below beetle saturn + vulkan. Also am not noticing any tearing or stuttering. Hopefully retroarch can get that some day.
1 Like
Hello Brunis, thank you for all your work on input lag, it is very thorough. Do you own any arcade/fight sticks that you could possibly do any input lag testing on? Really interested to know how the 8bitdo N30 arcade stick stacks up to other sticks like Qanba, Hori, Brooks, etc.
Sorry, I only own a bunch of gamepads, no arcade controls.
This guy on Facebook solved it,maybe you can use his “data” instead?
“Anthony Ball lol. Maximum input lag on a 60hz SNES games is 16ms. Your game is displayed and on the next vblank you process the previous grab from the controller. So if you run at 60hz then the delay from gab to processing is less than 1/60 sec. 1/60 sec is 16ms. I don’t remember any games on the SNES that didn’t run at 60hz.”
LOL indeed… 
Killer work man! I actually suspected the exact same thing about retroarch just needing to use one frame of run ahead to match console. I wonder do you think if you use 15 Frame delay, rather than run-ahead, it would match console?
Thanks! And, yes, given low latency controllers and otherwise well-behaving system/drivers/emulators, the settings I’ve listed in previous tests combined with a Frame Delay setting of 15 will get very close (as in indistinguishable) to the actual consoles. In absolute terms, this should get you within 5 ms, not counting any input lag caused by the display.
Here’s a pretty major input lag issue with the snes9x2002 core that I don’t think has been discussed previously:
I have never run any tests on snes9x2002 previously, since I haven’t used slow enough hardware to need the core. Now that I’ve started looking into a project where I will need it, I decided to run a few tests and it’s not looking good. See the linked issue for the details.
This will pretty much affect anyone running SNES on a Pi/Pi Zero.
Would be awesome if someone feels motivated to look into it. I really, really shouldn’t, due to far too much other stuff going on at the moment.
1 Like
Awesome! That was quick! 
EDIT: By the way, I think the input lag added by this polling issue you fixed is between zero and one frame, varying depending on the individual frame processing times. For frames that are completed quickly, there will be a longer wait for the next frame and the sampled input will be more stale.
Just curious, did you ever had a chance to glance over the mame libretro input lag issue?
I’m not after a solution, but would be interested in your opinion on the matter. There’s definitely something not right with the input response.
I’m mostly wondering whether the issue could not so much be a wrong moment of input polling, but something very different causing the issue (timer / throttle related or something.)
Is there any chance you could find some time to look into this matter?
(No is a valid answer for sure, I know about the amount of time you spent on the BSNES issue in the past. Still appreciating that find to this day 
)