<The Blur Busters Input Lag Pandora Box>
MatrixQW wrote:Just saw a review from Prad.de with XG240R, wich is basically the same monitor as XG2402.
Prad: input lag 3.6ms.
RTINGS: input lag 4.1ms.
PCMonitors: input lag 3.16ms.
Not bad, excellent tight <1ms error band. The test methodologies are finally getting better and more in-sync.
In addition to other error factors, the differences can also be attributed to how the stopwatch is stopped; e.g. GtG10% or GtG50% or GtG90%.
Check out
Understanding Display Scan-Out Lag With High Speed Video and you will understand how difficult it is to decide the lag stopwatching start/stop protocol.
hkngo007 wrote:Leo Bodnar = VYSNC ON bias = test at 60hz with VSYNC on?
Correct.
Leo Bodnar = 60fps @ 60Hz VSYNC ON lag tester
SMTT 2.0 = 1000fps VSYNC OFF lag tester
RTINGS = In-house VSYNC OFF lag tester
Console eSports favours VSYNC ON lag testers, and PC eSports favours VSYNC OFF lag testers. The button-to-photons are different for eyeballs, and consequently, because of that, the lag stopwatch parameters have to operate differently for VSYNC OFF versus for VSYNC ON. This is because not all pixels refresh at the same time (
high speed video) and VSYNC OFF can interrupt the scanout, making sub-refresh latencies possible for bottom screen edge during VSYNC OFF -- something impossible with VSYNC ON).
hkngo007 wrote:You have said that Prad.de is a good source of input lag (along with Rtings ~ which is good). Unless something's changed with Prad.de's test methodology
I'm not sure yet, I emailed them several months ago informing them that their test methodology needs to be improved. If I am now seeing prad.de numbers more similar to RTINGS for eSports tests, then hopefully they sync'd up the methodology a bit. That said, I already know prad.de methodology is still superior to the 60Hz Leo Bodnar VSYNC ON test for PC eSports use.
MatrixQW wrote:They use SMTT 2.0, so they must be using some additional settings because their review of XG2401 also shows extreme low input lag of 3.38ms.
Properly set up, SMTT 2.0 is still a legitimate VSYNC OFF lag tester. The problem is we're hitting the error margin limitations of camera shutter speed, camera sensor rolling scan, and human-eye interpretation. That said, if you tightly control all the parameters, the error margin of an SMTT 2.0 number can be roughly 1 millisecond. So the second decimal digit is mostly useless (e.g. 2.3
8ms) while the digit right before the decimal point can be very accurate.
Minimizing error margin in SMTT 2.0 requires (A) Very fast global-shutter camera sensor, (B) Very fast shutter speed, (C) maximum framerate (1000fps is only enough for 1ms error margin), (D) deciding where to interpret GtG. The bottom part of the fuzzyband (old refresh) can correspond to roughly ~GtG10% and the top part of the fuzzyband (new refresh) can correspond to roughly ~GtG90%. Two numbers exactly superimposed on top of each other = GtG50%.
I consider GtG10% or GtG50% the preferred standard, because
(A) It corresponds to the start of the stadardized GtG response time numbers, which measures from 10% thru 90%;
(B) by GtG10% a pixel has changed enough to have human visible photons to start human reaction time clocks,
(C) reaction time clocks of a human starts far beyond GtG0% but well before GtG100%.
So lag testing methodologies that trigger too early (e.g. GtG2%) and too late (e.g. GtG100%) are pretty much SOL for accuracy from a human realistic reaction time trigger perspective. GtG10% means a dark grey during a pixel transition from black->white.
In programmerspeak, PhotoShop-speak, and HTML-developerspeak -- it is like RGB(25,25,25) in a pixel transition from RGB(0,0,0) -> RGB(255,255,255) ...(non-gamma corrected simplified example).
Want to see GtG0% fading to GtG100% in realtime? See
High Speed Videos.
There you go. Lag pandora box now being closed, please wait [0%---|---------------------100%]
</The Blur Busters Input Lag Pandora Box>