Blur Busters Forums

If you can isolate the approximate delay of the monitor by eliminating the delay incurred by the testing method, mouse, and system, that number would apply to anyone with the same monitor; it wouldn't matter if they had a different system or mouse, as you already eliminated the differences that they would be seeing on their systems from differing components.

Again though, the number you generate is going to be approximate at best, and depending on what program you test with, and what sort of syncing methods you have applied, as the Chief already stated, you'll have to eliminate them from the totals as well.

Regarding sample size, there are multiple variables involved that will make every single sample a little different, from the USB poll (<1ms variation), mouse LED light response (<1ms variation), and camera capture (<1ms variation), to the system response itself. This is why it is best to do something like 4 sets of 10. E.g. click ten times, stop recording, repeat process four times, then add up and average out all the numbers by min/avg/max.

Getting back with some results. I listened to your suggestions and went with the following:

CS:GO - Map_Flood (custom map with white/black box)
144 Hz
G-Sync ON
V-Sync OFF
max_fps 0 (was getting ~2.000 FPS)
Modded Microsoft Intellimouse Explorer 1.1 @ 1000 Hz

Button-to-pixel response time was consistently sitting between 30 and 32 ms in each run (I did about 50 of them). I measured the time from the first glimpse of light on the LED to the first visible on-screen movement. I was recording the entire screen and mouse left click was bound to "Move Left".

Here's what I subtracted from that:

LED reaction time: 1 ms
Camera: 1 ms
USB polling rate: 1 ms
Mouse click latency (measured): 14-17 ms
TOTAL: 17-20 ms

WIth all of that in mind, it would appear that the monitor input lag is sitting between 10 and 15 ms.

Any thoughts on my process and results? As always, your input is greatly appreciated!

30-32ms of total latency seems a bit high to me, When i had the same setup but with a G302 i mesured about 10ms~ total.

I got around that result with V-Sync on. Try turning off G-Sync in the NVCP and using a native resolution with scaling disabled. I doubt it will help but it is awfully high.

https://docs.google.com/spreadsheets/d/ ... sp=sharing

https://docs.google.com/spreadsheets/d/ ... sp=sharing

if you wish to see my results, one of those is a mouse bump test and one was done with a led soldered to mouse.

I'll redo my tests tomorrow, I think I found a mistake in my procedure, related to the end-frame detection. I wasn't paying attention to the top of the screen, where a first glimpse of movement can be seen.

I'll post again tomorrow after I recheck and recalculate everything!

You want to test with G-SYNC disabled, V-SYNC disabled, and fps_max 0. Anything else is going to add delay, even G-SYNC, as it has to wait to start each frame scan at top of each scanout; you're not testing for differences in syncing methods, you're trying to get the frame to display as soon as possible to deduce monitor latency.

With G-SYNC/V-SYNC off and an uncapped framerate reaching 2000+, the frame scan can start anywhere on-screen and will show as a tearline, so be sure to look carefully for the first reaction, as it will be harder to spot/predict than synced due to what will look like random placement.

As for subtracting those numbers for final results, if you do enough separate runs and average the samples, it should mostly eliminate those variables without you having to manually remove them from the final numbers; that's what the multiple runs are for.

So to be clear:
LED, camera, USB poll = they randomly alternate anywhere between 0-1ms each (don't manually remove from final results)
Mouse click = 14-17ms (manually remove average of that range from final results)

Again, this won't be exact, but it will get you in the ballpark of the monitor's latency.

Once you have your new results, check TFTCentral; they may have reviewed your test monitor already, at which point you can see how closely your results line up with theirs.

LED reaction time: 1 ms
Camera: 1 ms
USB polling rate: 1 ms

Adding comments:

Instead of subtracting these numbers, it's best to mention these as simply error margin -- basically a USB poll may mean the result is only 200 microseconds old, or 800 microsecond old. So error margin is a 0ms-3ms range for all of the error factors adding up together. Given some of these factors are more like ~0ms-to-~1ms error jitter, rather than a constant 1ms error. that means you have error jittering of 0-3ms, rather than a constant average of +3ms from these factors. So instead of subtracting these numbers, simply document the possible error margins.

Also "first anywhere-on-screen reaction" versus "first center-of-screen reaction" can be both legitimate lag measurement methods, but they can also result in totally different results depending on monitor, refresh rate, sync settings, etc. Make sure you also document which reaction you are measuring until.

Fantastic advice from both of you, I'll take all of that into consideration before doing a fresh batch of measurements.

Any suggestions how to make the first movement a bit easier to spot? This is one of my video samples:

https://www.dropbox.com/s/gdx04srctzbdw ... 1.MOV?dl=0

Due to the low resolution @ 1200 FPS and the distance which I need to push the camera to in order to capture the whole screen, it's super hard to spot movement. Is there anything from your experience that could make it a bit easier?

Film vertically and just get the black/white strip and the led in the shot.

Wouldn't something like a 1ms polling rate add on average 0.5ms total if you took enough runs? I had a idea of latency testing with a 30fps camera and simply getting enough results to make a conclusion that was a accurate as a 1000fps camera just due to how averages work. Wouldn't that work?

Halfwit wrote:Fantastic advice from both of you, I'll take all of that into consideration before doing a fresh batch of measurements.

Any suggestions how to make the first movement a bit easier to spot? This is one of my video samples:

https://www.dropbox.com/s/gdx04srctzbdw ... 1.MOV?dl=0

Due to the low resolution @ 1200 FPS and the distance which I need to push the camera to in order to capture the whole screen, it's super hard to spot movement. Is there anything from your experience that could make it a bit easier?

Like lexlazootin said above, align the white/black separation like I did in the second example in my article vid (17 second mark):
http://www.blurbusters.com/wp-content/u ... op.mp4?_=1

You want to align the camera so it looks like a single vertical white/black separation that swipes horizontally across the screen on click. Start the white or black separation at the very left or right of the screen, then start sample capture.

This will make it way easier to spot first reaction.

Also make sure your mouse isn't moving when you click it. This threw off my results until I ultimately placed tape over the sensor.

It seems like reviewing the videos could be automated pretty easily. I wonder if there is any free software out there to do it. If there isn't it doesn't seem like it would be too hard to make.