4 ms·

Great article. >This process can incur quite a bit of CPU time as well. Attempting to poll the keyboard state, mouse state, and all attached gamepads can easil

by nibnib 10y ago

Great article. >This process can incur quite a bit of CPU time as well. Attempting to poll the keyboard state, mouse state, and all attached gamepads can easily eat several milliseconds per call. So it's just not possible to poll every millisecond. If input software layers mean it's not possible to poll every millisecond, why bother polling the hardware at 1kHz? Is it a just-in-case solution to increase hardware polling to maximum? I'm also curious if there are any harder numbers available, maybe by triggering a USB key input and measuring time for a test program to register the change. I know this sort of thing is done to compare CRTs and LCDs, I've never seen it done for a whole PC.

byuu 10y ago
Thank you! I was really worried about the tone being too harsh or know-it-all. Wasn't really meant for audiences that weren't aware of the context. But as an emulator author, you get people presenting new zany latency reduction ideas that defy the laws of physics all the time, and they completely dismiss your own experience in the field, and it's like kids constantly saying, "are we there yet?" on a long car ride. Eventually you lose your cool, and then well ... you sound like me in that article >_> > why bother polling the hardware at 1kHz? Is it a just-in-case solution to increase hardware polling to maximum? Yes, pretty much. More of a because-we-can and to combat the cumulative effects of latency (death by a thousand papercuts) however possible. If you were to push it to 200Hz (5ms), then it becomes possible that your OS API returns states immediately after and it stacks with your emulator latency of 5ms to form a 10ms latency. Push it to 1000Hz and that drops to a 6ms maximum latency. It is indeed silly. No one is going to perceive a worst-case 4ms difference. (And I say worst-case because these sorts of misses tend to average between best-case and worst-case, so in practice it's probably half that bad.) We're trying to chase the emulation latency of a gamepad that you literally tell it exactly when to poll the inputs and within mere cycles on a 21MHz clock, start reading out the results from its shift-register. > I'm also curious if there are any harder numbers available That would be fun. I'll admit that many of the numbers are estimated. In the end, we can only observe the net total of all latency by pressing a button and seeing how quickly the sprites respond visually and aurally. But it's probably possible to isolate similar test cases for each source of latency. In a lot of cases (kernel audio mixing, keyboard responses), we're probably talking much smaller latencies than CRT vs LCD monitors, so you'd need a huge amount of precision.
- nibnib 10y ago
  > as an emulator author, you get people presenting new zany latency reduction ideas that defy the laws of physics all the time, and they completely dismiss your own experience in the field, and it's like kids constantly saying, "are we there yet?" on a long car ride. Yep, that seems to be the usual for nearly every emulator scene. > But it's probably possible to isolate similar test cases for each source of latency. In a lot of cases (kernel audio mixing, keyboard responses), we're probably talking much smaller latencies than CRT vs LCD monitors, so you'd need a huge amount of precision. I was thinking of a test program that inverts/cycles the screen colour on registering a keypress. Put a photodiode in front of the monitor and use an electrical switch across the controller button contacts. Cheap parts and an oscilloscope will give microsecond resolution for the end-to-end net case. Unfortunately not everyone has this kind of setup lying around. I seem to remember someone marketing a commercial device that did something like this for timing CRTs vs LCDs but can't remember the name of it.
  - ilitirit 10y ago
    Leo Bodnar's Lag Testing device: http://www.leobodnar.com/shop/?main_page=product_info&products_id=212 http://www.leobodnar.com/shop/?main_page=product_info&produc... https://www.youtube.com/watch?v=zVw6T9rw0xU https://www.youtube.com/watch?v=zVw6T9rw0xU
    - nibnib 10y ago
      Thanks :)
  - mdwrigh2 10y ago
    > I was thinking of a test program that inverts/cycles the screen colour on registering a keypress. Put a photodiode in front of the monitor and use an electrical switch across the controller button contacts. Cheap parts and an oscilloscope will give microsecond resolution for the end-to-end net case. This, essentially, is one of the ways we measure end-to-end touch latency on modern phones.
ta160804 10y ago
If the OS polls at 1kHz, then when the process reads the state from the OS, the OS will give the process data that is at most 1ms old. If the OS polls at 125Hz, the data that the process reads from the OS can be up to 8ms old.
ilitirit 10y ago
In terms of competitive gaming, most serious players only care about the input lag that they can't control (they typically try to use hardware similar to the tournament standard). So for example in the Street Fighter community, players are really upset that the inherent input lag in SFV is much higher compared to previous versions. http://www.eventhubs.com/news/2016/may/08/community-begins-react-street-fighter-5s-input-lag-issue-playstation-4/ http://www.eventhubs.com/news/2016/may/08/community-begins-r... This has an impact on how the game is played.

by nibnib 10y ago

byuu 10y ago

Thank you! I was really worried about the tone being too harsh or know-it-all. Wasn't really meant for audiences that weren't aware of the context. But as an emulator author, you get people presenting new zany latency reduction ideas that defy the laws of physics all the time, and they completely dismiss your own experience in the field, and it's like kids constantly saying, "are we there yet?" on a long car ride. Eventually you lose your cool, and then well ... you sound like me in that article >_> > why bother polling the hardware at 1kHz? Is it a just-in-case solution to increase hardware polling to maximum? Yes, pretty much. More of a because-we-can and to combat the cumulative effects of latency (death by a thousand papercuts) however possible. If you were to push it to 200Hz (5ms), then it becomes possible that your OS API returns states immediately after and it stacks with your emulator latency of 5ms to form a 10ms latency. Push it to 1000Hz and that drops to a 6ms maximum latency. It is indeed silly. No one is going to perceive a worst-case 4ms difference. (And I say worst-case because these sorts of misses tend to average between best-case and worst-case, so in practice it's probably half that bad.) We're trying to chase the emulation latency of a gamepad that you literally tell it exactly when to poll the inputs and within mere cycles on a 21MHz clock, start reading out the results from its shift-register. > I'm also curious if there are any harder numbers available That would be fun. I'll admit that many of the numbers are estimated. In the end, we can only observe the net total of all latency by pressing a button and seeing how quickly the sprites respond visually and aurally. But it's probably possible to isolate similar test cases for each source of latency. In a lot of cases (kernel audio mixing, keyboard responses), we're probably talking much smaller latencies than CRT vs LCD monitors, so you'd need a huge amount of precision.

nibnib 10y ago
> as an emulator author, you get people presenting new zany latency reduction ideas that defy the laws of physics all the time, and they completely dismiss your own experience in the field, and it's like kids constantly saying, "are we there yet?" on a long car ride. Yep, that seems to be the usual for nearly every emulator scene. > But it's probably possible to isolate similar test cases for each source of latency. In a lot of cases (kernel audio mixing, keyboard responses), we're probably talking much smaller latencies than CRT vs LCD monitors, so you'd need a huge amount of precision. I was thinking of a test program that inverts/cycles the screen colour on registering a keypress. Put a photodiode in front of the monitor and use an electrical switch across the controller button contacts. Cheap parts and an oscilloscope will give microsecond resolution for the end-to-end net case. Unfortunately not everyone has this kind of setup lying around. I seem to remember someone marketing a commercial device that did something like this for timing CRTs vs LCDs but can't remember the name of it.
- ilitirit 10y ago
  Leo Bodnar's Lag Testing device: http://www.leobodnar.com/shop/?main_page=product_info&products_id=212 http://www.leobodnar.com/shop/?main_page=product_info&produc... https://www.youtube.com/watch?v=zVw6T9rw0xU https://www.youtube.com/watch?v=zVw6T9rw0xU
  - nibnib 10y ago
    Thanks :)
- mdwrigh2 10y ago
  > I was thinking of a test program that inverts/cycles the screen colour on registering a keypress. Put a photodiode in front of the monitor and use an electrical switch across the controller button contacts. Cheap parts and an oscilloscope will give microsecond resolution for the end-to-end net case. This, essentially, is one of the ways we measure end-to-end touch latency on modern phones.

ta160804 10y ago

If the OS polls at 1kHz, then when the process reads the state from the OS, the OS will give the process data that is at most 1ms old. If the OS polls at 125Hz, the data that the process reads from the OS can be up to 8ms old.

ilitirit 10y ago

In terms of competitive gaming, most serious players only care about the input lag that they can't control (they typically try to use hardware similar to the tournament standard). So for example in the Street Fighter community, players are really upset that the inherent input lag in SFV is much higher compared to previous versions. http://www.eventhubs.com/news/2016/may/08/community-begins-react-street-fighter-5s-input-lag-issue-playstation-4/ http://www.eventhubs.com/news/2016/may/08/community-begins-r... This has an impact on how the game is played.