Click Latencies compiled - Page 55 - Overclock.net - An Overclocking Community

Forum Jump: 

Click Latencies compiled

Reply
 
Thread Tools
post #541 of 568 (permalink) Old 07-31-2020, 10:56 AM
Not new to Overclock.net
 
dontspamme's Avatar
 
Join Date: Sep 2012
Posts: 579
Rep: 12 (Unique: 9)
How come we aren't seeing test results from the new Razer mice?

Is it because of the new optical switches (they can't be tested for some reason)?

dontspamme is offline  
Sponsored Links
Advertisement
 
post #542 of 568 (permalink) Old 07-31-2020, 11:25 AM
AAGGHH~ MY EYES~ AAGGHH~
 
uaokkkkkkkk's Avatar
 
Join Date: Sep 2014
Posts: 3,559
Rep: 157 (Unique: 67)
Quote: Originally Posted by dontspamme View Post
Is it because of the new optical switches (they can't be tested for some reason)?
They'd just wire up the other switches on the pcb if that were an issue.
uaokkkkkkkk is offline  
post #543 of 568 (permalink) Old 08-01-2020, 08:22 AM
New to Overclock.net
 
Join Date: Jul 2020
Posts: 2
Rep: 0
Trust GXT 180 Kusan +5.6ms (4.2 ms slower than the Apollo)

Bloody V5m +1.25ms (0.15ms faster than Apollo in 200 rounds, you decide whether that's 1.3 or 1.2)

Last edited by Meat; 08-01-2020 at 08:45 AM.
Meat is offline  
Sponsored Links
Advertisement
 
post #544 of 568 (permalink) Old 08-01-2020, 01:24 PM
New to Overclock.net
 
Gonzalez07's Avatar
 
Join Date: May 2015
Posts: 329
Rep: 7 (Unique: 7)
no info on the xm1?
Gonzalez07 is offline  
post #545 of 568 (permalink) Old 08-02-2020, 12:45 PM
Mouse addict
 
cdcd's Avatar
 
Join Date: Jan 2017
Posts: 719
Rep: 33 (Unique: 23)
Zephyr Gaming Mouse: +6.7 ms relative to SteelSeries Ikari

Mice currently owned: Logitech G402/G403/G303/G Pro, Zowie FK1/EC2-A/EC2-B/ZA12, Razer Deathadder 2013/Basilisk, Cooler Master Mastermouse S/MM530/MM520, Roccat Kone Pure Owl-Eye, Dream Machines DM1 Pro S/FPS/DM3 mini, EVGA Torq X3/X5, Ninox Venator, HP Omen 600, Thermaltake Ventus X RGB Optical/Ventus R, Microsoft WMO, Steelseries Rival 310, Nixeus Revel, Ozone Neon M50

Looking to buy and try: Ninox Astrum
cdcd is offline  
post #546 of 568 (permalink) Old 08-05-2020, 03:01 AM
New to Overclock.net
 
Join Date: Jan 2020
Posts: 15
Rep: 0
Quote: Originally Posted by cdcd View Post
Non sequitur. By the way, I've already explained this to you before, so not sure why you're bringing up something already refuted.
You either didn't read or understand.


If you push down the button of a reference mouse and of the test mouse at the same instant, such that their buttons are pushed down at the same time, then you can measure the relative latency between mouse down events. This is fine.


BUT.
Explain this to me: This methodology should work for ANY mouse with a pressable button, regardless of the internal implementation.
But TPU wrote this: "This time around, I couldn't measure the click latency because the mouse has a rather unique analog method for switch registration. This means I cannot use my standard testing methods as they respond with a lot of 0.0 ms values, which is obviously false."


So TPU is doing something completely wrong or measuring something else (see my earlier posts).

And since proper measurement numbers seem to be shared/mixed with TPU's in this thread, the validity of the data is not given.
xnoreq is offline  
post #547 of 568 (permalink) Old 08-05-2020, 04:52 AM
Mouse addict
 
cdcd's Avatar
 
Join Date: Jan 2017
Posts: 719
Rep: 33 (Unique: 23)
Quote: Originally Posted by xnoreq View Post
You either didn't read or understand.


If you push down the button of a reference mouse and of the test mouse at the same instant, such that their buttons are pushed down at the same time, then you can measure the relative latency between mouse down events. This is fine.


BUT.
Explain this to me: This methodology should work for ANY mouse with a pressable button, regardless of the internal implementation.
But TPU wrote this: "This time around, I couldn't measure the click latency because the mouse has a rather unique analog method for switch registration. This means I cannot use my standard testing methods as they respond with a lot of 0.0 ms values, which is obviously false."


So TPU is doing something completely wrong or measuring something else (see my earlier posts).

And since proper measurement numbers seem to be shared/mixed with TPU's in this thread, the validity of the data is not given.
For mechanical switches, any click latency (button-down) will come from any debounce delay. The XM1 buttons are not debounced (at least not in the traditional way), hence it is not possible to measure click latency that way. So it's exactly the opposite of what you inferred: TPU testing methodology would be fundamentally flawed if it were possible to measure click latency on the XM1. This not being possible validates and confirms the method used. Your premise 'This methodology should work for ANY mouse with a pressable button [...]' is mere conjecture and not supported by facts, therefore false, and, as such, your argument is not valid either (not to mention that this premise directly contradicts the conclusion).

Mice currently owned: Logitech G402/G403/G303/G Pro, Zowie FK1/EC2-A/EC2-B/ZA12, Razer Deathadder 2013/Basilisk, Cooler Master Mastermouse S/MM530/MM520, Roccat Kone Pure Owl-Eye, Dream Machines DM1 Pro S/FPS/DM3 mini, EVGA Torq X3/X5, Ninox Venator, HP Omen 600, Thermaltake Ventus X RGB Optical/Ventus R, Microsoft WMO, Steelseries Rival 310, Nixeus Revel, Ozone Neon M50

Looking to buy and try: Ninox Astrum
cdcd is offline  
post #548 of 568 (permalink) Old 08-05-2020, 07:31 AM
New to Overclock.net
 
Join Date: Jan 2020
Posts: 15
Rep: 0
Quote: Originally Posted by cdcd View Post
For mechanical switches, any click latency (button-down) will come from any debounce delay.
edit: This is quite misleading. It seems you're just talking about the switch itself. But a mouse is more than just a switch, so only measuring a switch while talking about the performance of a mouse is not only fallacious but misleading and disingenuous.


For "click latency" of a mouse there are many sources of delay. From the time the physical button is making contact until the application gets the event includes: debouncing, the rest of the firmware adding delays, the transmission technology adding delays (true for both wireless and wired connections and protocols) and there's more on the PC side but I assume this is configured consistently and for best possible performance (e.g. highest supported polling rates for USB mice).



Quote: Originally Posted by cdcd View Post
The XM1 buttons are not debounced (at least not in the traditional way), hence it is not possible to measure click latency that way. So it's exactly the opposite of what you inferred: TPU testing methodology would be fundamentally flawed if it were possible to measure click latency on the XM1. This not being possible validates and confirms the method used. Your premise 'This methodology should work for ANY mouse with a pressable button [...]' is mere conjecture and not supported by facts, therefore false, and, as such, your argument is not valid either (not to mention that this premise directly contradicts the conclusion).
You just confirmed that either "TPU is doing something completely wrong or measuring something else (see my earlier posts)".


As I have explained, when measuring time delay from a mechanical switch making contact (1) and the application receiving mouse-down event (2) it doesn't matter what happens in between. Any debouncing, processing, transmission ... delay will add to (2). That's input latency.

As the testing methodology doesn't measure this time delay directly, but instead measures relative difference between a reference and tested mouse:
(1) is used as the synchronization point for the reference and tested mouse.
Time measurements at (2) gives you the relative latency.


You cannot just call this "mere conjecture and not supported by facts" and at the same time asserting this is false without providing any evidence that it is. That's hypocritical and a logical fallacy itself.



And it looks like you again didn't understand the very simple argument: since one can measure the latency between (1) and (2) one can also use two mice to measure the relative delay for any two mice with pressable switches (1) producing a mouse-down event (2).
Since the XM1 is a mouse with a button (duh) that produces a mouse-down event (duh) the inability to produce the result means that: either "TPU is doing something completely wrong or measuring something else (see my earlier posts)".
q.e.d.

Last edited by xnoreq; 08-05-2020 at 07:43 AM.
xnoreq is offline  
post #549 of 568 (permalink) Old 08-05-2020, 08:45 AM
Mouse addict
 
cdcd's Avatar
 
Join Date: Jan 2017
Posts: 719
Rep: 33 (Unique: 23)
Quote: Originally Posted by xnoreq View Post
edit: This is quite misleading. It seems you're just talking about the switch itself. But a mouse is more than just a switch, so only measuring a switch while talking about the performance of a mouse is not only fallacious but misleading and disingenuous.


For "click latency" of a mouse there are many sources of delay. From the time the physical button is making contact until the application gets the event includes: debouncing, the rest of the firmware adding delays, the transmission technology adding delays (true for both wireless and wired connections and protocols) and there's more on the PC side but I assume this is configured consistently and for best possible performance (e.g. highest supported polling rates for USB mice).




You just confirmed that either "TPU is doing something completely wrong or measuring something else (see my earlier posts)".


As I have explained, when measuring time delay from a mechanical switch making contact (1) and the application receiving mouse-down event (2) it doesn't matter what happens in between. Any debouncing, processing, transmission ... delay will add to (2). That's input latency.

As the testing methodology doesn't measure this time delay directly, but instead measures relative difference between a reference and tested mouse:
(1) is used as the synchronization point for the reference and tested mouse.
Time measurements at (2) gives you the relative latency.


You cannot just call this "mere conjecture and not supported by facts" and at the same time asserting this is false without providing any evidence that it is. That's hypocritical and a logical fallacy itself.



And it looks like you again didn't understand the very simple argument: since one can measure the latency between (1) and (2) one can also use two mice to measure the relative delay for any two mice with pressable switches (1) producing a mouse-down event (2).
Since the XM1 is a mouse with a button (duh) that produces a mouse-down event (duh) the inability to produce the result means that: either "TPU is doing something completely wrong or measuring something else (see my earlier posts)".
q.e.d.
You're just repeating the same argument again and again. Yes, there are other facts influencing click latency, but they tend to be either negligible (<0.1 ms) and/or shared between all mice (i.e., polling rate). So in most case, what separates mice is the amount of debounce delay they have. And again, your hypothesis (XM1 being just like any mouse with a pressable button) is demonstrably false. In order for the program used for this method to work, there ought to be (1) switch pins as physical contact points and (2) traditional debouncing being used. (1) is true for the XM1, (2) isn't. For optical switches, neither (1) or (2) are true. This is just a limitation of the testing methodology. A method being limited doesn't render results pertaining to the set the method is valid for false. You're just postulating that the method is valid for all mice with pressable buttons, but that is not the case (it doesn't even work for side buttons, for example). Once you drop that premise, your entire argument crumbles. Ask the guy who wrote the program if you don't believe me (or, alternatively, the guy who wrote the firmware for the XM1).

Mice currently owned: Logitech G402/G403/G303/G Pro, Zowie FK1/EC2-A/EC2-B/ZA12, Razer Deathadder 2013/Basilisk, Cooler Master Mastermouse S/MM530/MM520, Roccat Kone Pure Owl-Eye, Dream Machines DM1 Pro S/FPS/DM3 mini, EVGA Torq X3/X5, Ninox Venator, HP Omen 600, Thermaltake Ventus X RGB Optical/Ventus R, Microsoft WMO, Steelseries Rival 310, Nixeus Revel, Ozone Neon M50

Looking to buy and try: Ninox Astrum

Last edited by cdcd; 08-05-2020 at 08:52 AM.
cdcd is offline  
post #550 of 568 (permalink) Old 08-05-2020, 09:21 AM
New to Overclock.net
 
Join Date: Jan 2020
Posts: 15
Rep: 0
Quote: Originally Posted by cdcd View Post
Yes, there are other facts influencing click latency, but they tend to be either negligible (<0.1 ms) and/or shared between all mice (i.e., polling rate).
This is mere conjecture and not supported by facts, especially considering wireless mice.
Also, your statement about debounce time only holds for the most trivial implementations that are essentially low-pass filters that delay the signal regardless of button state ... as I've already explained. Yeah, I need to repeat myself since you don't seem to get it.


So what you're trying to avoid to say is that I was right. That TPU doesn't provide click latency (delay from mechanical switch being pressed to mouse-down event in application) but measures something else..

What then exactly is measured and what have the other sources of the cobbled together latency spreadsheet measured precisely? I've asked this before but got no answer, other then "we're using qsxcv's program", one of which measures OS click-event duration (invalid) and the other measures what I've described in my previous post (relative click latency - good enough for comparisons).
But apparently this is not what is being measured, so what I've been saying all along is true: the data is misleading and since they're probably a mix of several different measured things should be considered invalid.



Quote: Originally Posted by cdcd View Post
And again, your hypothesis (XM1 being just like any mouse with a pressable button) is demonstrably false. In order for the program used for this method to work, there ought to be (1) switch pins as physical contact points and (2) traditional debouncing being used. (1) is true for the XM1, (2) isn't.
At this point I have to assume malice. You're deliberately misrepresenting and changing what I said.
(1) is when the physical button or switch is pressed down.
(2) is when the application receives a mouse-down event.

You're saying that when I press the left button on the XM1 that the application doesn't receive a mouse-down event (2)?


Quote: Originally Posted by cdcd View Post
For optical switches, neither (1) or (2) are true.
Are you high?
A mouse with optical switches has a physical button that can be pressed (1) and that results in a mouse-down event in the OS/driver (2). The fact that the switch is optical is completely irrelevant.
xnoreq is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off