Blur Busters Forums

https://youtu.be/6Yblf7dCCU8

I made a full latency input/rendering/output chain test in 960fps. (I saw just now that Linus by coincidence made pretty much the same thing ,but testing the sensor instead of mouse buttons, as in testing sensortime+latency+full input/output roundtrip).

Result: Slightly over 30ms from button down to flame/bullethole appearing (i was able to count frames locally before uploading, unsure if youtube preserves all frames).
I also do not know if firing a gun is completely instant in destiny2 or not or if it has some sort of un-animated trigger time or network wait before firing (I don't think so).
960fps video 1max pre-rendered frame 144Hz fps capped to 141 (ingame)with g-sync on. vsync off.
Chain also includes encoding 4:4:4 to 4:2:2 to reach 144Hz on asus PG27UQ - unsure if it adds latency (probably not, already part of rendering time).
Glorious model o mouse. 1000Hz USB
Asus gene VIII motherboard/usb with i7 [email protected]
Nvidia 2080ti
I also tested in fullscreen and hdr, and same result when counting frames. Best counted result identical.

It would be interesting if others could repeat this for various games and configs to see if we can find trends in what works, which games have fast engines, etc. If enough people spend some time doing this, we could find some interesting things

Methodology
Most modern smartphones have high fps modes. I used galaxy s9+ where "super slow mo" is 960 fps, and "slow motion" is 240fps. The video uses 960 fps which requires some timing on the users part.
https://sourceforge.net/p/countdowntimer/wiki/Home/ (supposedly) high precision millisecond counter
Klick in a quick snappy fashion so button push isn't too many frames and keep the mouse at a right angle so that the button movement is clearly visible. (or quickly snap a finger at the mouse and check movement, probably a better method as it eliminates firing a weapon with possible delay and networking).
Repeat many times, and either count frames or use the ms counter.
Note that you probably need to force vsync off in gpu settings globally to make windows not vsync (not 100% on this).

Total Input/rendering/output chain results:
Destiny2 - 144Hz ~30ms - Morkai (specs in vid)
CS:GO - 120Hz - ~20ms - Morkai (specs in vid, but left fps uncapped at around 300)
CS:GO - 240Hz ~14-36ms (depending on mouse used) - LTT - https://www.youtube.com/watch?v=orhb7Njj3h8

Nice video. Thanks to you filming the mouse button's gap so clearly, we're able to tell that a human finger adds about 8-16 ms to the latency chain; I think yours is the first one to show this. Your monitor skips some timer frames, such as 5:18:398 - 412. It happens pretty often, so your camera and setup is good but rendering has issues (maybe it's the timer's fault).

ad8e wrote:Nice video. Thanks to you filming the mouse button's gap so clearly, we're able to tell that a human finger adds about 8-16 ms to the latency chain; I think yours is the first one to show this. Your monitor skips some timer frames, such as 5:18:398 - 412. It happens pretty often, so your camera and setup is good but rendering has issues (maybe it's the timer's fault).

I noticed the timer inconsistency as well, but since I was able to count frames by stepping frame by frame locally, it can just be considered a roughly correct reference i guess.
If you know a better timer, please let me know. I am going to redo the test with the finger swipe sensor method, and also in cs:go to compare with linus's results.

I redid the test in destiny in 120Hz by snapping my finger at the mouse and counting frames until the view changed onscreen (to compare to linus's test as well). I tried swiping the sensor as well but it was too hard to determine when movement was detected.
Same result (well, slightly worse, as expected), which means that the 4:4:4 to 4:2:2 conversion on pg27uq does not in itself add additional latency.
I also tested in cs:go 120Hz but without a frame limiter to compare to linus's results, and got ~20ms which is very much in line with their ~14ms at 240Hz when you account for additional average delay from 120vs 240Hz monitor and the faster pixel response of TN vs IPS.

This means that the input/output/rendering in cs:go is extremely quick - removing pixel refresh, monitor processing, usb polling, mouse processing etc etc really doesn't leave much except the actual frametime in rendering.
Destiny2 is no slouch either, while about 10ms slower, it doesn't try to be an e-sports game, while it does have (fun) pvp matches.

i would assume using the timing of the firing animation is quite inaccurate (i.e. the fire might register before the animation)

motion latency should be generally lower
back when i was playing with input lag testing with a photodiode and a teensy board to emulate a mouse, i could get a few ms full cycle motion latency when running csgo or cs1.6 at high framerates

yea see this:
https://docs.google.com/spreadsheets/d/ ... 1384834239
or
https://docs.google.com/spreadsheets/d/ ... 2036693926

i also made my own little directx program that runs at like >10k fps. all it does it turn the whole screen white if the mouse is moved right, and black if the mouse is moved left. with that i could get <1ms motion latency (see all the tabs labeled dx9test)