iRacing – FPS, VSYNC, and Input Lag

As you probably know, there is always some controversy with graphic options and input lag, and in simracing, such matter is particularly important.

This is a useful post written a couple of years ago by Michael Gomen.

Seen a ton of confusion and posts about this subject so I’m just gonna post this here and maybe someone will sticky it where it belongs.

Just to get this out of the way, whether you notice input lag from Vsync or not- it’s still really there, always was and still is. It has almost nothing to do with system performance or computer specs, but your monitor quality and type have a mild affect on the delay. Whether you personally can perceive it, or whether it bothers you, or how much it affects your driving ability is totally subjective- but the lag is still there, period. I don’t personally care whether someone can feel it or not, but I promise you it is nevertheless there. No gut-feeling or intuition is involved with this- you are also always incurring some additional amount of lag whether you have either vsync enabled or you are just capping frames.

Vsync causes the program to “halt” or relinquish process time until it receives a message from the monitor that a frame has been completed. Then it copies the frame buffer before the next screen writing process begins. Meanwhile, I don’t care how fast your computer is, it is doing exactly nothing while it waits, including NOT processing inputs, physics, etc even though you are still using them. Waiting = delay by definition. The fastest computer in the world is going to have 0 effect on the type of delay we are talking about here since this type of lag is solely based on the monitor’s ability to draw and respond as quickly as it can.

Almost everyone has some form of LCD/flatscreen now which generally almost always run at 60 hz (mine can do 61 “overclocked” so I use it). This means at worst case scenario, with a terrible monitor that takes its entire allotted timeframe of 1/60 seconds to write a frame and then transmit a completion signal back, that you would be dealing with a 16.66~ ms delay. It never should be that bad unless the monitor is malfunctioning, but even small portions of a 16 ms delay are quite noticeable to a lot of people especially if you’ve been a hardcore gamer for a long time. Even a couple ms delay on a mouse is very noticeable to some people, let alone up to 16 ms, which is why gaming mice these days come overclocked and poll well over 1000 hz in some cases (that’s playing with sub-1 ms improvements at increased price). People don’t buy these mice or overclock them for no reason, many very well can legitimately sense 1-2 ms delays in inputs and below and feel that their gameplay would improve by decreasing that delay. How many extra frags they actually get or how many milliseconds they shave on lap times is subjective, but it probably is some tangible improvement even if undetectable. The wheel/pedal lag in a driving sim may not be as noticeable as a mouse but once again, that’s subjective, and it’s still very real and based in exactly the same hardware/software constraints as a mouse.

Even if your monitor can write a frame in 0.1 ms and transmit the completion signal in 0.1 ms, you are still dealing with more problems involving the fact that your process nevertheless gave up priority for a short time and may not have gotten it back exactly by the time the monitor was ready. Perhaps some processes still try to “do some other work” while waiting. I’ve never personally seen anything coded this way, but if iRacing is then you still have to consider that even if the process doesn’t let go of priority, that now the code must be doing another job which may not be finished exactly in time with the VBI signal from the monitor. This of course is yet another source of potential delay that gets compounded with write times and message sends, but it has less to do with computer performance in general and much more to do with interrupt timings/DPC’s, kernel sharing, and general randomness that you nor anyone else would likely ever be able to get control over beyond closing all applications and services that you don’t need and making sure drivers are updated and solid.

The argument about 60 fps capped with vsync OFF versus higher fps rates is still not about whether your eyes can see above 60 hz or not (btw, they can, all the way into the 200 hz range and higher depending on the content and person). I’ve seen this debate so many times in 15 years it’s exhausting. Despite whatever is showing on your monitor, the reason you STILL get input lag with Vsync off at 60 fps capped is for exactly the same reason you feel it with Vsync on, but less severe- Waiting. “Capping” the frame rate means if the process sees it isn’t time to produce another frame yet, then it must release priority or find something else to do for a little while- same exact activity as waiting for a vsync message. Waiting is waiting is waiting. For exactly the same reasons as described before, “not doing work for a while” will produce some amount of delay < 16.6 ms but with a difference being that now we aren’t dealing with VBI message send delays and the monitor write time compounding ontop. Thus the situation is improved substantially, but there is still a very real X amount of lag whose range can vary wildly and is not realistic to try to predict, other than to say it can’t be over 16.6 ms and that it can’t be as bad as Vsync, since Vsync only adds several more delay factors.

How can you reduce the delay between your input and what is actually happening within the sim (regardless of what your monitor is showing) ? Don’t tell the process to wait, for any reason. It’s that simple of an answer. Unfortunately this means letting your FPS fly uncapped so that it never stops processing, which also increases resource usage, computer temps, hardware degradation, etc etc. It is a trade-off that you have to choose between, there is no correct answer to this. Capping the rate somewhere above 60 and not letting it fly unhindered to keep temps cooler is a decent compromise, but there will still be some delay each time the process catches up and lets go of priority, preventing input from being processed to output for some amount of time. This incurred delay decreases as the amount of time the process is in waiting mode decreases (the closer to running at maximum fps you allow it to go). Even at maximum fps there is naturally still some amount of lag since we are talking about very complex electronic devices here, but playing with vsync/fps caps certainly can’t improve beyond this inherent amount of lag.

How can you reduce the delay between your input, the process, and how long it takes to see it on the monitor? Get a better monitor. This is why some very hardcore gamers still buy CRT’s, and why they are still sold- the refresh rates can usually be overclocked dramatically (I had an NEC that did 170 hz, it was spectacular). You can still stack them in multi-monitor mode to simulate widescreen but that route is pretty expensive. If you want to stay with LCD’s then you may not be able to improve past 60 hz, but higher quality monitors “should” still do their writes more quickly and respond more quickly than inferior LCD’s, which is an improvement. How to determine the write/response times of LCD’s is outside of this scope and requires a good amount of research into exactly what you’re buying. Although having an overclocked CRT would make the most dramatic improvement, purchasing a superior LCD over the rest is still a meaningful improvement despite the fact they usually all share the same 60 hz refresh. What quality of monitor you own, what refresh rate, or whether it’s even plugged in has no effect on how soon and at what rate the iRacing process handles your inputs when vsync is off and fps is uncapped. This is why people swear by uncapped frames and swear that they can sense a difference in handling- because they can. If you can’t sense a difference or don’t feel that it’s necessary, then you don’t. It doesn’t mean that it’s because you have awesome hardware, or should suggest others buy more RAM and a nicer video card like you have so that they can enable Vsync too. That’s poor for humanity since it is wrong.

How to deal with screen tearing ?

1) Enable Vsync and incur the biggest physical input-to-screen delay possible. IE deal with it for prettier graphics. Triple buffering isn’t going to save you from this. If you think there is no delay here all I have to say is “ignorance is bliss”, it’s perfectly up to you. If your lap times or whatever truly do not suffer by any fractionally tiny margin (or it actually helps you mysteriously so), then I would say that that is astounding and hard to believe, but good for you. You may also be well aware of the lag but prefer the graphics. That’s respectable. The sole upside of Vsync is that there is zero tearing and maximum smoothness/consistency of objects moving across the screen.

2) Disable Vsync but cap fps to your monitor’s refresh. This still incurs a delay (waiting is waiting) but less so of one than vsync, since you are waiting for less things to happen. You will also notice the tear predominately in 1 place on the screen as objects along the tear move horizontally (a random vertical portion of the screen is 16~ ms behind in time with the rest of the frame). The tear also slowly fluctuates and wanders around the vertical axis of the screen from timing/rounding errors and is disturbing to some people, to others not so much. This method also has the very nasty effect of making fast and consistent movement of objects (the landscape from afar, or trees/buildings) “click” or stutter across the screen annoyingly so, rather than smoothly traversing it. As in, 1 step, 1 step, 1 step, 2 steps, repeat.. it’s not very natural in appearance. This gives me a headache instantly which is why I personally don’t use this method.

3) Disable Vsync and cap fps slightly above or below monitor refresh. This is same as above but the tear will vertically jog up and down the screen more quickly and not change direction, which may or may not be less disturbing. The tear won’t get “stuck” right across the windshield and hang out for 15 seconds before it decides to wander off. The severity of “stuttering” in moving objects is reduced if you go above 60 hz and increased if you go below.

4) Disable Vsync and uncap your frames. This is a common solution and incurs the least input delay possible. Also the difference in time between two parts of a torn frame are minimized making the tear itself as mild as possible short of enabling vsync. The tear also moves around somewhat randomly depending on the circumstances, or the current ratio between monitor hz and fps, which helps decrease the obviousness that it is there (it can still occasionally get stuck in a certain spot for a while or jog at certain parts of a course where your fps changes). Naturally the downside is that you’re working your PC as hard as it can go, so some piece of hardware X in your machine is always bottlenecking and maxed out for sustained periods rather than the monitor bottlenecking the computer and giving it a much-valued break. The worst danger here is if one component of your build is severely behind pace with the rest of your computer (IE gpu overheating the entire time, cpu overheating constantly, etc).

5) Take iRacing’s suggestion and set the cap to 1.4x your monitor’s refresh, approximately. This has less incurred delay than capping at 60 fps assuming your computer actually can maintain that fps easily, and reduces usage. Any break, even small, that the process can grant your hardware has a fairly strong impact on temperatures and degradation. The interesting part of this compromise and using that ratio is that the “chord” harmonic produced between monitor hz and fps (60:84) results in a tear that seemingly ends up in random places every frame in a forced fashion, rather than periodically “tracking” up and down the screen in a patternistic manner. The placement height of the tear each frame would look like the decimal values if you divided 5/7 on a calculator- no pronounced pattern, therefore it is likewise harder to see on-screen since it rarely resides in the same place for long or “jogs” in a meaningful direction.

6) Buy a CRT(s) that can overclock higher. Hard to find, expensive, heavy, bulky, etc etc. But awesome. If you can run at 120 hz or 144 hz (or higher), you can actually safely enable vsync and incur half the delay or less than you would from a 60 hz LCD. After a certain point, enabling or disabling vsync truly would become unnoticeable to anyone and is only limited by how high the refresh rate of the CRT can be clocked safely. The tearing effect without Vsync is also less noticeable since it is displayed much more rapidly and for shorter amounts of time, assuming your FPS is actually keeping pace. For anyone who hasn’t seen what this looks like in action, if I were to make an analogy then I would say that going from a 60 hz monitor to 120-144 hz with a game whose framerate could keep up was almost as dramatic is it was seeing a full HD picture for the first time, but I eventually tossed it in favor of removing the hassle and cost that everyone knows CRT’s are.

I’ve presented to you the same dilemma that has plagued computer gaming since it came into being and the same options that have always been there; it’s choosing a balance between input lag, graphics quality, and hardware dependence/abuse and there is no solution that minimizes all three issues at the same time.

Hope this helps.