<Concern about Inaccurate Lag Measurement Methodology>
RLCScontender wrote: ↑26 Jun 2020, 22:06
Perceived input lag (display lag)
1.27ms(half of my pixel g2g response time measurements) also known as response time element
0.01ms ACTUAL INPUT LAG(how snappy you feel when pressing a button relative to the game u are playing)(the moment you press a button, it should be instantaneous.
0.01ms signal processing lag.
Chief Blur Buster wrote: ↑27 Jun 2020, 14:12
Unless you misphrased accidentally or used the wrong phrase accidentally, that's mathematically impossible because "button to photons" latency is much bigger than "display lag + processing lag"
This is because "button to photons" (bigger number) is a superset that includes "display lag + processing lag" (smaller number). You can't do the latency equivalent of "2 + 2 = 1". Adding two positive numbers never creates a smaller number than the original number!
I have to uphold Blur Busters to the proper academic standards of latency disclosure, so please re-evaluate your latency measurements.
RLCSContender,
Still waiting for your reply.
I am currently concerned that you are quoting dishonest latency numbers since you haven't corrected your testing disclosure.
First. I agree with you here: The monitor is definitely ultra low latency (I agree) and deserve to be highlighted (I agree). It's an amazing specimen of a monitor!
However -- the world needs to see truthfully honest latency disclosure. When we're nitpicking over milliseconds, we need to see the proper truthful latency numbers here with proper margin disclosure.
The button get pressed by the human and has to go through ALL OF THAT before the pixels begins emitting photons.
So what you quoted was a "2 + 2 = 1" mistake, so I'm pretty concerned about your latency numbers.
That's because if you measure a narrower section, it's a lower lag, than a wider section. Human doing a button press -- all the way to display photon -- is already the widest part of the lag chain -- the full width of the image above. That number of pretty much always bigger.
Even that diagram is a huge simplification. It gets even more complex than that -- e.g.
scanout latency as seen in high speed video cameras.
Your lack of reply is telling. You haven't properly documented your lag stopwatch start location in this diagram, and your latency stopwatch end location in this diagram.
Latency is a very complex chain. It's easy to be accidentally dishonest about lag numbers, especially with the inaccuracy potentially found in the decimal digits.
Yes, yes, oscilloscopes are great, but there are millions of oscilloscope
touch points along the whole latency chain (including inside a computer & inside a monitor). You have not even properly disclosed your oscilloscope touch points, so we don't even know what your latency stopwatch start location is, nor where your latency stopwatch ending location is. And if you're using a VSYNC-monitor dongle, you haven't even disclosed that (the electronic circuit that listens to the display signal). Just saying "
Hey, I have an oscilloscope" doesn't necessarily mean truthful latency results:
You must also write University professor/teacher approved testing disclosures!. Users here expect that of you.
Yes, opinions are also
excellent too ("My opinion about the ACMETron 240 is that it's such an amazing monitor, I'm winning my CS:GO matches with it!"). And you can be popular with opinion alone too! This is fine.
But,
measured lag numbers are not opinion. You need to
attach proper testing disclosure -- and your testing disclosure is still woefully dishonest & incomplete.
The better monitors are definitely amazing. But you have to be careful about honest testing disclosure -- that's part of the truth needed in testing.
I hope you can understand!
If readers are to trust the latency numbers, one has to accept the truth & be honest about latency testing disclosure.
While you did have somewhat better disclosure than many sites, you left some very critical disclosure out, that I feel now needs to be filled because of these mathematically problematic numbers you just posted. Some numbers you quoted are currently mathematically impossible (because of simple issues that is nonsensical similiar to a "2 + 2 = 1" issue).
RLCSContender, I'm not targetting you in particular, or expressing ego things. Any professor (understanding the lag chain) would also agree with me that your disclosure is quite limited. I'm expressing genuine concern at the flawed information posted with some mathematical gotchas. A good university student is willing to listen to teachers.
It's possible that you accurately measured some lag numbers and messed up measuring other lag numbers. It's okay, people make mistakes. Everyone here just need to understand a better latency testing disclosure, to understand where you begin your latency stopwatch, and where you end your latency stopwatch. While this forum is small and niche, being the least popular Blur Busters website -- the main website get millions of views & TestUFO gets over ten million views annually.
Being a deaf man, born deaf, I'm a very text/math/logic/truth based person. I got a 99% grade (A+) in electronics class. I pay attention to forum posts very well. So I'm extremely interested in seeing accurate truthful latency numbers. Currently, you haven't disclosed the whole picture such as exact locations where the oscilloscope is attached (there are millions of locations in a latency chain, because of all those solder points all over a PC and monitor, if you're not using a VSYNC detector dongle). I hope you can appreciate this concern about truthful latency honesty.
That monitor is low lag. We agree. Lag is really low on the monitor. You can win a lot of scores. So that's a fairly honest opinion.
But the number (not an opinion) is somewhat dishonest. I have to disagree with the methodology non-disclosure occuring, given the unusually low "button-to-photons" numbers that is smaller than a smaller subset of the lag chain. A subset cannot ever be bigger than its original set!
</Concern about Inaccurate Lag Measurement Methodology>
