Blur Busters Forums

Good people of Blur Busters,

Recently I became very interested in input lag testing. As luck would have it, my camera can record video at 1000 FPS and I have a modded Microsoft Intellimouse 1.1a (USB port is overclocked to 1000 Hz via driver, of course) with a blue LED connected to the primary mouse button. I'd like to contribute to this community as much as I can so I'm looking for advice on the best way to do it. I'm basically trying to find out what the best way to test monitor input lag would be, with the gear that I own.

From everything I've learned here, what I can measure with my setup (high-speed camera + modded mouse) is button-to-pixel time. But what's the preferable way to do it? Here are my main two questions. Once we go over those, I'll probably have a couple more. Any and all input (pun!) is highly appreciated.

1. Would it be best to use a game like CS:GO, bind the primary mouse button to "look" and then measure the time it took from the LED turning on to any movement visible on the screen?

2. If #1 is correct, what should be my aim in terms of in-game framerate? Should I strive to make it equal to the maximum refresh rate of the monitor?

Thank you!

Halfwit wrote:Good people of Blur Busters,

Welcome to Blur Busters!

I'll let our resident recent lag tester, Jorim Tapley answer when he has a free moment!
However, briefly:

Halfwit wrote:1. Would it be best to use a game like CS:GO, bind the primary mouse button to "look" and then measure the time it took from the LED turning on to any movement visible on the screen?

If you want to amplify monitor reaction visibility, use a black-and-white level where you've got a black-vs-white vertical edge you can mouselook against. Custom CS:GO level, etc. Use maximum monitor brightness.

Halfwit wrote:2. If #1 is correct, what should be my aim in terms of in-game framerate? Should I strive to make it equal to the maximum refresh rate of the monitor?

Lag can vary based on frame rate and refresh rate, and method of syncing (VSYNC ON vs NVInspector vs RTSS vs in-game). If you're isolating to input lag of the monitor, then you want to use VSYNC ON then subtract the frame buffer lag (1 or 2 frames, depending on drivers' VSYNC ON implementation).

Isolating the lag chain: Measuring lag differentials between displays
Calibrate using a CRT to find out framebuffer and game engine lag, and your lag variance margin (min/avg/max). Remember, top edge will react sooner than bottom edge. (Unless refreshed in the dark and strobed all at once). If you're measuring lag at crosshairs, focus on the crosshairs area. If you're measuring first-screen-reaction, back the camera to view the whole screen. Make sure CS:GO vertical edge goes all the way from top to bottom. Remember, you must test with the same computer with the same graphics drivers and graphics card, if you're testing display differentials using the mouse technique.

It won't be directly comparable to Leo Bodnar numbers or SMTT numbers but it will isolate lag differentials between two monitors.

Also, we're inventing new lag tests, which can isolate different part of the chain, keep an eye on Blur Busters in the coming months (And 2018).

Wow, a reply from the man himself, I'm flattered It's great to be here, you have an awesome site and I absolutely love the whole initiative in general!

Chief Blur Buster wrote: If you want to amplify monitor reaction visibility, use a black-and-white level where you've got a black-vs-white vertical edge you can mouselook against. Custom CS:GO level, etc. Use maximum monitor brightness.

Got it, I'll try that. So you think testing input lag like that (by using a game and binding movement to a mouse button) would be the best idea? What I'm wondering is this - what if I just used Windows desktop, for example by having the mouse button switch from a 100% black full screen picture to a 100% white full screen picture in Irfanview? The way I see it, that way the frame rate and refresh rate would always be in perfect sync (and maxed out at 60, 144 or whatever FPS/Hz) and I wouldn't introduce game engine lag to the mix. Could I kindly ask you to comment on that? Perhaps I'm missing something

Chief Blur Buster wrote: Lag can vary based on frame rate and refresh rate, and method of syncing (VSYNC ON vs NVInspector vs RTSS vs in-game). If you're isolating to input lag of the monitor, then you want to use VSYNC ON then subtract the frame buffer lag (1 or 2 frames, depending on drivers' VSYNC ON implementation).

Should the V-Sync be set to On in the video driver, the game I'm running or both? How to know if the frame buffer lag equals to 1 or 2 frames? I'm switching between GeForce GTX 1080 and Radeon RX 580, depending on the monitor I have connected (G-Sync or FreeSync).

Thanks for your input, I really appreciate it!

Halfwit wrote:Got it, I'll try that. So you think testing input lag like that (by using a game and binding movement to a mouse button) would be the best idea? What I'm wondering is this - what if I just used Windows desktop, for example by having the mouse button switch from a 100% black full screen picture to a 100% white full screen picture in Irfanview? The way I see it, that way the frame rate and refresh rate would always be in perfect sync (and maxed out at 60, 144 or whatever FPS/Hz) and I wouldn't introduce game engine lag to the mix.

You could do that, but you have to remember you still have to account for the USB poll from the mouse (<1ms), and the click latency from the mouse itself, which can vary heavily from mouse to mouse, and is dependent on driver/firmware, physical trigger differences, etc. I'm afraid click latency is very difficult to gauge as is.

To be clear (correct me if I'm wrong on this Chief), the external LED bypasses both the USB poll and the click latency, but both are still recorded on-screen, reflecting in the final numbers.

For this reason (and many others), this is why different methods are usually used to measure display lag instead. Can I ask what monitors models you are testing for input lag?

The Microsoft mice have 12ms~ at 1000hz from my testing.

Yea, the LED bypasses the internals and will turn on as soon as you click

jorimt wrote: I'm afraid click latency is very difficult to gauge as is.

I know how to test that, but right now I only have the one mouse to test, so it's not really worth doing for me.

You need something that can act as USB host, and which exposes GPIO pins. A Raspberry Pi or Arduino Due would probably work. Then you wire the mouse button to the GPIO pins so the microcontroller can measure the press directly without any debouncing, and you plug the mouse into the microcontroller so that it receives the USB input. Then you compare the delay from one until the other.

With this method you're specifically measuring latency of the mouse firmware, plus USB polling.

Hm, yeah. Don't you have to compare one mouse against the other, and isn't it ultimately approximate at best, or is there really a way to get an exact/near exact number for the given mouse?

Only sources on this subject I have seen are:
http://www.overclock.net/t/1411332/mous ... arison/680
http://www.overclock.net/t/1607990/clic ... s-compiled

Not sure how reliable they are though.

jorimt wrote:Hm, yeah. Don't you have to compare one mouse against the other, and isn't it ultimately approximate at best, or is there really a way to get an exact/near exact number for the given mouse?

Only sources on this subject I have seen are:
http://www.overclock.net/t/1411332/mous ... arison/680
http://www.overclock.net/t/1607990/clic ... s-compiled

Not sure how reliable they are though.

There's only one mouse with the method I outlined, which you plug directly into the microcontroller. The main difference between this and smashing two mice together is that you eliminate the latency and uncertainty of the second mouse, but you also lose the mechanical aspect of latency.

Basically, the microcontroller measures the difference in time between the button is clicked and when that information makes it through the USB interface.

Ah, or something closer to this would probably be ideal:
http://www.gamersnexus.net/guides/2594- ... s-vs-wired

But to get directly back on Halfwit's topic, it is probably possible to isolate the approximate delay introduced by the monitor with the led/camera method. As I stated in my article, at 2000+ FPS in the CS:GO test map, my mouse and monitor effectively became the bottleneck for minimum measurements:



Thanks to the Gamers Nexus article, I know the Chroma's (the same mouse I used in my test) click latency is in the 9-12ms range, and TFTCentral reports around a 4.60 delay (different brand, same panel) for the 240Hz monitor I was using.

So if we look at that average 14ms at 2000+ FPS, knowing what we do, we can obviously see that the mouse was responsible for roughly 9ms of that, and the display around 5ms.

Again though, this isn't the best method to test for display lag, as I had to know the mouse lag, and eliminate the game lag (at insane framerates) first. I'm probably oversimplifying though, and there may be other aspects I'm not factoring in either.

Here's what I'm thinking. If I test the button-to-pixel response time with a mouse that falls within the standard click delay time (9-12 ms), then I'm still providing useful information to anyone who's wondering about the input lag of the monitor, as they will also use it with a mouse and experience the same click delay as I did during testing. So as long as I explain my method and exact measurements in great detail, the numbers I'll be getting are going to be useful to anyone who's reading them. I'd do 10 measurements and calculate an average, of course.

Am I right or am I missing something there?

Oh and thanks to everyone for your input so far, very useful!