Blur Busters Forums

Well, I've been saying that for years now

RealNC wrote:Well, I've been saying that for years now

You sure have, its nice to have some numbers here to back it up. Getting input lag data is very time consuming and costs some money as well.

And we observed this in January 2014.

Chief Blur Buster wrote:And we observed this in January 2014.

This part right?

The good news now comes: As a last-ditch, I lowered fps_max more significantly to 120, and got an immediate, sudden reduction in input lag (27ms/24ms for G-SYNC). I could no longer tell the difference in latency between G-SYNC and VSYNC OFF in Counterstrike: GO! Except there was no tearing, and no stutters anymore, the full benefits of G-SYNC without the lag of VSYNC ON.

Why is there less lag in CS:GO at 120fps than 143fps for G-SYNC?

We currently suspect that fps_max 143 is frequently colliding near the G-SYNC frame rate cap, possibly having something to do with NVIDIA’s technique in polling the monitor whether the monitor is ready for the next refresh. I did hear they are working on eliminating polling behavior, so that eventually G-SYNC frames can begin delivering immediately upon monitor readiness, even if it means simply waiting a fraction of a millisecond in situations where the monitor is nearly finished with its previous refresh.

I did not test other fps_max settings such as fps_max 130, fps_max 140, which might get closer to the G-SYNC cap without triggering the G-SYNC capped-out slow down behavior. Normally, G-SYNC eliminates waiting for the monitor’s next refresh interval:

G-SYNC Not Capped Out:
Input Read -> Render Frame -> Display Refresh Immediately

When G-SYNC is capped out at maximum refresh rate, the behavior is identical to VSYNC ON, where the game ends up waiting for the refresh.

G-SYNC Capped Out
Input Read -> Render Frame -> Wait For Monitor Refresh Cycle -> Display Refresh

There is one inaccuracy in the video, the anti-lag settings should also help in a display limited scenario with v-sync on. Still not as good as an in-game cap though.

## About Chris Video

People here were talking about capping input lag for a while even before Battlenonsense video. I do not think this is 100% accurate because there is different cases. If you have near 100% gpu utilization it means the gpu are working 100% of time which is a sign that it is not fast enough to match cpu deliveries so you end-up queueing frames. This bottleneck is best observed using GPUView from Windows Performance Toolkit . When you have extremely low GPU render times compared to CPU (like you get in games like CSGO and Overwatch with competitive video settings) the pre-rendered is not a issue at all. The strange part of Chris work is that ultra low latency having a negative impact when it should have none... but that is probably due to implementation details.

## Inconsistent delivery with networking

Depending on the game engine you have a throttling on command delivery called tickrate.
You could write throttling algorithms in many different ways but usually games just checks timestamps interval.
Something like:
min_allowed_time = 1000 / tickrate
if ((old_ts - current_ts) < min_allowed_time) {
execute_network_block()
}

So if your frame interval is 7.75ms and your min_allowed_time is (7,81ms for 128tickrate) then you almost always have to wait an entire frame to send the current cmd.

In this scenario frame-capping to a bad gradient (just a little faster then the tickrate) is worse than ultrafast uncapped (300fps) but fixing at a good value is very positive.

Many of those button to pixel tests do that with strafe and guns that is affected by the server even with the mitigations like prediction and interpolation and happens even on local server for some games (i.e. CS). The correct way is to move the mouse since that is well known to be 100% independent from the server.

## Some other strange behaviours

You can check the render time (cpu + gpu) using GPUView. One think that is very strange is that if you lock your fps to something low like 60 that you have your render time of something like 7ms for rendering and then it will sleep for while. This will have low input delay since this will just render and call present (we are entering the discussion talking about 60hz delay but the time between command and render). Now the strange think is that even with no energy saving it will take something like 7 ms to render once it starts but when you raise the cap limit or unlock it will squash that render time to something as low as 2 ms. This behaviour happens both on Counter Strike and Overwatch. This do not seems to be some sleep function since there is another dll for sleep that is very easy to observate.

Hey guys, a quick question about this

Does it matter if we cap below or above the refresh rate? I got from this video its better to cap for lower input lag, but it doesn't say "cap below refresh rate" for example on fortnite I can get 200 FPS on average, but I leave uncapped and so I'm around 200-250 all the time and my refresh rate is 144 hz

Is it better to cap 200 FPS since I rarely dip below that or cap at 144 FPS? Again I agree capping FPS is overall better, atleast that's what I got from the video, but if I can reach 200 FPS consistently then isn't it better to cap at 200 FPS or will that kind of make my game not smooth? I don't get about tear line (I rarely see it anyways so its not a problem for me to go above refresh rate)

Known for years really.

He does some good testing, but not always thorough.

For instance the 'Game mode' setting allegedly took 5ms input lag off, but never did more testing with it or any follow up.

We don't know what he was all running on his system, background apps, etc. I find it hard to believe if you run two systems, totally clean (LTSB/C level or even further stripped down), one with and one without game mode, you would achieve any input lag reduction what so ever.

Not to mention the times various windows 10 builds changed mechanics.

GFresha wrote:Does it matter if we cap below or above the refresh rate?

As long as you're not using a syncing method in your case (V-SYNC OFF @144Hz, 200 FPS), and your framerate is being constantly limited by the set FPS cap, AND your GPU usage isn't maxed, then this should work to reduce input lag at any FPS limit your system can sustain, whether it be above or below the refresh rate.

The method depicted in the video is divorced of syncing solutions and pre-rendered frames queue settings, and instead relies on the set FPS limit to prevent max GPU usage, which (typically) effectively eliminates the pre-rendered frames queue/GPU bottleneck so long as the system FPS is sustained above the set FPS limit at all times.