flood's input lag measurements

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.
flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 08 Apr 2015, 04:58

bleh tempted to get this oscilloscope
http://sfbay.craigslist.org/nby/ele/4968167450.html

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

Re: flood's input lag measurements

Post by Sparky » 08 Apr 2015, 05:57

flood wrote:bleh tempted to get this oscilloscope
http://sfbay.craigslist.org/nby/ele/4968167450.html
$1 :roll:

I did some testing with radeonpro and v-sync.

Triple buffering isn't working with this test, and I don't think it would make one bit of difference, because the GPU render time is nonexistent.
Edit: "Lock frame rate up to monitor's refresh rate" isn't getting forced on correctly either.

V-sync on, no framerate limiting is about 55ms latency (85hz refresh rate).
DFC does nothing at 86fps v-sync on.

The following options are all pretty much identical, which is either ~22ms or ~34ms, depending on whether this frame happens to miss the v-sync deadline:
DFC 85 with v-sync on
DFC 84 with v-sync on


So, you can save about ~25ms of average v-sync latency by adding ~12ms of variance. No idea if that's a trade worth making.

Next up: MSI afterburner.
Last edited by Sparky on 08 Apr 2015, 15:59, edited 2 times in total.

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

Re: flood's input lag measurements

Post by Sparky » 08 Apr 2015, 06:46

Rivatuner(which comes with MSI afterburner) is a full frame faster than DFC when it comes to frame limiting.

Rivatuner cap at 86 does nothing with v-sync on. (56ms)
Average latency at 85 is 10ms with v-sync off.
at 85 and 84 with v-sync on, it shows the same single frame jumps that radeonpro had, but shifted down 1 frame. So instead of trading 2 frames of average latency for 1 frame of variance(compared to v-sync), you trade 3 frames of average latency for 1 frame of variance.

I guess this means DFC stalls the GPU, and rivatuner spoofs backpressure.

So, if you're going to play with v-sync, this is the way to do it.

Edit, it takes longer to make these graphs than to just run the tests:
Image

Image

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: flood's input lag measurements

Post by stirner » 08 Apr 2015, 10:48

The following options are all pretty much identical, which is either ~22ms or ~34ms, depending on whether this frame happens to miss the v-sync deadline:
DFC 85 with v-sync on
DFC 84 with v-sync on
"Lock frame rate up to monitor's refresh rate" with v-sync off
Are you suggesting these are identical because of DFC or that generally it wouldn't make a difference to cap framerate below refresh rate with vsync on, even that vsync on is the same as framerate capped at refresh rate with vsync off? Because that doesn't seem right.

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

Re: flood's input lag measurements

Post by Sparky » 08 Apr 2015, 15:42

Ignore what I said about "lock framerate up to monitor's refresh rate". Radeonpro isn't forcing it on correctly.

DFC at 85 and 84 are both capping framerate slightly below the nominal refresh rate, so there isn't a ton of lag accumulating, but you sometimes miss the v-sync deadline.

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: flood's input lag measurements

Post by stirner » 08 Apr 2015, 16:15

I always felt that capping framerate below refresh rate decreases vsync-induced lag, but your results are right that at least 1 up to a few frames per second will be displayed twice as they miss the sync because of fluctuation/frametime variance.

I think you should go away from external limiters though and either try to implement a cap in your test simulation or just use CS:GO. Framerates are lower, but conclusions are more useful regarding actual implementations. fps_max 84.999999 with 85Hz vsync. And maybe rivatuner cap vs. fps_max cap latency without vsync.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 08 Apr 2015, 16:44

the easiest way to detect (frames of) input lag is to make an application that draws a vertical line that follows the cursor and seeing how far behind the line lags the windows cursor

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

Re: flood's input lag measurements

Post by Sparky » 09 Apr 2015, 00:12

I did some testing in CS:GO, on frame limiting and v-sync modes(click for interactive version):

Image

Image


If you want raw data or a more focused graph, let me know.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: flood's input lag measurements

Post by flood » 09 Apr 2015, 02:08

looks like the input is being synchronized to the framerate...
are you sleeping a random number of ms between each cycle?

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

Re: flood's input lag measurements

Post by Sparky » 09 Apr 2015, 06:36

flood wrote:looks like the input is being synchronized to the framerate...
are you sleeping a random number of ms between each cycle?
What you see on the graph is just google docs, won't let me make the bins any smaller with that many things to compare. I have a 1~1000 microsecond random delay after a long fixed delay. There are some long term synchronization artifacts, over the course of several seconds, but I think that's due to the difference beteen an 85fps frame cap and the 85hz refresh rate(DFC with triple buffering had a period of ~20 seconds.) Here's an example: Image

Edit: you were absolutely right, but now I'm confused by the earlier results. They weren't perfectly in synch, so why the 12ms thresholds? Why didn't it slowly ramp up then fall off a cliff, or vice versa.

Image

Post Reply