CS:GO input lag test - multicore rendering

[sharknice]

In another thread someone was asking about input lag with multicore rendering. I ran a couple tests to find out.

fps_max 1000
During the test the frame rate with multicore enabled was around 800 and with it disabled was around 400.
With multicore enabled the input lag ranged from 5 ms to 21.7 ms with an average of 12.3 ms. Multicore disabled ranged from 1.7 ms to 21.7 ms with an average of 12.1 ms. The difference at such high frame rates is fairly negligible, but enabling multicore does add a small amount of input lag.

fps_max 144
With multicore enabled the input lag ranged from 5 ms to 26.7 ms with an average of 16.4 ms. Multicore disabled ranged from 3.3 ms to 23.3 ms with an average of 12.8 ms. It is still less than a 4 ms of additional input lag, but it is a significant percentage and will be higher at lower frame rates.

More details on my Counter-Strike: Global Offensive Input Lag page. I plan on doing more input tests lag later.

[RealNC]

Awesome, thanks! Very nice effort.

A few other things that are weird in CS:GO is frame capping with VSync. For example, on a 60Hz minitor, capping to 59, waiting 2-3 seconds and then capping to 60 results in less input lag than directly capping to 60 (from the default 300). Engine bug? After some time though, the input lag seems to "catch up" again (in the 59->60 case).

[Berserker]

Did you measure with highest graphics or lowest?
I remember that CS GO by itself has quite low input lag and multicore is not as annoying. In TF2 or L4D1/2 its way worse.

[Chief Blur Buster]

Good job -- I think we will be creating an "Input Lag" forum topic area in the not-so-distant future.

[flood]

Can you also test whether SLI affects input lag in CSGO?

[nimbulan]

It looks like an average increase in input lag of half a frame. I imagine that would only be noticable to the most sensitive people. Definitely good information to know though, I had not considered how multicore rendering would affect input lag.

[devi]

Hi,

good job on testing. You should be aware that when testing input lag in CS:GO, that the gun firing is considered a physics effect that is only calculated on tick frames, i.e. tickrate times a second, i.e. independent of fps. Hence the mean input lag (AS CALCULATED FROM GUN SHOTS; NOT MOVING THE MOUSE) shouldn't vary much with FPS unless there are frame queue type issues. Minimum latency should decrease, though, with more fps. So maybe there are some effects on FPS variance. This is one issue I would like to understand better, I attempted some tests here: http://forums.steampowered.com/forums/s ... ?t=3087112

[flood]

Hi,

good job on testing. You should be aware that when testing input lag in CS:GO, that the gun firing is considered a physics effect that is only calculated on tick frames, i.e. tickrate times a second, i.e. independent of fps. Hence the mean input lag (AS CALCULATED FROM GUN SHOTS; NOT MOVING THE MOUSE) shouldn't vary much with FPS unless there are frame queue type issues. Minimum latency should decrease, though, with more fps. So maybe there are some effects on FPS variance. This is one issue I would like to understand better, I attempted some tests here: http://forums.steampowered.com/forums/s ... ?t=3087112

that's something i suspected as well... and probably explains the large variation in the range of measured input lag from everyone who's done the gun motion type of measurement.

mouse motion, however, is not dependent on tickrate.. and in my thread where i measure mouse motion lag, i (so far) have found no difference with multicore on or off

it's unfortunate that csgo can't run at a standardized fps like quake live (250) or cs1.6 (100)

[RealNC]

it's unfortunate that csgo can't run at a standardized fps like quake live (250) or cs1.6 (100)

You can run it at 100tick if you want. You'll obviously need to install the dedidated server for this, and configure the server for 100tick:

http://css.gamebanana.com/tuts/5638

[TheLeetFly]

devi, could you please repeat your test with a fps lock at 128 frames [maybe 64 AND 128 tick with this framerate] ?!
In my opinion the drawtimes of the frames result in originate in the difference between lock and tickrate.

Thank you in advance.

EDIT: Oh sorry, I overlooked your second image. Would you agree with me, that the variance in this picture
originates of the Interpolation of the tickrate itself? In one frame the real TICK is applied and renderd and in the second frame the interpolation of the tickrate occurs. One of these two steps is the longer frame and the other one is always the shorter one.