KKNDT wrote:Chief, I have 2 question here:
1. Do you need to keep the 2 screen at the same HZ if you measure the lag using SMTT 2?
Yes, you have to with SMTT 2.0. You need perfect output mirroring. Exact same CRU timngs. Don't use adaptors, adaptors add lag.
To be very sure, swap the inputs, and measure again, make sure differential is still the same, so you don't have "input-related-differences" in input lag (e.g. DisplayPort has different input lag than HDMI)
SMTT 2.0 lag is much closer to "min-lag". It's 1000fps VSYNC OFF, so scanout lag is only 1/1000th what is normally is. So scanout lag is essentially removed from SMTT 2.0 results. That's why SMTT 2.0 numbers are more useful for VSYNC OFF game players than VSYNC ON game players.
KKNDT wrote:2. What does the result represent?/ What lag exact is SMTT 2 meant to measure?
I have read TFTCentral's
input lag article. In this article the developer of SMTT says "signal delay + input lag + response time + x". TFTCentral's input lag defination seems only contains signal processing and G2G. They never say something about the lag jitter caused by scanout cycle.
They certainly don't cover much in that aspect, BUT the SMTT 2.0 is very close to numbers that are important to CS:GO players that use VSYNC OFF which bypasses a lot of scanout lag.
KKNDT wrote:I have also read
RTINGS's article
RTINGS understand how scanout impacts the lag number, but their published numbers exclude the scanout factor, since the numbers are called "lowest input lag possible", is it right?
That's good for VSYNC OFF players.
Average scanout lag is half a refresh cycle.
(Framerate double refresh rate) = one-halved scanout lag lag factor in average lag number.
(Framerate quadruple refresh rate) = one-quarter scanout lag factor in average lag number
(Framerate eight times refresh rate) = one-eighth scanout lag factor in average lag number
So 480fps at 120Hz = one-quarter of one-half refresh cycle = one-eighth refresh cycle scanout lag graident error factor.
So the higher your video game framerate is above refresh rate, the less important scanout lag is to absolute lag.
These ultra-detailed lag analysis is extremely useful for smart interpretation:
VSYNC OFF Average equals Average = Scanout lag of framerate matching refresh rate.
VSYNC OFF Average equals Min = Scanout lag of infinite framerate VSYNC OFF
VSYNC OFF Average equals Between Min and Average = Scanout lag of finite framerates higher than refresh rate.
So it's
okay to exclude scanout lag when publishing lag numbers for the CS:GO eSports audience (e.g. VSYNC OFF lag numbers).
Since SMTT 2.0 is 1000fps VSYNC OFF, it output numbers almost equal to infinite-framerate VSYNC OFF, since for 1000fps VSYNC OFF scanout lag error margin is only 0.5ms for SMTT 2.0 Therefore, RTINGS Min roughly corresponds to SMTT 2.0 Min to the nearest millisecond, literally! There's a slight lag offset because of cable lag (e.g. HDMI vs DP vs etc -- 1-2ms differences), but the lag numbers will increase/decrease proportionally if both test techniques are done on the same display. Meaning numbers increase/decrease in exactly the same way, both sets of numbers being VSYNC-OFF-biased.
IMPORTANT: There is a distinction between scanout-waiting lag and scanout-lottery lag. VSYNC ON has a scanout-waiting effect, and VSYNC OFF has a scanout-lottery effect. This is because a page flip occuring randomly, will have a lag between (0...one refresh cycle) for any given random pixel on the screen, assuming a realtime scanout panel. It also depends on whether you're measuring a single pixel or first-anywhere-reaction.
Four Lag Metrics: Assuming realtime panel scanout: panel scanout fully in sync with signal input scanout
- VSYNC ON, monitoring a single pixel:
You have a scanout-random lag effect that increases towards the bottom of screen. There's a vertical lag gradient.
- VSYNC OFF, monitoring a single pixel:
You have a scanout-lottery lag effect, but you have no lag difference between top/bottom edges for realtime-scanout panels, when you do many runs and average the runs. Numbers will typically vary in a range that's equal to a whole refresh cycle, but the averages will settle. There's no vertical lag gradient at all, for synchronous-scanout panels.
- VSYNC ON, first-anywhere-reaction:
The top edge always reacts first, and almost always at a quite fixed interval.
- VSYNC OFF, first-anywhere-reaction:
Very consistent average numbers which becomes equal to MIN the closer you reach infinite framerate.
Disengaging from old-fashioned single-number lag readings (they're either only useful to VSYNC ON players or only useful to VSYNC OFF players.... console lag measurements are useless for eSports lag measurements, and vice-versa). Lag measuring methods inherently always has a "sync bias". Which means the numbers are either mainly useful to VSYNC ON players, or the numbers are mainly useful to VSYNC ON players.
TomsHardware: VSYNC ON bias
RTINGS: Both (graphs), VSYNC OFF bias (lowest number)
TFTCentral: VSYNC OFF bias
Prad.de: VSYNC ON bias
DisplayLag.com: VSYNC ON bias
Etc.
Leo Bodnar = VSYNC ON bias
SMTT 2.0 = VSYNC OFF bias
Etc.
Bias can be accidental (Because of test method). But no matter what lag measuring method anybody invents, there's always a sync bias. There's no way to have a single number that has both a VSYNC ON and a VSYNC OFF bias. Console eSports players should focus on the sites with the VSYNC ON bias in their lag numbers. CS:GO players should focus on the websites with the VSYNC OFF bias.
Pandora's Box. Lag measuring is an incredibly complex topic. It's horribly much more complicated than I thought two years ago, and I now understand why. It also even hugely explains many weird differences between websites. I have even gained the ability to mathematically convert lag numbers between all the different websites (and they correspond). It's like studying quantum mechanics and trying to get a Ph.D in quantum mechanics. It's tantamount to doing the same for input lag!
Few in the world understands all the lag variables concurrently and simultaneously well enough to figure out why the numbers between different websites are different, and know how to mathematically reproject the different websites' lag numbers to the other sites: They're actually very consistent with each other (even with huge lag-number differences) -- but compensating for the differences in lag stopwatching methods, the numbers of the different websites actually lines up since I finally discovered almost all the "major" variables (except for minor ones beyond control).
I can now actually create a math model (aka math formulas) that essentially clicks all the numbers of all the lag-testing websites into the same lag-testing Venn Diagram, even those numbers that are as much >15ms different between two different websites for the same monitor. It will take me until 2018-2019 but I plan to be publishing a "Input Lag Formula" standard -- kind of the input lag equivalent of a Unified Theory for particle physics. This is a breakthrough development. I'm considering looking for paper co-authors (e.g. to create a paper similar to
pursuit camera paper), please contact me for more information at mark[at]blurbusters.com since I believe what I have done is sufficiently breakthrough enough to be put into a paper. Researcher experience preferred (ResearchGate, etc).
In fact, what I have learned finally also explains why certain 144Hz and 165Hz panels is sometimes preferred by certain eSports players than certain 240Hz panels -- but not always. (This is unrelated to the ghosting differences -- that's a separate subject). Some players perform better on one, and different players perform better than the other. I think I know why but I need more testing time to exactly figure out why. If you are an eSports player who's confused about the 240Hz FUD but have an open mind to figuring out the scientifics, please email me, I would like to ask you more questions to help assist my testing.