Cap your fps people (battlenonsense)

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Post Reply
User avatar
ko4
Posts: 126
Joined: 06 Jul 2018, 16:14

Cap your fps people (battlenonsense)

Post by ko4 » 19 Sep 2019, 03:39

phpBB [video]

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Cap your fps people (battlenonsense)

Post by RealNC » 20 Sep 2019, 00:56

Well, I've been saying that for years now :P
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
tygeezy
Posts: 104
Joined: 29 Feb 2016, 21:56

Re: Cap your fps people (battlenonsense)

Post by tygeezy » 20 Sep 2019, 14:08

RealNC wrote:Well, I've been saying that for years now :P
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.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Cap your fps people (battlenonsense)

Post by Chief Blur Buster » 20 Sep 2019, 15:27

And we observed this in January 2014.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Roen
Posts: 3
Joined: 31 Jan 2019, 15:18

Re: Cap your fps people (battlenonsense)

Post by Roen » 20 Sep 2019, 18:52

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

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Cap your fps people (battlenonsense)

Post by Sparky » 20 Sep 2019, 20:36

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.

andrelip
Posts: 160
Joined: 21 Mar 2014, 17:50

Re: Cap your fps people (battlenonsense)

Post by andrelip » 23 Sep 2019, 10:34

## 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.

GFresha
Posts: 94
Joined: 01 Mar 2019, 17:28

Re: Cap your fps people (battlenonsense)

Post by GFresha » 26 Sep 2019, 14:15

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)

MT_
Posts: 113
Joined: 17 Jan 2017, 15:39

Re: Cap your fps people (battlenonsense)

Post by MT_ » 26 Sep 2019, 15:19

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.
LTSC 21H2 Post-install Script
https://github.com/Marctraider/LiveScript-LTSC-21H2

System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Cap your fps people (battlenonsense)

Post by jorimt » 26 Sep 2019, 15:29

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.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

Post Reply