Measured 3007WFP-HC input lag precisely

[MetaGenie]

The measurements of input lag that have a "minimum, average and maximum" never made sense to me. The delay should not fluctuate at all, otherwise the refresh rate itself would have to fluctuate. I figured it was probably an artifact of using stopwatch displays instead of bars moving sideways.

I finally got around to testing my 3007WFP-HC. I used this tool: http://www.hardforum.com/showthread.php?t=1423433

And guess what, it has ZERO input lag, period. Bye bye, "11.5 ms average", it was nice knowing you. Bye bye "DS-305W is the fastest". It's likely the HP LP3065 and Doublesight DS-305W have zero lag as well, but it would be nice to see confirmation. It would be especially nice to see the LG W3000H tested like this, since it has a different panel.

I wanted to prove once and for all that the input lag does not fluctuate but in fact stays constant, so I filmed video instead of taking still photos. I used my video camera's 240Hz slow-rec mode, with my Dell 3007WFP-HC and Sony GDM-F500 side by side in clone mode, both at 2560x1600 (no scaling). The results are very interesting — they show that the LCD is already beginning to light up a region of the screen at the same time as the CRT fully lights it up. This is how an LCD should work! The manufacturer quoted response time of 12 ms seems to be very honest, agreeing with the time it takes for black to go to white and back to black (if you subtract the mandatory time it has to stay white, i.e. one frame).

I will be paying more attention to the "minimum" in those imperfect lag tests now. The "average" and "maximum" are probably not very meaningful.

Here is 1 second of the video, as a JPEG image sequence:
http://rapidshare.com/files/310594095/Input_lag_-_Dell_3007WFP-HC_versus_CRT.zip.html

Speaking of input lag, it really doesn't make any sense at all for a non-interlaced scaler to add any significant lag. I don't understand why pretty much every LCD with a scaler adds a frame or two of lag. They should be able to work with only a small number of rows buffered; no reason they should have to buffer a whole frame.

 

[obobski]

I don't think you've emperically "proven" anything, more supported a hypothesis
interesting results nonetheless

the reason you'll have min/avg/max is because, well, you're dealing with stats related to a measured rate

 

[Sailor_Moon]

Regarding input-lag you should consider this report:

http://www.prad.de/en/monitore/specials/inputlag/inputlag.html

Best regards

Denis

 

[MetaGenie]

the reason you'll have min/avg/max is because, well, you're dealing with stats related to a measured rate

Technically there is a min/avg/max in my measurements as well, but the difference between them is smaller than 1 millisecond. I did a perspective transform to individually restore the angled monitors to a rectangular shape, and measured the percentage height of the vertical bar fragments, and they agreed to within 0.2 ms. This might as well be zero. I could rewrite the rolling-bar program to add a vertical scale, and take still photos (much higher resolution than slow-rec video), in RAW format so that the gradations between black and white could be measured photometrically, but all I really wanted to know was whether the lag was significant compared to the length of a frame. The answer is no, it is not. Measuring sub-millisecond lag would not be very practical.

There is far more error in the stopwatch display + still photo technique, especially if there is only one stopwatch on-screen. You have to deal with faded numerals, some of which are more obvious than others, and the fact that the vertical phase at the time of each shot may be unknown.

Given the fact that my test shows less than 0.2 ms of lag, and the fact that I waited for the two monitors' vertical retrace to be in sync (see below), it's unlikely that there are any significant hidden lags.

Regarding input-lag you should consider this report:

http://www.prad.de/en/monitore/specials/inputlag/inputlag.html

That appears to be an excellent article, thanks for linking it. I skimmed it, and will read the whole thing later.

Left: Nearly, but too late: The analogue V-Sync signal of an FX5900 limps behind the digital signal by somewhat more than 1 ms. Right: When connected once more, the lag is almost 16 ms. Worst case!

I should note that in my test, the two clones did not have a perfectly matching vertical retrace rate. As a result, they went in and out of phase (very slowly). While out of phase, the LCD displayed tearing; this strongly suggests that the rolling-bar program's VSync was syncing to the CRT, not the LCD. However, I did my video while they were in perfect phase, while there was no tearing on either display (essentially, the tearing disappeared into the vertical blanking period), which eliminates this source of error. I'm pretty sure is the same lag as that described in the above quote, and in the conclusion of the article. It appears that the writers and contributers of that article never did a test based on moving vertical bars, which is a shame. If they had, it probably would have completely changed their conclusion. Having fully vertical bars march across the screen allows any difference in phase to show up as tearing, making it easy for the photo-taker to wait until the two displays match in phase before taking a measurement photo.

 

[ToastyX]

I've been saying that for a while. Lag doesn't vary. It's the testing methods that are flawed.

There are three main problems:

1. The timers commonly used aren't synchronized with the refresh rate and aren't guaranteed to update at any particular interval. There can also be tearing if the timer updates while the refresh is happening in that part of the screen.

2. Only one part of the screen is tested, so it's not possible to tell where each monitor is refreshing. Both CRT and LCD monitors refresh from top to bottom. If the CRT has just refreshed the part of the screen with the timer, the LCD might only be a couple of milliseconds behind, but the timer will show a one-frame difference at that point in time.

3. Clone mode isn't guaranteed to update both monitors at the same time. Using a splitter guarantees both monitors get the same signal at the same time.

It's possible to use a timer, but the timer must be synchronized with the refresh rate and displayed on multiple parts of the screen, and a splitter must be used. That's the method I've been using, and I always get consistent results that way. The vsynced vertical bars method is also good.

 

[MetaGenie]

ToastyX, I think the only reason clone mode isn't guaranteed to update both monitors at the same time is because the vertical refresh rates aren't guaranteed to be exactly the same, and are not guaranteed to be in perfect phase. If you can get the refresh rates close enough, and wait for them to drift into phase like I did, they should be updating at the same time. If done properly, no splitter should be required. (This would only work the with the vertical bars method though... it'd be hard to perceive tearing with stacked clocks.)

Are there splitters that can take one signal and split it into DVI and RGB analog? What about DVI dual-link?

 

[obobski]

ToastyX, I think the only reason clone mode isn't guaranteed to update both monitors at the same time is because the vertical refresh rates aren't guaranteed to be exactly the same, and are not guaranteed to be in perfect phase. If you can get the refresh rates close enough, and wait for them to drift into phase like I did, they should be updating at the same time. If done properly, no splitter should be required. (This would only work the with the vertical bars method though... it'd be hard to perceive tearing with stacked clocks.)

Are there splitters that can take one signal and split it into DVI and RGB analog? What about DVI dual-link?

if you had a graphics card with DMS-59 out, you can have a digital and analog signal at once, but it'd be the same as using two outputs from the video card

you can split VGA to 2x VGA, but can't perform D/A conversion on the splitter (you'd incur latency, at least more latency than using the VGA and DVI outs from the card)

basically you can't take digital AND analog from the same output at once (At least TMK)


basically if you want to test this further (and I do find your willingness to improve your methods awesome), I'd find a somewhat older graphics card with a VGA and DVI out (who cares if it can't game, we're just running some flashing bars on it ), and hook up a pair of CRTs or whatever, see if they "line up" (I'm not actually certain if clone mode does or doesn't sync up, I'd assume it does, but thats just based on eyeing it, if its off by a ms or two, it's unlikely to be noticed, but it'd influence your results)

I suggest this because the RAMDAC on the graphics card will handle the digital to analog faster than some external solution

 

[ToastyX]

ToastyX, I think the only reason clone mode isn't guaranteed to update both monitors at the same time is because the vertical refresh rates aren't guaranteed to be exactly the same, and are not guaranteed to be in perfect phase. If you can get the refresh rates close enough, and wait for them to drift into phase like I did, they should be updating at the same time.

If the signals happen to be the same, they still might not be output at the same time, and in that case, they would never drift into synchronization.

Are there splitters that can take one signal and split it into DVI and RGB analog? What about DVI dual-link?

A true splitter can only split the signal. It can't convert from one format to another. In the case of a 30" monitor without a VGA port, clone mode is the only way to test it against a CRT, in which case, your method is more sane than prad's.

A passive DVI splitter with all the pins should be able to handle dual-link DVI, but you'd only be able to use that to test against other LCD monitors.

Also, I've found sometimes the video card (or the driver) would get confused when two monitors are connected to one port with a splitter, probably because of two EDID signals conflicting with each other, so you might need a device like DVI Doctor between the splitter and the video card so the video card only receives EDID info from one source. DVI Doctor only supports single-link DVI though.

 

[obobski]

A true splitter can only split the signal. It can't convert from one format to another. In the case of a 30" monitor without a VGA port, clone mode is the only way to test it against a CRT, in which case, your method is more sane than prad's.

A passive DVI splitter with all the pins should be able to handle dual-link DVI, but you'd only be able to use that to test against other LCD monitors.

Also, I've found sometimes the video card (or the driver) would get confused when two monitors are connected to one port with a splitter, probably because of two EDID signals conflicting with each other, so you might need a device like DVI Doctor between the splitter and the video card so the video card only receives EDID info from one source. DVI Doctor only supports single-link DVI though.

the only two 30" monitors with VGA ports do not support 2560x1600 (Because VESA doesn't support it) and will scale the input which incurs input lag, they are also both incredibly expensive, and are both known to have considerable input (and panel) lag compared to the 3007

furthermore, DL doesn't matter here, you're trying to take a DVI-I signal and feed the DVI-D and DVI-A components at once, and TMK the driver/hardware won't let you do that without some custom hardware inbtwxt, which means lag (which sorta nulls the test, eh?)

 

[ToastyX]

I edited out the part about prad because I misunderstood what they were saying.

I see what they're trying to do. They're trying to update the timer in real time by updating the timer on all parts of the screen as fast as possible, so when the refresh hits the next timer, it will have the latest value. That way, it doesn't matter if clone mode doesn't update each monitor at the same time. You just need the latest number from both monitors to determine the lag. In that case, you don't want vsync, or all the numbers would be the same.

That's actually a good idea, but the way they implemented it makes it hard to determine what the latest number is on the LCD. The numbers on the LCD are jumbled together and prone to tearing, making it hard to see what's going on.

I think this method can be improved, but I still think using a splitter with vsync is a better option when possible.

 

[MetaGenie]

I think any method using timers is fundamentally flawed because the numbers can fade together, and certain numeral fading combinations are harder to reliably make sense of than others.

What's wrong with the vertical bars method? If the input lag is large, just increase the number of bars. Perhaps the problem is that it requires the reviewer to understand exactly what is going on, so they can verify that vsync is working properly, that the vertical refresh of the two monitors is in phase, and that they know what the refresh rate is. Maybe drawing a timer (or set of timers) inside each vertical bar would help with that. With a set of timers inside one vertical bar, each one going down could add the proper increment (fraction of the vertical refresh period) to itself.