Page 1 of 1

xl2540 input latency possible sync problem?

Posted: 16 Dec 2016, 20:52
by Trip
A recent interview by a dutch website called hardware.info reviewed the xl2540 and they tested it for input latency. https://nl.hardware.info/reviews/7148/9 ... n-inputlag.
They also experienced it had a bit higher input latency at the top part of the screen as other review sites like respawn.ninja have also mentioned. Is this due to hitting the limits of displayport and having all of the lanes working at maximum capacity. I can imagine that syncing the incoming data across the 4 lanes can become a problem at such high speeds. Would this issue be resolved if they would use the displayport 1.3/1.4 standard since these both feature higher speeds per lane and thus requires less time to sync.

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 06:47
by Q83Ia7ta
They have several "input lag" values :) at top, middle, bottom.
If you look at their "input lag (bottom)" graph you will notice all the monitors have 16ms minimum.
That values indicates that 60Hz is used for test.
There is such tool called Leo Bodnar Input Lag Tester. It uses HDMI and 60Hz and it's only good to measure input latency for TV and monitors for consoles :)
respawn.ninja used bad method to measure input lag.
I own XL2540, PG248Q, mouse with LED and 1200fps camera and will make input lag tests soon.

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 07:05
by Haste
Q83Ia7ta wrote: I own XL2540, PG248Q, mouse with LED and 1200fps camera and will make input lag tests soon.
Awesome! :)

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 09:02
by Trip
Q83Ia7ta wrote:If you look at their "input lag (bottom)" graph you will notice all the monitors have 16ms minimum.
That values indicates that 60Hz is used for test.
That means the monitor is running with a very high vertical blank region right? Since 17.3(bottom lag) - 10.1(top lag) = 7.2ms. So the scanrate of the display is around 1000/7.2 = 139hz. If they would display 60hz this way the input latency tests make sense. Kind of a shame I already assumed this monitor is sluggish in comparison to the competitors. But if there is next to no vertical blanking at 240hz it could be there is near 0ms latency at that refresh rate.

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 13:34
by Q83Ia7ta
Trip wrote:
Q83Ia7ta wrote:If you look at their "input lag (bottom)" graph you will notice all the monitors have 16ms minimum.
That values indicates that 60Hz is used for test.
That means the monitor is running with a very high vertical blank region right? Since 17.3(bottom lag) - 10.1(top lag) = 7.2ms. So the scanrate of the display is around 1000/7.2 = 139hz. If they would display 60hz this way the input latency tests make sense. Kind of a shame I already assumed this monitor is sluggish in comparison to the competitors. But if there is next to no vertical blanking at 240hz it could be there is near 0ms latency at that refresh rate.
It doesn't really matter how this monitor performs at 60Hz via HDMI because all will use 240Hz and DisplayPort.

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 14:17
by alex47
Q83Ia7ta where can I see your review?
do you have a website?

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 14:20
by Q83Ia7ta
alex47 wrote:Q83Ia7ta where can I see your review?
do you have a website?
Isn't ready. No website, i'm just a twitch FPS player and love monitors and had many of 144+ Hz.

Re: xl2540 input latency possible sync problem?

Posted: 17 Dec 2016, 14:55
by Trip
Q83Ia7ta wrote:It doesn't really matter how this monitor performs at 60Hz via HDMI because all will use 240Hz and DisplayPort.
Yes exactly but it would be a bit unfortunate for these high refresh monitors to be benched this way. Since it does not really represent their actual latency characteristics. At respawn they put both monitors at 144hz and they saw that the xl2540 was a frame behind on a lot of instances. But it could just have been the case that it also had a very high vertical blanking setting at 144hz and the actual display scans out at a rate of 240hz (4ms).

Re: xl2540 input latency possible sync problem?

Posted: 19 Dec 2016, 14:09
by Chief Blur Buster
Trip wrote:
Q83Ia7ta wrote:If you look at their "input lag (bottom)" graph you will notice all the monitors have 16ms minimum.
That values indicates that 60Hz is used for test.
That means the monitor is running with a very high vertical blank region right? Since 17.3(bottom lag) - 10.1(top lag) = 7.2ms. So the scanrate of the display is around 1000/7.2 = 139hz. If they would display 60hz this way the input latency tests make sense. Kind of a shame I already assumed this monitor is sluggish in comparison to the competitors. But if there is next to no vertical blanking at 240hz it could be there is near 0ms latency at that refresh rate.
Unverified by me.

But I have a theory:

It's possible that a specific panel/electronics/etc optimized for a specific refresh rate (240Hz) isn't easily able to be scanned slower, so to be able to refresh at 60Hz, it would partially buffer 60Hz and then do an accelerated scan-out (refreshing a 60Hz frame in say, 1/120sec or 1/144sec from top-to-bottom edge). So the lag would only appear when trying to use refresh rates slower than a panel's minimum scanout speed. Or it might be input-dependant (e.g. HDMI).

Another theory is it might also be refreshing the 60Hz frame twice too (two scans of 60Hz refresh cycle) for the clearest possible 60Hz refresh cycles. This still requires partial buffering at the beginning (top) because the end of scanout needs to coincide with the last pixel arriving on the video cable -- if you're scanning out to the screen faster than the display image is coming over the VGA/DVI/DP/HDMI cable.

Technically, TN panels (even 240Hz-capable) should be able to run 60Hz in real time, but for whatever reason an accelerated scan-out is used for individual 60Hz refresh cycles (whether as optimization, limitation, image quality, etc) if the top/bottom edge input lag differences are much smaller than expected.