chaos Posted July 27, 2020 Report Share Posted July 27, 2020 There are 2 major forms of latency (or lag, whichever you'd like to call it): Input Latency - The delay from pressing a button, to the display of that button action on the screen. Network Latency - The delay in communication from one computer to another. In our case, the amount of time it takes to for one player's button press to show up on the other player's screen. Latency is usually displayed in ms (milliseconds). An emulator displays video by frames. Most emulators use an ~60Hz refresh rate (similar to the consoles they emulate), which means it displays 60 video frames per second. The video on the screen refreshes every 16.7ms (1 second / 60 frames = 16.7ms). So, the fastest an emulator can show a change on the screen is 16.7ms. This may seem like very little time, but in regards to computer processing, this is a ton of time. A lot of things happen within those 16.7ms, one of which is preparing for the next video frame. Input Latency The emulator checks for controller input during a specific time during a frame. If the input arrives before that time, it will update the video on the screen. How soon you see a reaction to your input is called the input latency. Many things can factor into this: Controller - Your USB/Bluetooth/wireless controller polls the button inputs every couple of ms. Some poll quicker than others (2-4 ms), some take longer than others (11-16ms). This contributes to input lag. On top of that, the PC will poll the controller, which also contributes to input lag (though this is usually 1-2 ms). So, when you press the button, the controller polls the buttons to see what was pressed, and then the PC polls the controller to get the input. This is not instant. Emulator - Depending on how well the emulator is coded, some of them can contribute to input lag. It can receive the input from the PC, but it may take a frame or 2 before it updates the video to show the input. Display - Depending on your monitor or TV, there could be a delay added. HDTVs especially, since there is some upscaling of the video involved in order to display it (this can add a few frames). Computer monitors are usually lag-free. Regardless of all the latency added above, the emulator still checks for input every 16.7ms. So if you press the button, if it gets to the emulator in time, it will display it. The problem is this: It only checks every 16.7ms. So, if you press the button mid-frame (8ms), and your input latency adds up to 10ms, the total is 18ms (10ms latency, 8ms to press the button), and you will miss the frame. Your input has to wait for the next frame to show up. The best way to think of the above is this way: Imagine you need to get on the bus. A bus comes by every 16.7ms to pick people up. It takes 10ms for you to get to the bus stop from your house (your latency). Depending on the time you leave your house (press a button), will depend on what bus (frame) you make. If you are curious as to the input lag of your controller (the first part of above), you can look it up on the internet. A lot of people have done tests of controllers. For example, the wired retro-bit controllers come in around 10ms, where as a wired 8bitdo M30 2.4g has about 3-4ms. Network Latency Network latency is the amount of time it takes for communication between 2 PCs. This comes into effect during Netplay, when 2 PCs are sending inputs back and forth. Latency increases with distance (the further the signal has to travel, the more latency there most likely will be), but there are many other factors that can cause latency: Wifi - A wireless signal from a PC to a router can be affected by many things. Walls, interference from microwaves (microwaves use the same frequency as most Wifi routers), interference from wireless landline phones (same frequency), distance from PC to router, devices on Wifi, etc. You can have the fastest internet and Wifi router in the world, but it will not make a difference. Wifi adds lag, and since it isn't consistent lag, it makes it even worse. Jitter - Your internet speed is not important when it comes to gaming. You can have 1GBit download and upload speeds, but what matters most is jitter, or stability. Input lag is usually consistent, in other words, stable. Your eye can easily adjust to it after a minute or so. Network jitter causes instability, where the network lag constantly changes. There are many things that can cause this, though most are out of your hands. You can check your network jitter using online tests such as speedtest.net. Note, this will change (you will get different results every time you run it), but the goal is to have jitter that is less than 8ms or so. One of the only ways you can control jitter is by using a wired connection for internet, between your PC and router. Other than that, you are at the mercy of your Internet Service Provider (ISP). Local Network Load - This is a problem again you may have some control over. The amount of devices using internet on your local network can cause a load on the router, where the router has to decide what devices to let through at a given time. Sometimes, your PC will be at the top of the list, sometimes on the bottom. The router decides what is most important. Sometimes, some routers have settings that give priority to gaming. Usually, this isn't much of a problem, but it could be. ISP Network Load - You have no control over this. This depends on how many people are using the internet at a given time. In a case when a pandemic is going on, internet usage goes up, causes a network load, and everything slows down. Peak times (after work hours) will also cause issues with network traffic. Some people just have crappy internet service providers, and it might be their only option. In these cases, you just have to limit what you can. Again, speed doesn't matter, this game could be played using a 1200 baud modem no problems. The amount of data passed between PCs is just inputs, and occasionally save states. The most important thing is stability. If the Network Latency is constant, it can be dealt with easier than if it is constantly changing. Both Input Latency and Network Latency are added together when it comes to Netplay. So if we use our bus analogy: Imagine you need to get on the bus. A bus comes by every 16.7ms to pick people up. It takes 10ms for you to get to the bus stop from your house (your input latency). But now, there's traffic along the way (your network latency). Depending on the time you leave your house (press a button), and depending on how bad the traffic is at that time (network latency), will determine what bus you get on (what frame). RetroArch Netplay Like I said above, your Input Latency (which is local to you) and Network Latency (between you and your opponent) affect your Netplay experience. RetroArch netplay, the way it works in a nutshell, is it checks frame by frame to see if it receives an input from the opponent. It also keeps track of what frame you and your opponent are on, and compares. When you connect to each other, it starts frame counting. So, when you press the B button on Frame 123, it sends that information to your opponent. When your opponent is on Frame 123, it receives your B button press, and shows it on the screen on the next frame (124), just when it would show on yours as well. In a perfect world, every button press on a frame would be registered on the same frame for your opponent, without problems. But, what happens when you press your B button and it's showing your pass on Frame 123, but it doesn't get to your opponent until Frame 125? This is the effect of latency. What RA does in this case, is rewind to Frame 123, show your B button press, and continue. Now in this case, there is 2 frames of lag (which is ~33ms). The rewind may go unnoticed in this case. But, lets say the frame difference was 10 frames. That's 166.7ms. That may be noticeable to the player. In this case, what they see is a skip, or "rubber-banding" where the skaters rewind back 10 frames, then continue. (Note: more goes on than just rewind, just keeping it simple here) The short frame rewinds make it seem like input lag. Many players complaining about input lag are probably experiencing this. The larger frame rewinds are more noticeable and look like skips. In other emulators, what would happen in this case, is the game would stutter and hang until one side caught up to the other. If the frame difference was large, the game would de-sync. Input Latency Frames and Run-Ahead RetroArch can deal with latency in 2 ways - Input Latency Frames (used to help with network latency) and Run-Ahead (used to help with input latency). Remember, Netplay expect the input from each player to arrive on the same frame. This is unrealistic. In some cases, when people playing against each other are very close geographically, this is possible (as long as all latency equals to less than a frame - 16.7ms, this works). In cases when playing across North America, expect network latency to be in the 20-80ms range. Adding Input Latency Frames allows some time for Netplay to expect the input. If we add 2 Input Latency Frames, for example, when we press B on Frame 123, it sends the press on Frame 123, but delays showing it until Frame 126 (pressed on 123, would originally show on 124. 124 +2 frames = 126). This way, the opponent's PC can wait for the input on Frame 125, showing it on 126, giving it 3 frames total of travel (Frame 123, 124, 125). Gens Kaillera Netplay and ZSNES both add 2 input latency frames automatically. Gens adjusts by adding more if needed (depends on ping). By default, Input Latency Frames is set to 0 in RA. Run-Ahead works locally, by removing input latency frames. By turning Run-Ahead on, you remove at least 1 frame of input latency (you can set it higher if you'd like). It's one of best features of RA. By default, it's turned off. TL;DR: So how can we use these to help improve Netplay experience? We can add Input Latency Frames, and remove some of them locally using Run-Ahead, to give us a near lag-free (in most cases) experience. Example: If we set Input Latency Frames to 2, and set Run-Ahead to 1, we essentially add 1 frame of input latency locally (2 input frames - 1 run-ahead frame = 1 total). This gives the network 2 frames to play with as far as receiving data, but we only see a difference of 1 frame while playing. This is not noticeable. Even 2 frames is hard to notice. NOTE: Adding Run-Ahead frames becomes CPU intensive. You can experiment with it, but 1 or 2 frames should be more than enough. NOTE: When it comes to adding Input Latency Frames, both players have to have this set to the same value. Confer with your opponent beforehand as to how many you will set. Run-Ahead is local only, so this doesn't matter if the values are different between players. Setting Input Latency Frames Start RetroArch Discuss with your opponent how many latency frames you'll be using (I recommend starting with 1 or 2, that should be enough in most cases). Once decided, go to Netplay->Network. Set Input Latency Frames to the value decided (2 as shown below). NOTE: Leave "Input Latency Frames Range" to 0. Only set the Input Latency Frames. Also, the Input Latency Frames setting is saved when exiting RA. So make sure you check it before playing, if you'd like to change it again. Enabling Run-Ahead Start RA. Go to Settings-Latency Turn "Run-Ahead to Reduce Latency" to ON. I recommend using 2 Input Latency Frames, and 1 Run-Ahead Frame as a starting point. Switch to 1 Input Latency Frame when playing someone who is closer to you. Again, confer with your opponent, as it's important that your Input Latency Frames are the same value! 4 1 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.