280Hz: vsync + gsync gives 260fps lock?

[jorimt]

I wish I remember what I was truly thinking that day I asked you, sorry for the terrible outlining. Ugh, really wish I could remember

No worries. If you ever recall the specifics, feel free to PM me.

I just hate the fact that we cannot use it at all for conclusive testing because there's no proper software or CSV file or anything like that. It's just an average over 20 samples and you can't even save each sample point. It's ridiculously poor. I wonder if the LDAT software would work with the RLA monitor, no idea where to find that, if public at all.

I don't know if the LDAT software would work with an RLA monitor, but said software does allow recording of the results to .csv files.

There is a public link to download the software, but you have to first sign up for the Nvidia Developer Program. I'll PM you a link to the download, which will prompt you to sign up.

As I said, the thinking was more in the line of; are there different variations and lag numbers of implementations that are on a surface level the same thing. I have an odd feeling they trigger different implementations and methods.

Anything is possible, but I have tested some of those types of combos before, and they've just triggered the same few flags no matter what.

Not referring to you in the least here, but I have observed that for those just beginning to explore (or publicly discuss) this subject, they tend to complicate all the things that are simple, and simplify all the things that are complicated. E.g. they discount all that is known, and start on it again (as if it needs to be), instead of focusing on the things that actually need to be moved on to, etc.

Anyway, in my experience, from the user-side, if you take almost any game, ensure GPU-limitation and refresh rate-maxed V-SYNC behavior is avoided, you've got your lowest possible in-game adjustable average input lag levels right there, the end.

The rest is down to the less formally explored aspects of adjustments that quickly become more and more inaccessible to the average end user (either be it by disinterest, incapability, or a mix of both), such as OS/BIOS tweaks, overclocks, and to a less controllable degree, the given brand and combo of system components, debounce and signal delay of input devices, processing delay of monitor, ISP (for online games), electrical performance quality of the given location (aka the ever debated EMI argument), etc.

Also, I think a lot of users here and elsewhere sometimes conflate average input lag with overall frametime/latency consistency, which is not something that highspeed or photodiode testing is necessarily suited for (nor is it ever really the goal with that form of testing, at least for me).

(side-note, the newest RTSS implemented a new framerate limiting method that is a lot more similar to how Special K does their limiting, you'll find it on the newest msi afterburner beta released in the thread on guru 3d, as the new rtss version is bundled in there. It's called front-edge sync.

Thanks, I'll note that down and check it out when I get the chance.

[diakou]

Not referring to you in the least here, but I have observed that for those just beginning to explore (or publicly discuss) this subject, they tend to complicate all the things that are simple, and simplify all the things that are complicated. E.g. they discount all that is known, and start on it again (as if it needs to be), instead of focusing on the things that actually need to be moved on to, etc.

I don't disagree - I'm personally more interested in reassurance of consistent behavior if it's not properly documented however, especially when there's 40 Windows versions, with X driver updates and Y game optimization choices. There's much to find elsewhere, but sometimes I find more beauty in revisiting the basics rather than going neck-deep into EMI land and staying there for too long. I think the approach of discounting is silly as well, we should always just be using anything as more datapoints to leap off from. It is, to an extent, simple science approach.

(some capframex results with what RTSS' framerate limiter looks like for a game like Brawlhalla, very short 30 sec gameplay aggregations) though side-note, it doesn't feel too good to play, but I'd imagine it feels very good in a story-driven game. Can't comment on competitive aspect as a few friends have noted it feels ever so slightly slower/worse from an absolute latency standpoint.)





Front-Edge Sync frametime zoom;


Front-Edge Sync software input-lag approx;

[jorimt]

I don't disagree - I'm personally more interested in reassurance of consistent behavior if it's not properly documented however, especially when there's 40 Windows versions, with X driver updates and Y game optimization choices. There's much to find elsewhere, but sometimes I find more beauty in revisiting the basics rather than going neck-deep into EMI land and staying there for too long.

I'm not specifically referring to EMI, I'm more referring to the continual retreading of input lag measurement based off of syncing methods, framerate limiters, the render queue, or even frametime, where more nuanced, non-game-level "tweaks" are made and compared against.

The issue with attempting to measure frametimes with such programs for input lag consistency, is that's not what they're actually measuring; frametimes can be reported as 100% consistent, and you may still have better/worse variable input delay that goes completely undetected, as the data baked into each rendered frame has already been executed before render.

It gets a little more complicated with no sync scenarios, especially when you throw multiple tear slices into the mix, but let's say you test in a controlled scenario where you make the start of the frame scan appear at the same point in the scanout each time, such as FPS-limited G-SYNC + V-SYNC, where now, each frame is being delivered from top to bottom completely, and the only thing that will differ, assuming the desired framerate can't be maintained 100%, is the frametime of the given frame; you now have a neutral base to test non-sync settings, and thus, if a given setting increases/decreases input lag, it should ultimately show up in the average in 1 or more frame increments.

And there's your main problem for attempting to test latency consistency across a continuous period of frames; all the input data is baked into a single frame at a time, which means you're only getting a new update once per scanout cycle in synced scenarios, or once per frame scan in non-synced scenarios, regardless of refresh rate, regardless of framerate, regardless of everything, as that's just how frame delivery currently works.

As I said, highspeed and photodiode testing can detect the point of display reaction to user input in a given frame and, after a number of samples, log the min/avg/max data, but said methods aren't terribly practical for charting out the distribution of that data across each and every frame, whereas programs such as capframex or setups such as FCAT can measure frametime across a set period, but can't fully differentiate or easily extract the actual data for where each point of randomized user input is actually registered.

In other words, there has yet to be a testing method that can easily, accurately, and continually record the registered randomized user input across individually rendered frame scans and aggregate that into a plottable chart, and that's what people are asking for when they get into the more OCD testing that would require such a method to determine if there are actually sub-ms-level distributional improvements to latency consistency across a period of frames with such tweaking.

[TTT]

Nvidia Reflex caps your monitor when you are using Gsync, theres no way to stop it apart from not using Reflex or not fully implementing Gsync by turning Vsync off.