Input Lag Analysis on RetroPie

[thelostsoul]

Author: thelostsoul (Tuncay D.)
Date: 2019-01-07
License: Free to download and share without editing
Source: Input Lag Analysis on RetroPie.pdf

For now, the whole article is only available for download. If everything is correct, I may reconsider to add its content at this place. The document is just 8 page "long". It is about my personal setup, so no universal application here. The content talks about what I measure, how I did, what settings are used and shows the results. It includes some screenshots and even links to 240 fps video footages. Multiple games and systems are tested, in hope to find the latency values for my RetroPie build. If something is wrong, please let me know. Tell me what you think. Here is some example content:

Test 1: Game and emulator lag
NES Mega Man 2 (U): 40 ms latency

Test 2: Overall real time lag
NES Mega Man 2 (U): 63.4 ms latency

Conclusion

So, this was a little adventure. At the end of day, I am a lot surprised. Some results
are not consistent and others look unbelievable. My hope for a clear answer just dis-
appeared. In example, the lag with King of Fighters ‘98 in Test 1 sounds a
bit too high for my taste. The outcome of Super Mario World at Test 2
looks suspicious too. Super Metroid, Sonic and Donkey Kong share at
least one thing in common: Their difference between Test 1 to Test 2 are
around 33 to 36 milliseconds. I consider this value as the added latency of
my input and output devices.

What can I take from this? The total latency on my setup is approximately 70 to 100
milliseconds (4 to 6 frames) for most games, if everything is taken into account and is
correctly done. That sounds and feels acceptable to me.

[A Former User]

Would be interesting to see a similar test done on a Pi connected to a CRT, either using the composite out, or Pi2Scart. I noticed far less lag going from originally a 1080p LCD TV, to my Trinitron CRT. I also swear the lag has also slightly decreased going from my USB Hori Rap V4, to the Scorpion Arcade Stick. The Hori was seen as a USB stick, while the Scorpion is seen as a keyboard controller. I wonder if the keyboard controller has less lag ? It feels like it does - tested on Super Mario 2 NES.

[thelostsoul]

@John_RM_70
I actually use a CRT pc monitor (60 Hz), but it is connected with HDMI to VGA converter. The fightstick I have can operate in different modes, forgot to mention that, it was set to PC mode. Available modes are Xinput, PS3/Dinput and default game mode, which is essentially PC and Android mode. I have an old CRT here, but it is 50 Hz only (I live in the EU, which is 50 Hz for CRTs tvs) and I am not sure if the cable I have is correct. So, I'll pass this anyway. I am also interested in how to count the frames correctly. Do I have to add up the last frame (when the animation starts) into the count? Like this:

Counter=0.
(Pause the emulation.)
Frame 010: Push jump button and the LED goes on.
(Click to process frame via Frameadvance.)
Frame 011: Nothing happens.
(Add 1 to counter.)
(Click to process frame via Frameadvance.)
Frame 012: Nothing happens.
(Add 1 to counter.)
(Click to process frame via Frameadvance.)
Frame 013: Start of a jump animation.
(Don't add anything to counter. Stop now.)

So after this logic, I would have counted 2 frames of delay. Is that correct?

[thelostsoul]

Edit: Ah, just forget this. I tried it with Snes9x 1.54.1 on SMW and it slows down even if Runahead is set to 1, regardless of second instance. Same with Nestopia 1.49 on Mega Man 2. I think, this will not gonna work on the Pi.

Small comparison with Brunnis from libreto.com. He uses Windows and have a beefy pc and highly optimized settings.

1. https://forums.libretro.com/t/an-input-lag-investigation/4407/100
   The emulator lag he gets with lr-snes9x on Yoshi's Island is 4 frames and with his fix 3 frames. I did not test it, but on Super Mario World I get around 3 frames too. Doing a full real time test on same emulator, he gets 6 frames and I got 7.2 frames. Not too bad.
2. https://forums.libretro.com/t/an-input-lag-investigation/4407/169
   In Nestopia on Mega Man 2 he has 4.3 frames and optimized he gets 3.4 frames on a full real time test. On a real NES hardware he gets 2.2 or 1.2 frames (didn't understand). I get 3.8 frames, very close to his Nestopia. Quite good.

Overall impressive results from this little device. While I don't know if all other games and systems are good as these results, I am still satisfied.

---

I am reading threads here and there and consider to enable Runahead at 1 frame on 8 and 16 bit systems. I am confused about the second instance thing. Do you guys use it on Raspberry Pi? And if yes, which systems and what settings? What is the current state? I have an overclocked Pi 3B, which should roughly the same performance as 3B+. Would it be safe at 1 frame Runahead, if 60 fps is maintained all the time or are there any side effects? Or is it something I only should enable for specific games?
Btw, I will not do the same test again, as I changed everything back to normal; so no comparison.

[Brunnis]

I'm sorry to say, but your results appear all over the place and are quite different compared to mine. A few notes:

First of all, it's very curious that you get such varying results when doing the frame advance tests. I have personally never found the input lag to vary during the same game/scene when using this method. However, it can vary depending on which action you perform (jumping, shooting, etc.), due to how the particular game is coded.

Second, the real time tests contain some strange results. For example, real time input lag in Mega Man 2 and Battletoads is just marginally worse (0.4-0.8 frames) than when frame advancing. That looks too good. Also, if the test method was reliable, Metroid would be 1 frame faster than SMW, but in your results it's 3 frames faster.

You should count the first frame when you see animation as well. So you need to add one frame to your real time measurements to get accurate results. I guess this is why your NES results look too good.

Also, my experience is that you should take ~25 samples to get stable averages.

Here's the most recent test I've done with Raspberry Pi 3 with RetroPie 4.3: https://forums.libretro.com/t/an-input-lag-investigation/4407/583

Please note that the results in the graph in that post include the TV's internal lag, which is ~1 frame. So you need to subtract one frame from those results to get the input lag of the systems excluding the display lag (the scan-out time is still included).

As you can see, on the high performance PC, RetroArch is at 3.6 frames average in Super Mario World and would be at 2.6 frames average in Mega Man 2 (given the same vertical placement of the character as in SMW), since Mega Man 2 has exactly one frame lower built-in lag.

[thelostsoul]

@Brunnis Hello Brunnis, I am glad you had a quick look at my results. I have high respect for your work.

I know something must went wrong on my test, as the outcome wasn't consistent and I didn't know the actual delay for input and output devices or even used wrong emulator settings. I expected some sort of delay and just wanted to know how my personal setup works. Currently, there the only way to play on CRT for me is to use that converter.

Quick test of GAMEPAD and CONVERTER

I did a quick test on my USB Fightstick on my PC without RetroPie.

Test 1 does not involve any display. It was just to see how long the LED light on the stick needs to turn on after pressing a button. This is hard to tell, as I can't say for 100% sure when the actual press of button sends a signal. At least the converter, monitor and usb aren't involved here.
Result: 1 or 2 frames of 240 fps, which translates to 0.25 to 0.5 frames at 60 fps (right?).

For Test 2 I used my daily Linux PC with 144 Hz HDMI monitor (without converter). jstest-gtk on Ubuntu was used to visualize a press button on display.
Result: I think 4 frames of 240 fps footage in addition after the LED is lighting up. That translates to 1 frame delay at 60 fps.

At Test 3 I connected same PC to the CRT PC monitor via HDMI to VGA converter. Same jstest-gtk was used as previous test.
Result: 6 or 7 frames at 240 fps footage after the LED is lighting up. Which translates to about 1.5 or 1.75 frames at 60 fps.

Conclusion:

• The arcade stick seems to add 1 or 1.5 frame delay on its own, which would mean 16.7ms or 25ms.
• If Test 2 and 3 are compared, the converter seems to add 1.5 or 1.75 frame delay on its own, which would mean 25ms or 29.2 ms.
• So, both together are in total adding up approx. about 3 frames or 50 ms latency.

Do you think the autofire/turbo-2 function of arcade stick could send too many key press events, so the emulator or driver gets too busy? Could this have an effect? What do you think about all of this? Does these sound reasonable?

And, should I also just copy the posting to Reddit?