flood's input lag measurements

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 10 Dec 2016, 01:44

soooooooo

gpu scaling on my old pc (i7 920, x58, gtx580)

adds

~120us input lag

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 10 Dec 2016, 10:53

very cool, probably the first time this info has been made public, or has even been measured.

Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Re: flood's input lag measurements

Post by Q83Ia7ta » 10 Dec 2016, 15:33

flood wrote:soooooooo

gpu scaling on my old pc (i7 920, x58, gtx580)

adds

~120us input lag
thanks for sharing!

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 10 Dec 2016, 19:27

actually i'm not sure how much it adds. whatever it is, it's negligible
np.mean(np.loadtxt("log_1600x1200_85_d.txt"))
Out[7]: 1485.0177536908989

np.mean(np.loadtxt("log_1280x960_85_7350_gpuscaled.txt")) # upscaled to 1600x1200 by gpu
Out[8]: 1534.7039894926941

np.mean(np.loadtxt("log_1280x960_85_7700.txt")) # after adding a 1280x960 mode with CRU and rebooting
Out[9]: 1522.5928985507246
numbers are average latencies in us. filename format is "log_<width>x<height>_<refresh rate>_<dx9test framerate>_<notes>"

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 10 Dec 2016, 20:19

lexlazootin wrote:https://youtu.be/9ty1arbqepU
http://www.mediafire.com/download/kkrav ... o_dust.zip
It's about the same as the fps you would get on dust2.

I would just edit dust2 and place a bunch of these boxs around the place but rendering the whole map would probably take a full day, i might look into writing a sourcemod plugin to do it.
k measurements on this map, for m_rawinput 1, mat_queue_mode 0 and 2. framerates were 325 and 550 respectively

screenshot because i'm lazy:
Image

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 10 Dec 2016, 21:10

csgo m_rawinput 0/1, with mat_queue_mode 0

framerate was around 325-330 consistently

8 consecutive batches of measurements in this sequence:
A: m_rawinput 1
B: m_rawinput 0
C: m_rawinput 0
D: m_rawinput 1
E: m_rawinput 0
F: m_rawinput 1
G: m_rawinput 1
H: m_rawinput 0

the teensy is plugged in for 1 minute for each batch. no alt-tabbing.
aroudn 1750 measurements per batch

Image

m_rawinput 0 is ~225us faster pretty consistently.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Post by Sparky » 10 Dec 2016, 21:39

flood wrote:
lexlazootin wrote:https://youtu.be/9ty1arbqepU
http://www.mediafire.com/download/kkrav ... o_dust.zip
It's about the same as the fps you would get on dust2.

I would just edit dust2 and place a bunch of these boxs around the place but rendering the whole map would probably take a full day, i might look into writing a sourcemod plugin to do it.
k measurements on this map, for m_rawinput 1, mat_queue_mode 0 and 2. framerates were 325 and 550 respectively

screenshot because i'm lazy:
Image
Looks like you got GPU limited. maybe try mqm 2 with fps_max 500?

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 10 Dec 2016, 22:07

what do you expect that to do though?

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Post by Sparky » 11 Dec 2016, 01:39

flood wrote:what do you expect that to do though?
I expect it to keep you CPU limited, so that the GPU can start working on each frame immediately, instead of the frame waiting for gpu resources to become available. If you look at your average latency, MQM 0 is approximately 2 frames of latency at 325fps, but MQM 2 is 3 frames of latency at 550fps.

Say your pipeline looks like this(hypothetical and oversimplified, estimated purely from the given framerates):

MQM 0, 325fps, CPU limited: You wait an average of 1.5ms for the game engine to start working on the next frame. It takes the CPU 3.1ms to finish a frame and push it to the GPU. It then takes 1.8ms for the GPU to render it and push it to the monitor. (total: 6.4ms)

MQM 2, 550fps, GPU limited: You wait an average of 0.9ms for the game engine to start working on the the next frame. It takes the CPU 3.1ms to finish the frame. You wait 0.5ms for the GPU to become available. The GPU then takes 1.8ms to render and display the frame. (total: 6.3ms)

MQM2, fps_max 500: You wait an average of 1.0ms for the game engine to start working on the next frame. It takes the CPU 3.1ms to finish the frame. The GPU then takes 1.8ms to render and display the frame. (total: 5.9ms)

The exact predicted latencies obviously disagree somewhat with reality(this model predicts a uniform distribution, your measurements have tails on both sides of it because frametime isn't perfectly fixed). If you look at the histograms, I think the cap will shift the MQM 2 distribution over to the left so the minimum values line up with the minimum values of MQM 0.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 12 Dec 2016, 00:12

these are my notes from last year
http://www.esreality.com/post/2691945/m ... pid2714776

anyway these are the new measurements

for csgo, 800x600@160hz, all settings low/verylow, 4x msaa, trilinear filtering, lexlazootin's map
filename has settings. last number is the actual fps.
each file corresponds to 1minute of data. for the last file, i ran with fps_max 0 again to estimate the consistency of everything

Image

empirically: the average latency is not significantly affected by the cap, until the cap is around half the uncapped framerate (600 in this case)

plotting histograms now

edit:
fps_max 0 (actual fps ~600)
Image
fps_max 550
Image
fps_max 500
Image
fps_max 450
Image
fps_max 400
Image
fps_max 350
Image
fps_max 300
Image
fps_max 250
Image
fps_max 200
Image

for now i'm too lazy to think about what this actually means (as in what csgo/source engine actually is doing.)

if anyone wants to explain it, please include a diagram like mine here (which applies for when there is a single rendering pipeline): http://i.imgur.com/9cSP1bM.png

empirically, it appears that when fps_max is capped below 300, the latency is as if there's a single rendering pipeline.



notes:
there's around 1-1.5ms latency unrelated to csgo (since dx9test shows this amount of latency at very high framerates)
todo - repeat with high graphics settings to make it more gpu-limited
repeat with main pc (4770k, gtx970)

Post Reply