4 ms·

Input lag has nothing to do with network ping. Input lag is the time between you perform the action and the computer shows that on screen. It depends on your f

Input lag has nothing to do with network ping. Input lag is the time between you perform the action and the computer shows that on screen. It depends on your frame rate, refresh rate, and peripheral polling rate, as well as how good the game schedules things (which is what LatencyFleX tries to optimize). Network ping on the other hand is often hidden away. Whether you are on 2ms ping or 100ms ping, the bullet always goes where you aim at: this is done through rollback netcode [1], which rewinds the server state to the time the action has been performed. I'm not saying that having low ping is pointless, it has an effect on things like peeker's advantage, but the effect of network ping is drastically different from the effect of input lag. [1]: https://ki.infil.net/w02-netcode.html https://ki.infil.net/w02-netcode.html

hffftz 5y ago
How can you get input lag of 20ms? do you have to slow down your code? I only implied it was network lag because it was so high.
- formerly_proven 5y ago
  Every subsystem goes "ah buffering for a few ms or a frame doesn't hurt anybody" and in the end you have click-to-photon latencies of 150+ ms. This starts with incorrect debouncing in input devices (which can cause 10+ ms delay on its own even in dedicated "gaming" hardware!), slow/inefficent poll rates, wrong input handling in games (many still seem to receive input on the "main" thread ticking along at the frame rate, which causes huge amounts of input lag at lower framerates and also clamps inputs to frametimes, which causes significant position errors), incorrect V-Sync implementation (like the broken "triple buffering" in D3D9-11 games, this should be a thing of the past nowadays), graphics drivers favoring throughput over latency as they are almost exclusively benchmarked on average fps (used to be that they could buffer up to 9 frames, or ~150 ms) etc.
- snarfy 5y ago
  There are a variety of factors that add up to many ms of lag. USB and HDMI are a few that come to mind. USB is incredibly complex when compared to e.g. ps/2. If you are building an embedded board like rasberry pi and you want to add ps/2, you just add a couple pins. If you want to add usb, you buy an extra chip.
  - hffftz 5y ago
    > If you want to add usb, you buy an extra chip. Do you know how many chips are in a cable modem/router combo?
    - formerly_proven 5y ago
      1 or 2, depends on the kind of modem. VDSL2+ modems might have three, though one of those is the line driver which is zero-delay for the purposes of a computer.
      - hffftz 5y ago
        I've seen many more chips last time I opened one....
        jaywalk 5y ago
        Most of those chips have zero impact on latency, and many aren't even involved in the actual packet flow.
    - ben-schaaf 5y ago
      Modems/routers don't use polling nor do they need debouncing. The default USB polling rate is 125Hz, which is already 8ms of latency. Debouncing depends on the switch and is generally a couple milliseconds as well.
  - duped 5y ago
    Many CPUs have USB support. Pin count also doesn't correlate to latency, what matters is the minimum buffer size and transfer speed. USB can beat PS/2 for latency without issue.
    - WithinReason 5y ago
      Isn't PS/2 interrupt based, while USB is based on periodic polling?
- zamadatix 5y ago
  Input lag is the period between input and output, not just the time to poll the input. E.g. on 250 Hz standard mice just polling the mouse will average 2 ms input lag with 2 ms jitter and that's before you've even done anything with the input. If you don't have a high refresh rate VRR gaming display and don't want tearing the same repeats, e.g. 60hz would be 8.3 +- 8.3. That's halfway to 20 and we haven't even gotten to delays from the game code where you can choose things like triple buffering for higher FPS at the cost of another frame of latency. Input lag can also include output to the monitor and delay from the monitor depending how it's being measured. In this case it's more about the rendering pipeline input lag so the USB polling delay and the monitor output delay aren't counted, the swapchain delay to prevent tearing or trading latency/FPS are though and then you have to add in your actual game still.
- ksec 5y ago
  Those are End to End System latency. Your USB Input Devices and Monitor Refresh Rate, excluding anything in between, could easily had 20ms delay in the worst case scenario. A 60Hz monitor would have had 16.6ms of worst case latency alone.
titzer 5y ago
Thanks for that link. Very interesting!
jokoon 5y ago
Question: is that GGPO library useful for FPS games?
pugworthy 5y ago
> Whether you are on 2ms ping or 100ms ping, the bullet always goes where you aim at However what you are aiming at may not actually be where you see it. If it's another player or something critical to multiplayer gameplay, then you are going to see what the server has told you you're going to see at that location. And latency means that will be delayed. So you may think you have a clear hit on a target, but with latency the target may have moved and you haven't gotten an update yet. Or by the time your fire command gets to the server, the target has already moved. This can get pretty confusing especially if the game does client side hit effects (like bullet impacts). You shoot, you see immediate feedback of the bullet hitting, but due to latency your target moved and you missed - so the feedback is false. But if you don't do the client-side hit effect, there's a strange subtle delay that feels wrong. Client tells server they fired, server determines hit location, server sends back "hit here" message, client draws hit effect. Valve has a writeup at https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_... which covers some of the issues with network latency.
- winrid 5y ago
  It doesn't matter if where the player actually is, is somewhere else. As long as you aim at them and shoot before they shoot you, even if they are no longer there, the server will "rewind" and say you shot them, up to a certain limit. This is covered in your link :)

hffftz 5y ago

How can you get input lag of 20ms? do you have to slow down your code? I only implied it was network lag because it was so high.

formerly_proven 5y ago
Every subsystem goes "ah buffering for a few ms or a frame doesn't hurt anybody" and in the end you have click-to-photon latencies of 150+ ms. This starts with incorrect debouncing in input devices (which can cause 10+ ms delay on its own even in dedicated "gaming" hardware!), slow/inefficent poll rates, wrong input handling in games (many still seem to receive input on the "main" thread ticking along at the frame rate, which causes huge amounts of input lag at lower framerates and also clamps inputs to frametimes, which causes significant position errors), incorrect V-Sync implementation (like the broken "triple buffering" in D3D9-11 games, this should be a thing of the past nowadays), graphics drivers favoring throughput over latency as they are almost exclusively benchmarked on average fps (used to be that they could buffer up to 9 frames, or ~150 ms) etc.
snarfy 5y ago
There are a variety of factors that add up to many ms of lag. USB and HDMI are a few that come to mind. USB is incredibly complex when compared to e.g. ps/2. If you are building an embedded board like rasberry pi and you want to add ps/2, you just add a couple pins. If you want to add usb, you buy an extra chip.
- hffftz 5y ago
  > If you want to add usb, you buy an extra chip. Do you know how many chips are in a cable modem/router combo?
  - formerly_proven 5y ago
    1 or 2, depends on the kind of modem. VDSL2+ modems might have three, though one of those is the line driver which is zero-delay for the purposes of a computer.
    - hffftz 5y ago
      I've seen many more chips last time I opened one....
      - jaywalk 5y ago
        Most of those chips have zero impact on latency, and many aren't even involved in the actual packet flow.
  - ben-schaaf 5y ago
    Modems/routers don't use polling nor do they need debouncing. The default USB polling rate is 125Hz, which is already 8ms of latency. Debouncing depends on the switch and is generally a couple milliseconds as well.
- duped 5y ago
  Many CPUs have USB support. Pin count also doesn't correlate to latency, what matters is the minimum buffer size and transfer speed. USB can beat PS/2 for latency without issue.
  - WithinReason 5y ago
    Isn't PS/2 interrupt based, while USB is based on periodic polling?
zamadatix 5y ago
Input lag is the period between input and output, not just the time to poll the input. E.g. on 250 Hz standard mice just polling the mouse will average 2 ms input lag with 2 ms jitter and that's before you've even done anything with the input. If you don't have a high refresh rate VRR gaming display and don't want tearing the same repeats, e.g. 60hz would be 8.3 +- 8.3. That's halfway to 20 and we haven't even gotten to delays from the game code where you can choose things like triple buffering for higher FPS at the cost of another frame of latency. Input lag can also include output to the monitor and delay from the monitor depending how it's being measured. In this case it's more about the rendering pipeline input lag so the USB polling delay and the monitor output delay aren't counted, the swapchain delay to prevent tearing or trading latency/FPS are though and then you have to add in your actual game still.
ksec 5y ago
Those are End to End System latency. Your USB Input Devices and Monitor Refresh Rate, excluding anything in between, could easily had 20ms delay in the worst case scenario. A 60Hz monitor would have had 16.6ms of worst case latency alone.

titzer 5y ago

Thanks for that link. Very interesting!

jokoon 5y ago

Question: is that GGPO library useful for FPS games?

pugworthy 5y ago

> Whether you are on 2ms ping or 100ms ping, the bullet always goes where you aim at However what you are aiming at may not actually be where you see it. If it's another player or something critical to multiplayer gameplay, then you are going to see what the server has told you you're going to see at that location. And latency means that will be delayed. So you may think you have a clear hit on a target, but with latency the target may have moved and you haven't gotten an update yet. Or by the time your fire command gets to the server, the target has already moved. This can get pretty confusing especially if the game does client side hit effects (like bullet impacts). You shoot, you see immediate feedback of the bullet hitting, but due to latency your target moved and you missed - so the feedback is false. But if you don't do the client-side hit effect, there's a strange subtle delay that feels wrong. Client tells server they fired, server determines hit location, server sends back "hit here" message, client draws hit effect. Valve has a writeup at https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_... which covers some of the issues with network latency.

winrid 5y ago
It doesn't matter if where the player actually is, is somewhere else. As long as you aim at them and shoot before they shoot you, even if they are no longer there, the server will "rewind" and say you shot them, up to a certain limit. This is covered in your link :)