[PCM2]

We were recently contacted by Raymond Wang via our YouTube channel (see pinned post on our LG 34GK950F video review) who has developed a novel method of input lag assessment using basic equipment which many users will have at home. His tool, appropriately named Display Input Lag Tester (download here via Google Drive) allows users to have an LED of choice on their keyboard (num lock, caps lock or scroll lock) light up when they click their mouse button. They can then use a high speed camera (such as the ‘slow motion’ recording feature found on some modern Smartphones) to calculate the time delay between the mouse button being clicked and the screen reacting to this input. In other words, it gives users an indication of the input lag of their display. This can be calculated if the video is reviewed or edited using software that allows the user to see individual frames of the video, which includes the player integrated into Windows 10.

The principle is essentially similar to signal generator based input lag assessment tools, Leo Bodnar’s device being the best known iteration of that. These tools would require specific investment by the user for something that would have no other use to them. Furthermore, they’re usually inflexible in terms of the assessment conditions (e.g. a specific test program run at a certain refresh rate and resolution). This sort of ‘self-contained’ test has some advantages over methods such as SMTT 2.0 or the less reliable ‘stop watch and camera’ method, in particular that it doesn’t require multiple screens to be set up in clone mode. The Display Input Lag Tester tool is not only self-contained, it does not restrict the user in terms of the testing environment. They could run the monitor at any refresh rate it supports, any frame rate and in any specific application. This sort of flexibility is very welcome, so we took the tool for a spin to see whether it could provide reliable measurements that were at all comparable to something like SMTT 2.0.

Our initial testing using a Dell S2719DGF and this tool has been very promising indeed. Using a Samsung Galaxy Note 9 with 960 fps slow motion video capture and a Rocat Arvo gaming keyboard (low latency, caps lock LED lights up with very little delay), we found the tool did indeed offer useful data and if used in an appropriate way provided strikingly similar results to SMTT 2.0. The video below shows three separate tests, which are explained below the video.

The first test has the monitor running at 155Hz with the monitor running Microsoft Paint fullscreen such that a left click closes this view and returns to the application. The delay between the keyboard’s caps lock LED first lighting up (‘zero point’) and the monitor first exhibiting a change on the screen was calculated. This method of assessment minimises the impact of the response time element of input lag (‘element you see’) and gives a better indication of signal delay (‘element you feel’) which is really what most users are interested in when it comes to input lag. Bear in mind that monitors typically refresh from top to bottom and you’re able to see (more or less) when the monitor first starts reacting to the input without having to wait for lower regions of the screen to refresh or the pixel response itself to complete in its entirity. This video just shows one run of the test, but repeating it several times and averaging is advisable. After 10 repeats ~3ms of input lag was calculated which is surprisingly close to what we calculated using SMTT 2.0, with minimal variation between each run. The second test shows the same thing, with the monitor set to 60Hz. ~8ms of input lag was calculated (averaged over 10 runs) which was again consistent with our findings on SMTT 2.0.

The third test is a particularly interesting one as it uses an in-game example. Specifically, Battlefield V run in single player with the monitor set to 155Hz and the frame rate limited to 144Hz. FreeSync is enabled on the monitor. It’s actually connected to an Nvidia GPU and using Adaptive-Sync or ‘G-SYNC compatible’ mode, which is actively being engaged due to the frame rate being below the static refresh rate set (155Hz selected, game running at 144fps, monitor running at 144fps with Adaptive-Sync). The time between the LED first lighting up and the weapon showing signs of life, which in this case includes a huge decal on the wall directly in front of the weapon, was calculated as ~15ms average over 10 runs. Note that this can’t be directly compared to the earlier tests as you’re assessing the centre of the screen, are running a game and subjectively assessing what you believe is the start of a series of animations. However; you can cross-compare by testing using the in-game method and changing specific conditions. For example having Adaptive-Sync (e.g. FreeSync) active vs. the game running with Adaptive-Sync off. You can then establish the input lag penalty of activating FreeSync on the monitor.

[Glenwing]

Please note that my own test results with this method are not encouraging in terms of accuracy. Even if it was accurate for you, it still means the accuracy can vary quite a lot, and is not really a reliable method, especially if different people start testing their monitors and comparing results with other people using other keyboards and mice. I think this is something that should be made clear to readers before this gets out of hand.

https://www.reddit.com/r/Monitors/comments/aksv86/app_win3264_display_input_lag_tester_no_extra/ef8j5ev?utm_source=reddit-android

[PCM2]

Yes, that’s a very good point to raise. It certainly does depend on the equipment used and some keyboards will indeed have significant latency before the LED lights up. Out of interest, what keyboard were you using?

Users need to be aware that it can give them a relative indication of input lag rather than an absolute value. It can still help them compare different screens and different test conditions (VRR enabled vs. disabled) etc. as long as the equipment and other conditions remain the same. If a user does want a better idea of actual input lag, it’s best if they are able to use a monitor of known latency (measured by a reliable source using a generally accepted method – such as a model we’ve reviewed) and use that as a baseline. They’ll then be able to offset their readings appropriately if measuring other screens.

[Glenwing]

I’m using a Logitech G110 keyboard. The lag tester I built was from a cheap mouse (Nexus SM-8500B), probably 250 Hz, I’m not sure. Can’t test the polling rate since motion tracking broke (which is why I disassembled and experimented on it to build my lag tester :3). So it’s not the most accurate stuff, but neither will some other people’s, so it’s important for users to be aware that the accuracy can vary significantly when using this method.

[AndyK]

Hi,

I have seen quite a few monitor review sites state that they use SMTT 2.0 to test for input lag (also quite recently – as in 2019).

However, I can’t find the software anywhere: when searching it links to smtt.thomasthiemann.com which is down.

Can anyone help with a working link?

thanks in advance.

[PCM2]

I can confirm SMTT 2.0 has been used even more recently, in 2020. By ourselves and TFT Central for example. It isn’t available to download and hasn’t been accepting public downloads or licensing for quite some time now. An alternative which I’d encourage users to try out is covered in this thread (which I’ve merged yours with).

[Author]

Posts