Page 2 of 4
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 01 Feb 2022, 03:19
by MatrixQW
Chief Blur Buster wrote: ↑30 Jan 2022, 20:45
This is a very good test that pushes the extremes of esports performance differences with milliseconds — it also can vary whether or not you keep a fixed gaze or use eye-tracking. Sometimes the way your eyes behaves, can mean you easily pick up 5ms differences, while you’re unable to pick up 20ms differences.
I have to use eye-tracking. A fixed gaze the line tears apart.
In this sense, eye-tracking in games should be more beneficial.
teo wrote: ↑31 Jan 2022, 22:20
let's pretend that 8ms is the lowest latency where I can hit 13/16.
a) would we also expect that I would only be able to distinguish differences of 8ms or greater?
b) that is, would I perceive a 20ms delay as slower than a 15ms, or would they feel the same?
c) could I always pick out 30ms as better than 40ms, or 100ms as better than 110 or 120ms?
it might be a cool feature to let the user assign a baseline latency penalty for both A/B in addition to the discrepancy.
I modified your quote for better readability.
a) I assume that is the case.
b) You would notice a delay with 20 and 15 but you wouldn't be able to know wich is wich.
c) Yes because the threshold is 8+, considering a).
You can ask
Ashun to implement that feature.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 03 Feb 2022, 21:35
by Arbybear
Neat tool! I can get 100% at 15ms without too much practice on a 240hz monitor with a 2000hz mouse.
Some things I noticed:
1. There is an issue with feathering where if you move the mouse slowly pixel by pixel, the line will change thickness.
2. With the Razer Viper 8K, each step up in frequency proportionally decreases sensitivity. So 2000hz = 1/2 sens, 8000hz = 1/8 sens.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 07 Jun 2022, 19:09
by tetsuo
Sorry to frankenstein an old thread. I just like to add something: In these and similar discussions about the limits of perceivability (whether it be additional frames, hertz, or less input/system/processing/display lag) the argument often raised that there is no point to tweak/upgrade beyond perceptibility. In other words: if I can't see it, I don't need it. I'm not implying saying that most here think like that, but what perhaps many readers/lurkers forget is that "lack of subjective perceptibility" does not equal "lack of objective in-game advantage".
While in any given moment you are indeed unable that your game is rendered X milliseconds snappier, averaging say 1000 game results in an A/B test would still definitely show an objective edge just by the fact that all opponent action *objectively* will reach your eyes X milliseconds sooner, thereby giving you the opportunity to react X milliseconds sooner than you otherwise could. This is why competitive gamers will keep buying faster hardware even though they know they couldnt pass a blind test challenging them to subjectively tell apart their new hardware from their previous hardware.
Or take a sprinting athlete for better illustration: When crossing the finishing line he can't know *subjectively* whether he has broken his personal record, until he watches the scoreboard. Suddenly those imperceptible few milliseconds make a world of difference, and particularly so if you are up against opponents who likewise have optimized everything to the last detail. A professional athlete would never reject new shoes that are able to shave off another 0.05 seconds. He is ok with the fact that, to him, this difference is only detectable when averaged over hundreds of sprints.
Or put another way: When crossing beyond one's individual subjective imperceptibility threshold one enters pay-to-win territory. Each optimization has diminishing returns so you are looking to add as many such insignificant-on-their-own tweaks as possible in the hopes that in-aggregate it all reaches significance again.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 11 Jun 2022, 10:21
by Zenden
Nice test, enjoyed it.
Using a VG259QM monitor at 240Hz OD 120 (currently using an old GPU that doesn't support 280Hz) and a G305 1000Hz (3200dpi 0.25sens). Might try more later and edit this out with the results, my arm started getting tired and at 5ms it took a while between each try.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 14 Jun 2022, 17:13
by Chief Blur Buster
This split test is a very interesting latency-differential perception test. I would still like people to keep bumping up this thread with their own personal results.
The statistical spread between people able to see 1ms-5ms differentials, versus people who needs bigger (15+ms), would be interesting to explain from both an equipment-based perspective as well as human-based perspective.
A higher refresh rate presumably makes this test easier to tell at smaller differentials, as seeing subtle refresh cycle differentials is definitely easier for me at 360 Hz than at 60 Hz.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 14 Jun 2022, 23:53
by Boop
Ashun (LST creator) posted a video about this tool on his YouTube channel a few days ago:
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 17 Jun 2022, 07:53
by Sirito

This is mine but strangely at same latency test I felt like there were easy ones to determine and harder ones (at same latency)
I don't know if my pc is changing it's input latency randomly or what
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 20 Jul 2022, 21:17
by daniloberserk
Just sharing. I made a SINGLE test for my old 240Hz (LG 27GK750F) display, and I made another today after I updated it to a 360Hz display (Ozone DSP25 Ultra)
For the Ozone, I only did the 5ms test, where I was quite "bad" at. I certainly improved and probably can do better after some more runs. But I guess the best "test" will be the very first one for each value. So I can't just try hundreds of times 'til I have an incredible score.

- test.png (102.81 KiB) Viewed 11502 times
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 22 Jul 2022, 17:52
by DPRTMELR
Results on this test is in line with how I felt when adding audio delays back in the day(long story). 20 is definetely noticeable, 5~10 while it looks like nothings wrong, you can feel like somethings off from the baseline. Similar to this test , for 10ms differences I am relying on my mouse feeling funny instead of delays in visuals really. So I think most people can "recognize" at least the 5~10 ms difference if they wiggle their mouse around long enough and be really focused on it. ie get us a ranking ladder for this stuff and you will see some crazy people rolling in lol.
Should you be worried about 1, 5, or 10 ms of input lag?
I feel like there's this aspect of you who are unconsciously annoyed by the minor difference and the other more real you who's making the decision to do the actual clicking that is worrying about more pressing issues. But even if I can't tell the difference for 1~10ms being 10ms ahead means that's 10ms slower reaction from my end that can be covered with capitalism D: so I think answer still remains yes.
Is 1000fps supposed to be actually locked tight on 1000fps? I see it fluctuating within a single digit is that a problem? happens on lowest rendering as well.
Re: Should you be worried about 1, 5, or 10 ms of input lag? Use Latency Split Test (LST) and find out!
Posted: 23 Jul 2022, 20:15
by Vocaleyes
This is speaking from a personal standpoint. I attempted the test but at sub 5ms timings, it is redundant due to the input issue plaguing countless others and myself.
I would be extremely excited to attempt this test once it's possible to determine the difference between the input inconsistency issue and input delay.. which currently is indiscernible.
So as it currently stands, the outcome is irrelevant.