BenQ Zowie XL2411 vs RL2455 *vs* Dell U2414H

[t2k]

Hey guys, I'm trying to minimize input lag on my setup here, I've got a RetroUSB NES console (it's a reproduction NES with FPGA inside, HDMI output, etc - very slick) and two BenQ monitors.

I have both a RL2455 and XL2411 (both are Zowie's) and after trying a few different configurations of the single strobe settings on the XL2411, I'm disappointed to find that this monitor is no more responsive than the RL2455. To measure, I have a LED wired to the start button of my NES controller and film at 240fps.

Is this to be expected? Is there some configuration change I could make to the XL2411 to achieve less input lag than the RL2455?

I have blur reduction ON
via service mode I have single strobe ON, strobe duty 005, and I've tried strobe phase 000 and strobe phase 100

Thanks!

[lexlazootin]

Na, that's about right.

60hz is 60hz. If you did it on a PC and used 120hz you would notice a difference but you don't really get much of a difference from using a 120hz monitor on a 60hz source.

[t2k]

Is this because monitors buffer the entire frame of video before displaying it? Seems like this would only really be necessary if you were rescaling the input.. but even then I can imagine some clever ways of rescaling using a buffer much smaller than the entire frame. I wonder if I would have better luck going HDMI into an HDMI->LVDS converter with no buffer that directly drives the panel. HRM.

[lexlazootin]

The XL2411 is running at 60hz same as the RL2455 that's why you're not seeing any improvement in input latency.

Not really to do with scaling or anything of that sort.

[RealNC]

For reduced latency, you'd need to use an emulator on PC, and use a g-sync monitor at max refresh rate. This lowers input lag values that very often match or are lower than the input lag on the original hardware.

[t2k]

I don't think that 60hz output dictates that the minimum lag is 16ms. This should only be the case if the monitor actually buffers the entire frame before displaying any of it. HDMI transmits the image top to bottom and there's nothing inherent in the spec or in LCD panels that requires an entire frame be buffered prior to displaying it. I think I'm going to return these monitors and try the Dell U2414, which TFTCentral measured at 4ms lag (despite being a 60hz panel) - http://www.tftcentral.co.uk/reviews/dell_u2414h.htm#lag

[RealNC]

60Hz incurs a 16.7ms minimum latency when running with vsync. That "4ms" rating you see for the other monitor is measured with vsync off.

An NES (or any other retro console) will always run vsynced. It will not send the next frame to the monitor until the monitor has finished drawing the current frame, and on 60Hz, it needs 16.7ms to draw a frame. This is a very low latency, btw. 16.7ms is SUPER fast. If you're getting too much input lag that you can feel, it's probably the fault if your NES clone. It's probably doing buffering that an original NES wouldn't do?

[t2k]

"That "4ms" rating you see for the other monitor is measured with vsync off."

I did not see vsync mentioned anywhere in that review. I didn't read it start to finish but I did re-read the lag section and I searched for 'vsync' and 'sync' but neither appear on the page. If I'm just missing the part where that was discussed would you tell me where they've buried it?

As far as buffering in the NES clone itself, I've spoken with the developer of the clone and there is no substantial buffering (roughly 1 *line* of video). A standard NES+CRT (running at 60hz) has nowhere near 16ms of lag so the idea that 60hz must mean 16ms minimum lag is just not true. I've measured the input lag on a NES+CRT as low as a single 240hz frame (the lowest possible measurement w my camera). Modern double buffered gpu rendering with vsync on will have 16ms lag minimum, absolutely - but that's not what a NES does and not what the clone does either. The NES can and often does examine the controller state during vblank (when the CRT beam is temporarily off as it works it's way from the bottom of the screen back to the top), update the PPU and game state, and immediately begin drawing a frame that reflects the new controller state - much much less than 16ms after the controller state was changed.

[lexlazootin]

This only works on a CRT on analog signals or with like G-Sync/Freesync and V-Sync off. If you're not getting tearing it's getting buffered one way or another.

The TFT SMTT test with V-Sync off and compared to a CRT, not total latency.
http://www.tftcentral.co.uk/articles/input_lag.htm

[RealNC]

I did not see vsync mentioned anywhere in that review. I didn't read it start to finish but I did re-read the lag section and I searched for 'vsync' and 'sync' but neither appear on the page. If I'm just missing the part where that was discussed would you tell me where they've buried it?

Latency tests are always done with vsync off. Vsync ruins the measurement. It's really an implicit assumption and is not mentioned. It's like testing the top speed of a car. It's not mentioned that the speed limiter (if the car has one) is disabled. It goes without saying, otherwise the test doesn't make any sense.

Have you tried without strobing? Also, what resolution is the RetroUSB using? Maybe it's a combination of different factors that add up to the input lag you're seeing. Scaling lag on the RetroUSB + scaling lag on the monitor + strobbing lag? Just a random thought, not saying this is the reason for sure.