In gaming, input lag is defined as the delay between the when a user does something with an input device and when that action is reflected on the monitor.
The definition is straightforward, but the reality of input lag is much more subtle than may readily be apparent. There are many smaller latencies that contribute to the overall whole of input lag and understanding the full situation may prove beneficial to gamers everywhere.
The first subtlety is that there will always be input lag. Input lag is an unavoidable reality that can only be minimized and never eliminated. It will always take some amount of time for input data to get to the software and it will always take some amount of time for the software to use that data to display a frame of animation on the monitor. Keeping this total time as low as possible is a key mission of hardcore twitch gamers out there.
This article will step through all the different contributors to input lag, and we'll give some general estimates on the impact of each different contributor. Exact numbers will vary widely with different hardware and software combinations. But knowing where to focus when optimizing for input latency should help those who are interested.
After drilling down into the causes of input latency, we will provide a few examples of different hardware and settings in our lab. The extra twist is that we will be evaluating actual input latency using a high speed camera to count frames between input activation and monitor response. We'll be looking at three different games with multiple settings on both CRT and LCD monitors.
Facebook
Twitter
RSS
85 Comments
View All Comments
aguilpa1 - Thursday, July 16, 2009 - link
Lots of variables that we never consider when trying to do fast gaming. I would be curious how much lag is in a racing sim like GRID or Colin McCrae DIRT. Those are intense graphics games and demand the fastest everything to keep you from going in the ditch. I have noticed I compensate at times by estimating when to start turning before the turn arrives.crimson117 - Thursday, July 16, 2009 - link
Isn't part of that just intentional skidding / drift in racing games, to mimic the "lag" of rubber catching asphalt at high speeds?hechacker1 - Thursday, July 16, 2009 - link
You say TF2 is GPU limited, but with my 4850 I find the first core is pegged at 100%. The same applies to my older 3850.With core i7 920 @ 166x20 = 3320MHz and +166 for Turbo mode, hyper threading on, I see TF2 using 6 cores, The first is pegged out at 100%, the second and third vary from 50-100% depending on the action (32 player server). The other three hover around 25%.
1920x1080. Benq 2400G (bought for its low input-lag)
All highest settings, 4xMSAA, Aniso 8x, Disable vsync, FOV 90
My framerate hovers around 100FPS for most Valve maps.
I use this autoexec to get more threading and higher quality textures:
rlod 0 matpicmip -10 clnewimpacteffects 1 mpusehwmmodels 1 mpusehwmvcds 1 clburninggibs 1 matspecular 1 matparallaxmap 1 rthreadedparticles 1 rthreadedrenderables 1 clragdollcollide "1" jpegquality 100 rthreadedclientshadow_manager 1
Most people say TF2 is a CPU limited game. Perhaps that only applies ATI?
Even without the autoexec.cfg, I see the game use 100% on the first core.
Very good article though. I hope this shuts up the false info that 60fps is too fast for humans to notice.
DerekWilson - Thursday, July 16, 2009 - link
even if a core is pegged at 100% that doesn't mean the game's performance is CPU limited.at 2560x1600 we were hovering around 110fps but at 1152x864 we were constantly well over 200 fps. As lowering resolution doesn't change the load on the CPU, this clearly indicates that we were GPU bound -- at least at 25x16.
For our 1152x864@120Hz test, we might have been CPU bound, but I don't have the data to know for sure here (I didn't test any near resolutions).
hechacker1 - Thursday, July 16, 2009 - link
Oh yeah.Flip queue to 0.
ATI A.I. at Low or "standard" (I've read "high" mode can use more CPU?)
Latest driver. Windows 7 x64 7201.
Qiasfah - Thursday, July 16, 2009 - link
In the article you stated that TF2 was GPU limited (and it was in the situations you were testing), however you should find that in battle situations with other active characters present it becomes heavily CPU limited. It would be interesting to see if there was a difference in input lag due to this in the midst of battles rather than sitting idle.I run an i7 920, and even with multicore enabled (an option which will very commonly double a persons TF2 framerate) i get the same dips in FPS regardless of graphical settings. It would be interesting to see how overclocking affects the performance of this game.
DerekWilson - Thursday, July 16, 2009 - link
More than likely, in TF2, you'll be bottlenecked at the network when it comes to performance ...But the way Valve does things is with local prediction (running code on the client) and then checking predictions on the server. This should mean that our test shows what you can expect to actually /see/ whether or not what actually /happens/ is the same (if you are very laggy on the network or if there are lots of players or whatever).
codestrong - Thursday, July 16, 2009 - link
"Beyond that, GPU is the next most important faster (factor?), and a mouse that can do at least 500 reports per second is a good idea." Nice work by the way. I've been interested in this since Carmack mentioned input lag during his work on quake live.DerekWilson - Thursday, July 16, 2009 - link
yeah, i meant factor. thanks.SiliconDoc - Tuesday, July 21, 2009 - link
Yes, nice article and nice work on getting the job done without a super expensive camera, on an interesting subject for gamers.