flood's input lag measurements

Everything about input lag. Tips, testing methods, mouse lag, display lag, game engine lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more!

Re: flood's input lag measurements

Postby 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.
Sparky
 
Posts: 443
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Postby 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)
flood
 
Posts: 875
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Postby Sparky » 12 Dec 2016, 01:33

That's about what I expected, though it seems like the minimum times were impacted significantly more than the average times. I suppose that any waiting for the GPU is heavily impacted by frametime variance.

Here's a pic I made to show what I think is happening:

Image

edit: minor changes to image.
Last edited by Sparky on 12 Dec 2016, 17:35, edited 4 times in total.
Sparky
 
Posts: 443
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Postby Sparky » 12 Dec 2016, 01:43

To clarify a couple points of the image:

Latency, as measured by your device, ranges from a random point of the Green "Input" bar, to the start of the green "Results" bar.

If the cap is below the MQM 0 framerate, the two CPU threads stop overlapping.
Sparky
 
Posts: 443
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Postby stirner » 12 Dec 2016, 17:05

Great stuff. Making me feel bad for capping below 300.

Request: Can you shut down the "NVIDIA Display Container LS" service from services.msc (it will kill the NVIDIA Container and Experience processes) and check whether it affects CS:GO latency at all?

And out of bullshit curiosity: Mind checking whether running Steam/CS:GO in admin mode changes anything? Likewise, running Steam from a shortcut with the "-no-browser" parameter to prevent the web helper from being co-launched. These probably change next to nothing/negligibly affect performance at most, but hey, they are easy enough to test and I take it you want to test.
stirner
 
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: flood's input lag measurements

Postby lexlazootin » 12 Dec 2016, 21:09

stirner wrote:Great stuff. Making me feel bad for capping below 300.


Whoa, don't jump to conclusions mate. Simply saying that you shouldn't cap below 300fps would be a assumption based on the test results.

My guess based on the Spark and Floods post is that capping somewhere below your lowest fps count (550/500 in this case) reduced latency because of the freeing up of CPU time? But going any lower will obviously would add latency due to the frame times rising.

So every system would be different and the map/gamemode would factor into this as well.

stirner wrote:Request


You're probably right in saying those would reduce latency, but only in terms of freeing up rendering times VERY slightly or not even noticeable amounts.

Flood, what CS:GO team you on?
lexlazootin
 
Posts: 769
Joined: 16 Dec 2014, 02:57

Re: flood's input lag measurements

Postby flood » 12 Dec 2016, 21:33

stirner wrote:These probably change next to nothing/negligibly affect performance at most, but hey, they are easy enough to test

well then i should also test if flushing my toilet does anything :P

it is easy in the sense that it would take like 10min or so but nowadays i have only a hour or so a day on weekdays. so i'll probably do it during the weekend

for csgo, first step is to determine all the framerate/frametime dependent effects. (i.e. stuff that can be explained by stuff like Sparky's drawings above). the amount of lag that's not explained by that is the thing thing to worry about. if that amount is X, that means that doing anything to my setup, which doesn't affect the framerate/time, can improve the input lag by a maximum of X.
flood
 
Posts: 875
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Postby Sparky » 12 Dec 2016, 21:47

lexlazootin wrote:My guess based on the Spark and Floods post is that capping somewhere below your lowest fps count (550/500 in this case) reduced latency because of the freeing up of CPU time? But going any lower will obviously would add latency due to the frame times rising.
Because it eliminates the waiting between the CPU being done with the frame, and the GPU being ready to start working on a frame.
So every system would be different and the map/gamemode would factor into this as well.

Yep.
Sparky
 
Posts: 443
Joined: 15 Jan 2014, 02:29

Re: flood's input lag measurements

Postby flood » 12 Dec 2016, 22:34

i'm not so sure about that
also in actual gameplay fps fluctuates so much that it's probably best to just use uncapped (or fpsmax 1000 to avoid glitches with source engine)
flood
 
Posts: 875
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Postby Sparky » 12 Dec 2016, 22:51

flood wrote:i'm not so sure about that
also in actual gameplay fps fluctuates so much that it's probably best to just use uncapped (or fpsmax 1000 to avoid glitches with source engine)


I think a framerate cap of about 90% of a high average framerate is beneficial if you're GPU limited. Pointless if you're already CPU limited.

If the fluctuation in frametime was caused by the CPU, you might want to stay GPU limited, just for more consistency, but it's pretty clear that most of the variance that isn't caused by framerate is caused by the GPU, otherwise the uncapped graph would show a more uniform distribution, less normal distribution.
Last edited by Sparky on 12 Dec 2016, 22:54, edited 3 times in total.
Sparky
 
Posts: 443
Joined: 15 Jan 2014, 02:29

PreviousNext

Return to Input Lag

Who is online

Users browsing this forum: No registered users and 1 guest