# Click Latencies compiled



## badben25

The information to put this together is messy and unorganized, but here's where some of it is from: 1 | 2 | 3 | 4 | 5

I have used many sources, though I'd like to thank:
uaokkkkkkkk
rafalog
qsxcv
vanir1337


----------



## badben25

Some links to KeyResponse PK for 'bump testing':
Latest release here (direct link)
Official webpage (scroll down the page)
Last version with old interface (without timer, easier to use)

Please note that the majority of figures produced on this sheet are via wiring the switches and using a utility to measure input.

Bump testing is for those that would like an alternative involving less work. Some would argue it is less accurate (and it can be), though when done correctly, strictly and with a big enough sample size, the results come in the same ballpark as wiring up the switches.


----------



## badben25

Note to Mods: If this thread crosses any rules, please PM me before modifying/deleting anything. I will do the requested changes myself; it was a lot of work to do this. Thanks.

If required, maybe this thread should be a sticky so it can help more members.

I am looking for some verifications and hoping someone can help:

# Why is the Roccat Savu fw1.18 and 1.20 the best? Was it improved tracking? What is the click latency on these?

# I was corrected that all SteelSeries Kinzu v1 releases have good click latency. Need latency numbers from other releases apart from P/N:62010.

# The Logitech G402 and G303 have new firmware that has made them slower. Need to verify this and the firmware version number.

# The click latency of SteelSeries Rival 100 (yes, again) and firmware version number.

# Delay between left and right click on DM1 Pro S and Nixeus Revel?

I want to add click latency of:

SteelSeries Rival (on fw newer than 1.2.0.0)

SteelSeries Rival 300

SteelSeries Sensei / Sensei Raw

Logitech G502

Finalmouse Tournament Pro

Finalmouse Scream One

Roccat Kone Pure Optical (with fw number)

Roccat Kone Pure Military (on fw newer than 1.10)

Genius GX Scorpion M6-600, M6-400

Help me out, OCN members!


----------



## Ino.

I could only give values against the G303 at best, don't have any of the faster ones readily available.

Also look into adding a table instead of plain text.


----------



## ramoramo

Ty very much







Exactly what I needed.


----------



## wareya

> Roccat Kone Pure Military (on fw newer than 1.10)

My WMO at 1000hz is ~8ms slower than my KPM FW1.11. Give or take an ms.

It's probably exactly the same as fw1.10.

Also my abyssus v2 is ~approximately~ halfway between the WMO 1000hz and the KPM fw1.11.


----------



## badben25

Quote:


> Originally Posted by *Ino.*
> 
> I could only give values against the G303 at best, don't have any of the faster ones readily available.
> 
> Also look into adding a table instead of plain text.


That would do as well. We could still adjust figures into the list. For now I'll take anything and everything in regards to the missing info.


----------



## gene-z

Nice idea, but you're better off creating a Google Spreadsheet and sharing it publicly. Would be much better having the ability to sort highest to lowest and vice versa. It would also be much tidier.


----------



## badben25

I'll get onto it as soon as I can. Are there any additional points or ideas for it? I will be making a table and possibly a chart/graph as well.


----------



## gene-z

Quote:


> Originally Posted by *badben25*
> 
> I'll get onto it as soon as I can. Are there any additional points or ideas for it? I will be making a table and possibly a chart/graph as well.


Maybe go to town and write the sensor it uses, switch types, cord, dpi settings, polling rates, weight, etc. Would be cool to have a comprehensive mouse list with every little detail similar to something like this.


----------



## badben25

Added links to spreadsheet and interactive chart in the first post!


----------



## badben25

Quote:


> Originally Posted by *gene-z*
> 
> Maybe go to town and write the sensor it uses, switch types, cord, dpi settings, polling rates, weight, etc. Would be cool to have a comprehensive mouse list with every little detail similar to something like this.


I initially thought of it but that would be outside its scope. Not to mention I'd never be able to finish it lol


----------



## Elrick

Quote:


> Originally Posted by *badben25*
> 
> *NMouse 4K* (fw1.18 and above)
> *Zalman ZM-M600R*
> -0.3ms


DAMN, now watch all the ultra low latency freaks jump for this model







.

Who would of thought Zalman could deliver this despite everyone's blindness towards worshiping only Razer and Logitech consistently.


----------



## wareya

Oh yeah I forgot to say this thread reminded me how I remember someone saying the kone pure optical black's clicks were 8ms faster than the kpm, both on the low latency firmware

>Roccat Kone Pure Military (fw1.10, 1.11)
>4.2ms


----------



## qsxcv

Quote:


> Originally Posted by *Elrick*
> 
> Who would of thought Zalman


the zalman is honestly probably the best mouse you can get for its price.
if 3090 lod and angle snapping aren't issues


----------



## wareya

but can I mod it


----------



## qsxcv

http://www.overclock.net/t/1595500/zalman-zm-m600r-pics/0_100#post_25035718

kind of tight but it's possible


----------



## bruzanHD

Quote:


> Originally Posted by *badben25*
> 
> SteelSeries Kinzu (product number 62010?)


nope, any v1 has the same latenvy as they all have the same firmware.


----------



## realistic01

How much does WMO click latency improve if at 8k Hz polling? Is it a linear increase?


----------



## SpiLLi

Quote:


> Originally Posted by *qsxcv*
> 
> the zalman is honestly probably the best mouse you can get for its price.
> if 3090 lod and angle snapping aren't issues


hmm I had actually never even looked into this mouse. How bad is the lod? We talking like fnatic flick bad or even worse? Like the look of the shape and for 30$ why not


----------



## uaokkkkkkkk

Meh, not gonna bother with correcting a bunch of stuff. It is what it is.

I will share this since it was something I was looking into tonight.

These Dexin mice have the adjustable debounce feature:

*Minimum=0ms Max=32ms:*
Sentinel Advance I & II
Inferno
Reaper
Havoc
Black (Excluding V2)
Black Element

*Minimum=12ms Maximum=36ms:*
Theron
Level 10M (Not 2016 version)

To be clear though the values I stated above are what they are "intended" internally to do. Well, except the Theron. That gains temporary amnesia after a firmware update.

I'd go into the current lineup of Dexin mice that now have the minimum set to 4ms. However I do not have them or have looked at them yet. I plan on buying the Ventus R, so when that happens I'll bother with it.


----------



## chr1spe

Quote:


> Originally Posted by *realistic01*
> 
> How much does WMO click latency improve if at 8k Hz polling? Is it a linear increase?


Probably not much.


----------



## the1onewolf

Good stuff.
Although I'm actually surprised the G900 has more click latency than the g402, 303 and etc.


----------



## badben25

Quote:


> Originally Posted by *bruzanHD*
> 
> nope, any v1 has the same latenvy as they all have the same firmware.


Do you know if there's only 1 version of firmware or more?

I've seen some guys here like the Kinzu v1, but doesn't the inherent accel issue bother any of you?
Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Meh, not gonna bother with correcting a bunch of stuff. It is what it is.


Hey man, it would benefit all of us if you bothered.


----------



## bruzanHD

Quote:


> Originally Posted by *badben25*
> 
> Do you know if there's only 1 version of firmware or more?
> 
> I've seen some guys here like the Kinzu v1, but doesn't the inherent accel issue bother any of you?


the driver flashes the firmware, the v1 uses a unique driver therefore all v1 firmware has to be the same. In regard to liking the mouse though, the accel is not on the 400CPI step and most of us (I think it is only myself, Alya, and qsxcv used it for a short time) use it for the shape/weight. The sensor is made by the same company as the WMO, IO, and IE, sensor is also 9375 FPS which is better than even a 3310.


----------



## badben25

Quote:


> Originally Posted by *bruzanHD*
> 
> the driver flashes the firmware, the v1 uses a unique driver therefore all v1 firmware has to be the same. In regard to liking the mouse though, the accel is not on the 400CPI step and most of us (I think it is only myself, Alya, and qsxcv used it for a short time) use it for the shape/weight. The sensor is made by the same company as the WMO, IO, and IE, sensor is also 9375 FPS which is better than even a 3310.


Thanks for the info man. I'll update the charts now.


----------



## Gonzalez07

LOL the zalman has the click latency graph on the amazon page


----------



## tp4tissue

Any one experiment with how click latency change while the mice are in MOTION?


----------



## wareya

There are mice that change pixel latency when you pick them up, but I don't know of any that change it while in motion, just when "asleep"


----------



## qsxcv

well it shouldn't at al unless firmware is trash, which is definitely possible so i wouldnt be surprised


----------



## tp4tissue

Quote:


> Originally Posted by *qsxcv*
> 
> well it shouldn't at al unless firmware is trash, which is definitely possible so i wouldnt be surprised


I think these latency tables are of very limited use/insight without testing latency in-motion..


----------



## badben25

Added more data, made a bunch of corrections. Everything is on the spreadsheet now.

I'm having some trouble with the bar chart's size and readability. I can't seem to find how to have the bars be of a fixed size and still have all of them show up, along with having scrolling. I can only fit it within my browser window and the rest of it adjusts itself which is pretty limiting. Can anyone here help with that?


----------



## karod

How do you use the software?
It counts down from 6 to 1 and then I have to double click for it to register something. But it always shows some 100s of milliseconds.


----------



## badben25

Quote:


> Originally Posted by *karod*
> 
> How do you use the software?
> It counts down from 6 to 1 and then I have to double click for it to register something. But it always shows some 100s of milliseconds.


You have to bump the the left-click of one mouse with the right-click of another, and it'll tell you which one is faster and by how much. It will take a bunch of attempts to get it right and then another bunch for consistency.

From another post:
Quote:


> Using it is pretty straight forward: bump LMB against RMB of the other mouse.
> Note that the left mouse button of either mouse is A and the right mouse button of either mouse is B. So when you switch the mice bumping by L/R buttons, the winner will change from A to B or vice versa (assuming one mouse is always faster than the other with both buttons).


----------



## SpecialKthx

Quote:


> Originally Posted by *the1onewolf*
> 
> Good stuff.
> Although I'm actually surprised the G900 has more click latency than the g402, 303 and etc.


Quote:


> Originally Posted by *badben25*
> 
> You have to bump the the left-click of one mouse with the right-click of another, and it'll tell you which one is faster and by how much. It will take a bunch of attempts to get it right and then another bunch for consistency.


thats the reason why, g900 and gpro and g303 have spring for buttons.

You should not bump for a click latency test, I've been following rafa since 1-2 year. He actuate them with one switch. So you get the latency between the switch actuation and the PC.

http://blog-imgs-48.fc2.com/r/a/f/rafaut/measurement01.jpg

http://blog-imgs-48.fc2.com/r/a/f/rafaut/testingmethods.jpg


----------



## wareya

Why shouldn't you bump for the latency test

If you bump hard enough, it's going to be obvious when the switches actuate differently and you can throw out outlier cases. plus the existence of outlier clicks is useful information. I had really weird problems playing TF2 with my DA 3.5g that was starting to wear out beyond use, and I learned that it was because clicks randomly actuated something like 10ms-20ms later than normal, or something like that, because the switch was so worn out.


----------



## SpecialKthx

If you bump it really fast, you will still have a little difference because 1ms is really fast, If one switch is harder than the other, the harder switch will actuate after the softer one.

So the harder switch has the extra ms it takes to actually travel the softer mouse to actuation


----------



## wareya

That's part of the latency you get with a particular mouse, and it's *definitely* going to be smaller than 1ms, unless you're really not hitting them fast at all.

There's also "which mouse is polled first"; unlike mousetester motion latency tests, which accidentally correct for polling rate differences, click latency is sensitive to this. on my super old laptop, unplugging and plugging back in my mice gave different polling phases in mouse tester, and slightly different average button latency differences. this is a bigger problem than whether or not you're opening up your mouse.


----------



## SpecialKthx

Quote:


> Originally Posted by *wareya*
> 
> That's part of the latency you get with a particular mouse, and it's *definitely* going to be smaller than 1ms, unless you're really not hitting them fast at all.
> 
> There's also "which mouse is polled first"; unlike mousetester motion latency tests, which accidentally correct for polling rate differences, click latency is sensitive to this. on my super old laptop, unplugging and plugging back in my mice gave different polling phases in mouse tester, and slightly different average button latency differences. this is a bigger problem than whether or not you're opening up your mouse.


The thing is that the graph is mixed with rafa numbers using his method. also its unfair to give the softer mouse the advantage of only calculating the actuation VS the harder mouse testing his own full actuation with travel to hit the actuation


----------



## wareya

Softer mice have an advantage when actually using them though.

The only problem is if you're mix matching latency tests from shared switch testing with latency tests from bump tests, like knowing mouse A's latency objectively, testing B against A with the switch tests, and C against B with the bump test, C will be higher or lower than A depending on the difference in switch weight wheras with A vs B the switch weight is eliminated.

but the usb polling phasing skew introduces up to 0.5ms in both directions already, and if you're chaining comparisons like this to get objective numbers without adding a range onto them you're already doing it wrong


----------



## badben25

Quote:


> Originally Posted by *SpecialKthx*
> 
> thats the reason why, g900 and gpro and g303 have spring for buttons.
> 
> You should not bump for a click latency test, I've been following rafa since 1-2 year. He actuate them with one switch. So you get the latency between the switch actuation and the PC.
> 
> http://blog-imgs-48.fc2.com/r/a/f/rafaut/measurement01.jpg
> 
> http://blog-imgs-48.fc2.com/r/a/f/rafaut/testingmethods.jpg


No...

Ofcourse I know about rafa's work, and on this list I have tried to be as accurate and up to date as possible, and have prioritized results from the wiring method than bump tests. Work by sousu and rafa is old though, so I've used results from uaokkk and qsxcz whenever I could. It is true that there are still a few mice on the list that did not have wired tests done, and in those cases I've taken the averages from the most consistent numbers. I'd rather have a close result and still have those mice on the list, rather than no inclusion just because the bump tests aren't easy for everybody to agree with.

On that note, what you say makes sense theoretically, but in real life trials the bump tests are not far off from the wired tests. Yes, it does take a number of attempts but you can certainly get reliable results by hitting fast/hard enough for a specific case as well as being thorough. qsxcz has proven this in a few of his posts.

I am going to be adding such info to the first posts. The sources are unorganized but you can take a look here and here for some more insight. Those threads have been updated a bunch of times so some material may not be found anymore.


----------



## badben25

Got my hands on a KTEC KTM-9500+ and it is on average 1.5ms faster than the Fatal1ty 2020. I used 200 bump tests. This makes it the fastest mouse on the list now.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *badben25*
> 
> Got my hands on a KTEC KTM-9500+ and it is on average 1.5ms faster than the Fatal1ty 2020. I used 200 bump tests. This makes it the fastest mouse on the list now.


I doubt it would beat the Areson/Gigabyte M63 in the wired test. In the end they would just be all 1ms anyway.


----------



## badben25

Here's a pic of internals in case anyone's interested


----------



## uaokkkkkkkk

Well, at least they had a holder for the led. I guess it cost so much they had to cut costs in other places. A lot of other places.


----------



## m0uz

More companies need to utilise the KTEC's top mounted M4 and M5 buttons


----------



## uaokkkkkkkk

Geil/Epicgear Zora = 10ms debounce


----------



## xname

perhaps update Asus ROG Sica and Gladius info: http://www.overclock.net/t/1542757/rog-sica/570


----------



## Deku

why is dm1 pro 1.3 ms and dm1 pro s 6.2 ?


----------



## Alya

Quote:


> Originally Posted by *Deku*
> 
> why is dm1 pro 1.3 ms and dm1 pro s 6.2 ?


Probably using the same firmware as the Revel.


----------



## uaokkkkkkkk

Revel ≠ DM1


----------



## czerro

DM1 Pro - S clocks at 6.2ms...as does the Revel









I suspect the two mice are mostly identical internally.

I think it's possible the person you are replying to does not understand 'DM1 Pro' and 'DM1 Pro-S' are different mice. He just noticed 'DM1 Pro' on the list and and then searched Revel to compare. He therefore compared the wrong mice. The DM1 Pro-S values are also listed: 6.2ms.

Exact same as Revel.


----------



## Alya

Quote:


> Originally Posted by *czerro*
> 
> DM1 Pro - S clocks at 6.2ms...as does the Revel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I suspect the two mice are mostly identical internally.
> 
> I think it's possible the person you are replying to does not understand 'DM1 Pro' and 'DM1 Pro-S' are different mice. He just noticed 'DM1 Pro' on the list and and then searched Revel to compare. He therefore compared the wrong mice. The DM1 Pro-S values are also listed: 6.2ms.
> 
> Exact same as Revel.


I know the difference Pro has a 3310 and Pro S has a 3360, different mice from the same people (DreamMemechines), I wasn't paying attention when I made the post, so I noticed the Revel and the DM1 Pro S had similar latencies and then also realized I had something already quoted, so dumbly, I thought the post I quoted was relevant. It wasn't.

DM1 Pro and DM1 Pro S use different firmwares, seems the DM1 Pro S uses the same firmware as the Revel. I have no clue what the DM1 Pro firmware is based on, if anything. Better?


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *czerro*
> 
> DM1 Pro - S clocks at 6.2ms...as does the Revel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I suspect the two mice are mostly identical internally.
> 
> I think it's possible the person you are replying to does not understand 'DM1 Pro' and 'DM1 Pro-S' are different mice. He just noticed 'DM1 Pro' on the list and and then searched Revel to compare. He therefore compared the wrong mice. The DM1 Pro-S values are also listed: 6.2ms.
> 
> Exact same as Revel.


Revel was +7.7ms when mr.q measured it against a teensy.

The Revel and DM1 Pro S are not identical internally.

Alya knows the difference between the DM1 Pro and DM1 Pro S.

I just thought he forgot that the DM1 Pro/S and Revel were from different manufacturers. Which is pretty easy to do.


----------



## chr1spe

Quote:


> Originally Posted by *Alya*
> 
> I know the difference Pro has a 3310 and Pro S has a 3360, different mice from the same people (DreamMemechines), I wasn't paying attention when I made the post, so I noticed the Revel and the DM1 Pro S had similar latencies and then also realized I had something already quoted, so dumbly, I thought the post I quoted was relevant. It wasn't.
> 
> DM1 Pro and DM1 Pro S use different firmwares, seems the DM1 Pro S uses the same firmware as the Revel. I have no clue what the DM1 Pro firmware is based on, if anything. Better?


I always assumed they were using the same firmware as FM since I thought they were using the same PCBs. I guess the click latency is different though or one of the latency measurements is wrong. If I had to guess though the firmware was just made by motospeed possibly with a bit of input from the actual companies.


----------



## uaokkkkkkkk

Quote:


> abyssus 3.5g
> blue lights, like mirror edition, lmb+rmb is 18.2ms


Huh? My abyssus 3.5g never had that issue.


----------



## uaokkkkkkkk

Well, I'll be damned it was the Hades mice all along...

background; there was a mystery mouse from 2007-2008 era that had this feature. turns out the answer was in plain sight. typical.

@FoxWolf1 the reason the H8 was 16ms was because it defaulted to that. it was actually adjustable in the software.

per this:


----------



## FoxWolf1

Aha! So that's what that does...good to know!


----------



## uaokkkkkkkk

glad i could tell you what it was 4 years after you stopped caring \o/


----------



## uaokkkkkkkk

Kova 2016 4ms.


----------



## badben25

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Kova 2016 4ms.


Would be nice if you could include firmware version and if its vs the M63, Ikari, or something else.


----------



## uaokkkkkkkk

All firmware versions. Latest is 1.18.


----------



## m0uz

Just tested the Xornet II with 1.02, 1.03 and 1.28 and all of them are about 8ms slower than G Pro. I downgraded to 1.02 because the graph says it lowers the click latency and it did jack faeces


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *m0uz*
> 
> Just tested the Xornet II with 1.02, 1.03 and 1.28 and all of them are about 8ms slower than G Pro. I downgraded to 1.02 because the graph says it lowers the click latency and it did jack faeces


They were all 4ms. If you seriously downgraded to 1.02 for a 0.3ms difference then just lol.

Also, this spreadsheet should have all it's values rounded. So you don't have this weird 3.8ms vs 4.1ms hilarity.

Wait, Abyssus has a difference of 18ms when pressing both buttons at the same? Wat.


----------



## m0uz

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> They were all 4ms. If you seriously downgraded to 1.02 for a 0.3ms difference then just lol.
> 
> Also, this spreadsheet should have all it's values rounded. So you don't have this weird 3.8ms vs 4.1ms hilarity.
> 
> Wait, Abyssus has a difference of 18ms when pressing both buttons at the same? Wat.


Why is it displaying as being 8ms slower than the G Pro then? That makes it about 13ms slower than the Ikari. Plus, I didn't know what the click delay was like on 1.28 so I tested it on it and 1.03 as well. Both weren't good so I thought I'd downgrade to 1.02 and check again and it was the exact same value as 1.28 and 1.03.


----------



## badben25

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Also, this spreadsheet should have all it's values rounded. So you don't have this weird 3.8ms vs 4.1ms hilarity.


Yeah I think so too, but I guess it's a detail that's not a chore to enter. Maybe I will just round them off later.
Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Wait, Abyssus has a difference of 18ms when pressing both buttons at the same? Wat.


It's from one of your posts, one where you also mentioned how the Abyssus gives inconsistent results which might be linked to batches.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *badben25*
> 
> Yeah I think so too, but I guess it's a detail that's not a chore to enter. Maybe I will just round them off later.
> It's from one of your posts, one where you also mentioned how the Abyssus gives inconsistent results which might be linked to batches.


Two revisions of the Abyssus 2009-2013. First revision was 3ms, second was 13/14ms.
Quote:


> Originally Posted by *m0uz*
> 
> Why is it displaying as being 8ms slower than the G Pro then? That makes it about 13ms slower than the Ikari. Plus, I didn't know what the click delay was like on 1.28 so I tested it on it and 1.03 as well. Both weren't good so I thought I'd downgrade to 1.02 and check again and it was the exact same value as 1.28 and 1.03.


Bump testing I guess?

I just checked 1.28 and it's 4ms. Tap test in this case renders bump testing useless. Hell, bump testing would take longer in this case.


----------



## Aliandro1d

Is there a new firmware gor the katar, i like the shape but 16ms might stop me from picking one up


----------



## uaokkkkkkkk

Updated the Katar to firmware 2.09 from 1.07.



Nothing changed. Mouse still feels like a cheap piece of crap. I can't put this thing back into it's box fast enough.


----------



## Arizonian

Thank you badben25 for compiling and maintaining the OP latency list.









As long as this is actively being updated I put it on the section sticky list for easy reference and access.

Will make it easier for members to find when doing research on their mice.


----------



## badben25

Thanks dude


----------



## pruik6

Just some random click latency's based on a ikari. HAHA


----------



## subsoul

What I don't understand is that the spreadsheet says the DM1 Pro is 1.2ms click latency yet other reviewers are measuring around Logitech's click latency area.

It also states 20ms added on m1 n m2, I don't really understand would that not make the click latency much much higher on the board as they are primary main buttons?


----------



## chr1spe

Quote:


> Originally Posted by *subsoul*
> 
> What I don't understand is that the spreadsheet says the DM1 Pro is 1.2ms click latency yet other reviewers are measuring around Logitech's click latency area.
> 
> It also states 20ms added on m1 n m2, I don't really understand would that not make the click latency much much higher on the board as they are primary main buttons?


Are you sure you aren't confusing reviews of Pro and Pro S. They are different mice with different debounce intervals. Also what is meant by the lmb+rmb thing is that when pressing both at the exact same time there will be a delay on one of the inputs I assume. That is a somewhat common problem on mice with poorly coded firmware.


----------



## subsoul

Quote:


> Originally Posted by *chr1spe*
> 
> Are you sure you aren't confusing reviews of Pro and Pro S. They are different mice with different debounce intervals. Also what is meant by the lmb+rmb thing is that when pressing both at the exact same time there will be a delay on one of the inputs I assume. That is a somewhat common problem on mice with poorly coded firmware.


Nah here are the links to the reviews check em out.
Is the 20ms error still an issue in the current gen? (not S)

1 http://www.overclock.net/t/1591152/dreammachine-dm1-pro-mouse-review

2 http://www.overclock.net/products/dream-machines-dm1-pro/reviews/7327

3 http://au.cybergamer.com/forums/thread/589254/ReviewTesting-Dream-Machines-DM1-Pro-Gaming-Mouse/


----------



## badben25

Quote:


> Originally Posted by *pruik6*
> 
> Just some random click latency's based on a ikari. HAHA


?
Quote:


> Originally Posted by *chr1spe*
> 
> Are you sure you aren't confusing reviews of Pro and Pro S. They are different mice with different debounce intervals. Also what is meant by the lmb+rmb thing is that when pressing both at the exact same time there will be a delay on one of the inputs I assume. That is a somewhat common problem on mice with poorly coded firmware.


This is correct.
Quote:


> Originally Posted by *subsoul*
> 
> Nah here are the links to the reviews check em out.
> Is the 20ms error still an issue in the current gen? (not S)
> 
> 1 http://www.overclock.net/t/1591152/dreammachine-dm1-pro-mouse-review
> 
> 2 http://www.overclock.net/products/dream-machines-dm1-pro/reviews/7327
> 
> 3 http://au.cybergamer.com/forums/thread/589254/ReviewTesting-Dream-Machines-DM1-Pro-Gaming-Mouse/


The mouse does not have any wired tests for it so I decided to go with Ino's results: http://www.overclock.net/t/1601672/dreammachines-dm2-comfy-review-by-ino

DM1 and DM2 were practically the same inside. If I can get more info I am willing to update the sheet.


----------



## Alya

Quote:


> Originally Posted by *pruik6*
> 
> Just some random click latency's based on a ikari. HAHA


Give us a better way to test click delay then, besides basing it around what we consider to be the lowest possible delay that we know of.


----------



## chr1spe

Quote:


> Originally Posted by *subsoul*
> 
> Nah here are the links to the reviews check em out.
> Is the 20ms error still an issue in the current gen? (not S)
> 
> 1 http://www.overclock.net/t/1591152/dreammachine-dm1-pro-mouse-review
> 
> 2 http://www.overclock.net/products/dream-machines-dm1-pro/reviews/7327
> 
> 3 http://au.cybergamer.com/forums/thread/589254/ReviewTesting-Dream-Machines-DM1-Pro-Gaming-Mouse/


Well two of those are actually pretty ambiguous. The second one compares to the g402 which has ~1-2ms of latency for earlier firmware and ~5ms for later firmware and puts it on par with that which could agree with what is in the spreadsheet if it was an earlier g402 firmware. Also the third one just confuses me. It says "-1ms and 3-4ms (relative to the Logitech G300s)" which is confusing to me. I think maybe the writer confused the g303 latency with the g300s latency. -1ms from the g303 would give 3-4ms . -1ms from the g300s would give approximately 0ms.


----------



## subsoul

Quote:


> Originally Posted by *chr1spe*
> 
> Well two of those are actually pretty ambiguous. The second one compares to the g402 which has ~1-2ms of latency for earlier firmware and ~5ms for later firmware and puts it on par with that which could agree with what is in the spreadsheet if it was an earlier g402 firmware. Also the third one just confuses me. It says "-1ms and 3-4ms (relative to the Logitech G300s)" which is confusing to me. I think maybe the writer confused the g303 latency with the g300s latency. -1ms from the g303 would give 3-4ms . -1ms from the g300s would give approximately 0ms.


Almost every review I have watched they have said it is in par with current gen of logitech, just want to make sure accurate information is being delivered.


----------



## HotCheetos333

I appreciate the included decimal numbers. Im sure others do too


----------



## badben25

Quote:


> Originally Posted by *HotCheetos333*
> 
> I appreciate the included decimal numbers. Im sure others do too


Personally I don't think decimal values matter when speaking about a few ms, so don't use them as law for hard ranking. If something is 4.5 for example, consider it to be 4ms - 5ms.


----------



## chr1spe

Well considering polling rate it shouldn't even be possible to get a fraction of an ms. I know it is just an average of different measurements, but really I don't even see why results aren't almost perfectly consistent. I guess I'm not sure the frequency at which most mice read the button states with the MCU, but I would assume 1000hz which would mean even if you set the debounce interval to 4.5ms it would effectively be 5ms.


----------



## wareya

mice don't respond immediately after being polled

they can wait X time between polling the button and responding to the PC


----------



## chr1spe

Quote:


> Originally Posted by *wareya*
> 
> mice don't respond immediately after being polled
> 
> they can wait X time between polling the button and responding to the PC


Yeah, I guess I didn't think about the fact that reading the buttons state by the mcu and the usb polling can be desynced and probably is on many mice. Ideally you would try to sync those and read the button state just slightly before a usb poll should be coming, but I doubt many mice actually do that.


----------



## wareya

Even if they're synced the time between polling the buttons and sending off over USB will be different between mice. For example if mice read the sensor and buttons in a different order they'll have different click and tracking latencies, even if otherwise identical.


----------



## chr1spe

Quote:


> Originally Posted by *wareya*
> 
> Even if they're synced the time between polling the buttons and sending off over USB will be different between mice. For example if mice read the sensor and buttons in a different order they'll have different click and tracking latencies, even if otherwise identical.


Well that difference should absolutely tiny and not really matter at all compared to the 1000hz polling rate.


----------



## wareya

It's larger than you'd think


----------



## Maximillion

Quote:


> Originally Posted by *wareya*
> 
> It's larger than you'd think


You said it brother.


----------



## Niko2K

not really into this but howcome some older mice have better latency than their newer models?


----------



## patoux01

Quote:


> Originally Posted by *Alya*
> 
> Give us a better way to test click delay then, besides basing it around what we consider to be the lowest possible delay that we know of.


Didn't some guy in China make a setup that allowed to do real tests and popping out absolute values? Why has it not been copied?


----------



## chr1spe

Quote:


> Originally Posted by *patoux01*
> 
> Didn't some guy in China make a setup that allowed to do real tests and popping out absolute values? Why has it not been copied?


I'm pretty sure his test was click to screen latency which then compounds a ton of other variables (monitor, framerate, etc.) and would never allow any people with 2 different setups to compare results. I suppose it may be possible to make something where you don't use click to screen latency, but it would still require you to make some sort of USB device with an arduino or something along those lines that lights an LED when you click your mouse and then hooking up an LED to the actual mouse switch and then measuring the time between those two lights. That would still add in a lot of complication, work and setup to test each mouse without really providing any extra information and would limit the number of people who can contribute which would reduce the number of tested mice.


----------



## Wall Street

Quote:


> Originally Posted by *Niko2K*
> 
> not really into this but howcome some older mice have better latency than their newer models?


Some mice have been updated with firmwares to prevent double clicks. It is easy to make a mouse that responds fast but is also prone to register false double clicks. If the mouse maker is getting too many complaints of double clicks, the easiest thing to do is to not register any click until after a long debounce period. It is harder (but still relatively straightforward) to program a mouse to register the click immediately, but then don't allow the button to unclick until the end of the debounce period. Either way, instead of just registering if the mouse button is clicked or not, modern mouse firmwares add delays to prevent switch chatter from registering as multiple clicks.


----------



## Gonzalez07

Quote:


> Originally Posted by *Wall Street*
> 
> Some mice have been updated with firmwares to prevent double clicks. It is easy to make a mouse that responds fast but is also prone to register false double clicks. If the mouse maker is getting too many complaints of double clicks, the easiest thing to do is to not register any click until after a long debounce period. It is harder (but still relatively straightforward) to program a mouse to register the click immediately, but then don't allow the button to unclick until the end of the debounce period. Either way, instead of just registering if the mouse button is clicked or not, modern mouse firmwares add delays to prevent switch chatter from registering as multiple clicks.


damn. nicely explained


----------



## subsoul

I just have to say.

Do any of you guys not just love the zowie shapes but the ms delay it is actually noticeable,

It can be the difference between a kill and not a kill in most competitive games.

Does this not annoy anyone else or just me lol?


----------



## Alya

Quote:


> Originally Posted by *subsoul*
> 
> I just have to say.
> 
> Do any of you guys not just love the zowie shapes but the ms delay it is actually noticeable,
> 
> It can be the difference between a kill and not a kill in most competitive games.
> 
> Does this not annoy anyone else or just me lol?


I could feel it when playing in-game, even the "fixed" Zowie mice felt a little odd after using my Kinzu which is about 0.9ms, it didn't really hurt me too much in terms of performance but I definitely felt something was off.


----------



## subsoul

Yeah it sucks for me because I notice the click difference in making shots first with awps etc. However I just cannot adjust to the G Pro or any other low click latency mouse.

I just pray zowie release an update or fix the click issue and the mouse would be perfect!


----------



## uaokkkkkkkk

Well Kingsis branded Zowie/Benq mice have been 16ms -> 10ms. So where they would go from there who knows.


----------



## Yahar

It's unfortunate that my keyboard has less latency than most mice, even my mouse from Logitech. Why can't Logitech write firmware that register clicks immediately and debounce after?


----------



## wareya

Because then they can't make mice that put pressure on the switches so that they feel artificially responsive and wellmade


----------



## Yahar

Quote:


> Originally Posted by *wareya*
> 
> Because then they can't make mice that put pressure on the switches so that they feel artificially responsive and wellmade


Hmm? Could you elaborate?


----------



## wareya

They make the mouse buttons put pressure on the switches by default to eliminate "pre-travel", but this means that the buttons can press down on the switches and make them actuate just when you move the mouse around. This actuation is extremely short, so they block it by using a latent debounce period.

If they had pre-travel or used lighter switches it wouldn't be a problem, but by playing to the unnecessary marketing gimmicks of having zero pre-travel and light switches at the same time, they have to increase the button latency in order to prevent it from causing other problems, which is really ironic.

They could probably get away with a lower debounce period but it would increase the rate of RMAs.


----------



## boGardoN

Any information on ducky secret click latency? and also ducky secret m?


----------



## qsxcv

Quote:


> Originally Posted by *wareya*
> 
> this means that the buttons can press down on the switches and make them actuate just when you move the mouse around.


for logitech? that's never happened for me

actually for the g303, the springs don't press on the plunger except at the very top of the range of motion (i.e. no pressure from your finger). so all the springs do is the button pieces from rattling

for the g pro the springs press on the plunger more. for my g pro at least. but still not enough that you actuate the switch in normal use.


----------



## wareya

Chinese omrons (at least) can actuate for a very short period of time, without "clicking", if the mouse is wired to detect clicks when the "unpressed" pin turns off, and even a little bit too much pressure on the plunger is enough to do it. I suspect that's what's happening to the scream one.


----------



## SIDWULF

I don't get it. Competitive players all use the zowie mice like the ec2-a....yet look at the friggin click response!


----------



## trhead

Quote:


> Originally Posted by *SIDWULF*
> 
> I don't get it. Competitive players all use the zowie mice like the ec2-a....yet look at the friggin click response!


~9ms is not bad. Maikelele played really well with the Newman gx1-pro which has 18.6ms lag!


----------



## vanir1337

Quote:


> Originally Posted by *trhead*
> 
> ~9ms is not bad. Maikelele played really well with the Newman gx1-pro which has 18.6ms lag!


I've had so many crazy moments with that mouse too... Now I kinda regret selling it.


----------



## M1st

Quote:


> Originally Posted by *wareya*
> 
> playing to the unnecessary marketing gimmicks of having zero pre-travel and light switches at the same time


I don't play fps that much anymore, but that's obligatory for a mouse to be good for mobas. If you can't spam 4-5 rightclicks/second there, that's actually a huge disadvantage.


----------



## wareya

I stutterclick better with heavy switches for some reason


----------



## M1st

Quote:


> Originally Posted by *wareya*
> 
> I stutterclick better with heavy switches for some reason


How do u actuate the buttons? "Slap" motion? I spam by contracting forearm muscles slightly, not even moving the fingers themselves.


----------



## wareya

I use a muscle that starts near my wrist


----------



## M1st

Quote:


> Originally Posted by *wareya*
> 
> I use a muscle that starts near my wrist


Yeah, pretty much the same. I guess, matter of preference. I tried heavy switches, and i just can't play normally. If i try to click like i usually do, i can't put enough force to actuate the button which makes me add a little movement with fingers, thus making spamming significantly slower.


----------



## wareya

if it helps my grip is basically half vertical and my fingers and the edge side of my palm are my only contact with the mouse, so there's a lot of force potential there


----------



## M1st

Quote:


> Originally Posted by *wareya*
> 
> if it helps my grip is basically half vertical and my fingers and the edge side of my palm are my only contact with the mouse, so there's a lot of force potential there


Again - i even have pretty much the same grip... I get a feeling the difference is my elbow being lower than mousing surface, i just put it on armrest.


----------



## JackCY

Quote:


> Originally Posted by *wareya*
> 
> Chinese omrons (at least) can actuate for a very short period of time, without "clicking", if the mouse is wired to detect clicks when the "unpressed" pin turns off, and even a little bit too much pressure on the plunger is enough to do it. I suspect that's what's happening to the scream one.


Yep, that's a wrong way to detect switches that have 3 poles and 3 states. They still only use 2 right?








There is no need for software debounce delay as long as all 3 states are used.


----------



## subsoul

Quote:


> Originally Posted by *SIDWULF*
> 
> I don't get it. Competitive players all use the zowie mice like the ec2-a....yet look at the friggin click response!


Because they are incredibly fast responding player (humans) through training, natural talent etc.

But if you take SK Gaming a team that is primarly a zowie mouse only team apart from one and they are currently #1 in the world.

People use this as an arguing point to click latency not really being "noticable" however if you gave these players a Zalman mouse and they all adjusted perfectly they'd be even more unstoppable


----------



## MazzaTR

Anyone know the click latency of the chinese Steelseries Rival Saviour / Rescuer?


----------



## SEJB

Actually Vp is #1 but I get your point and they also use Zowie mice like most, teams. I'd think if the pro players adjusted to new mice with less latency they would perform better, the only problem is shapes.

Karrigan is a good example of a player who has adapted very well to the G pro and it's also showing in his individual game. Probably not all down to the mouse but it sure helps I'd wager.


----------



## chr1spe

Quote:


> Originally Posted by *SEJB*
> 
> Actually Vp is #1 but I get your point and they also use Zowie mice like most, teams. I'd think if the pro players adjusted to new mice with less latency they would perform better, the only problem is shapes.
> 
> Karrigan is a good example of a player who has adapted very well to the G pro and it's also showing in his individual game. Probably not all down to the mouse but it sure helps I'd wager.


Actually I'm pretty sure VP uses 100% steel series currently due to sponsorships. I know Snax uses the Rival 100 and a few of them are using the Rival 300 at least.


----------



## SEJB

You are 100% correct actually. I could have sworn the wiki said Zowie a while ago.


----------



## subsoul

Quote:


> Originally Posted by *SEJB*
> 
> Actually Vp is #1 but I get your point and they also use Zowie mice like most, teams. I'd think if the pro players adjusted to new mice with less latency they would perform better, the only problem is shapes.
> 
> Karrigan is a good example of a player who has adapted very well to the G pro and it's also showing in his individual game. Probably not all down to the mouse but it sure helps I'd wager.


Prime example here.

SK Gaming is currently number 1, NiP are 2nd and 3rd is Virtus Pro - http://www.hltv.org/

Karrigan is not the best example to use imo, I'd say more cloud9 but again my point is its not about the mouse its the player.

However the mouse does come into consideration, GuardiaN has a custom franken mouse too due to the high click latency on his mouse but I am saying it does make a difference its just your luck if your hand adjusts properly.

For example when I hold the Logitech G Pro it feels natural and comfortable but I play avg but if I switch to my FK2 then I start playing significantly better on a variety of games however I notice the click delay


----------



## SEJB

Completely offtopic but no sk is not the nr 1 team. They've lost every match to Vp lately and Vp has won or finished second in every event they've attended the past few months.

I picked Karrigan since he switched from Zowie to Logitech by own choice instead of cloud9 players who are forced to use Logitech mice.


----------



## subsoul

Quote:


> Originally Posted by *SEJB*
> 
> Completely offtopic but no sk is not the nr 1 team. They've lost every match to Vp lately and Vp has won or finished second in every event they've attended the past few months.
> 
> I picked Karrigan since he switched from Zowie to Logitech by own choice instead of cloud9 players who are forced to use Logitech mice.




Okay...

VP Don't use Zowie anyways. Just like GTR switched from the G303 to the EC1-A it doesn't matter what they do.

The point is stop basing performance of other people if you want the highest advantage then the lowest amount of click latency is going to give you that.


----------



## v0rtex-SI

HLTV rankings? Are you serious?

Okay...


----------



## subsoul

Doesn't really matter where you check either NIP or SK are #1 in the world Gosu, ESL etc. Personal opinion is not fact as much as you want it to be.


----------



## SEJB

The thing is all those things are based on attending more events and points. Put VP up against anyone in a bo3 on lan right now and they will win. Anyone saying otherwise has no clue what they are talking about.


----------



## subsoul

Yeah your right, everyone else is wrong, nobody like Thorin, Janko etc all don't know what they are talking about.

They may be playing great just now and got there form back but they are very inconsistent. That does not mean they're #1 like you claimed which they are not ranked 1 on any site.


----------



## SEJB

The thing you don't seem to get into your skull is that rankings are based on event results and we are talking about which team is the best one. Since VP attends less events since they have families and mostly attend big events which they win which costs them in rankings but they are still the best team in the world.

Funny you should mention Thoorin since he typed this literally yesterday. "Virtus.pro will still be considered the best team in CS:GO by many, including your author"

"https://gamurs.com/articles/thorins-csgo-top-10-world-rankings-21st-november-2016


----------



## subsoul

Quote:


> Originally Posted by *SEJB*
> 
> The thing you don't seem to get into your skull is that rankings are based on event results and we are talking about which team is the best one. Since VP attends less events since they have families and mostly attend big events which they win which costs them in rankings but they are still the best team in the world.
> 
> Funny you should mention Thoorin since he typed this literally yesterday. "Virtus.pro will still be considered the best team in CS:GO by many, including your author"
> 
> "https://gamurs.com/articles/thorins-csgo-top-10-world-rankings-21st-november-2016


We are not really talking about the best team this is why you're continuing this so much because I don't really care who the best team is (it varies every year), its all opinion based until specific standards regulate definitive values.

All of VP use a SteelSeries which you were making a point about the Zowie, which none of them use anymore.

Thorins #1 Pick Team SK - Zowie
Thorins #2 Pick Team VP - SteelSeries

That's all. TLDR Zowie update your mice pls


----------



## plath

damn i never knew my ninox aurora was so sick. wanted to upgrade to a g pro but seems less of a upgrade now.


----------



## Alya

Quote:


> Originally Posted by *subsoul*
> 
> GuardiaN has a custom franken mouse too due to the high click latency on his mouse but I am saying it does make a difference its just your luck if your hand adjusts properly.


Nope.

Kinzu v1 has 0.9ms click delay, even the first page says this, and that is the mouse that GuardiaN uses. SS Kinzu v1 Sudden Attack, 400 CPI (actually ~515), 500Hz polling rate.



Sources:
http://wiki.teamliquid.net/counterstrike/GuardiaN
https://docs.google.com/spreadsheets/d/1UaM765-S515ibLyPaBtMnBz7xiao0HL5f-F1zk_CSF4/edit
http://www.hltv.org/forum/571445-kinzu-v1-accel-problem
https://www.facebook.com/CSGuardiaN/posts/609304055805837


----------



## realistic01

Quote:


> Originally Posted by *Alya*
> 
> Nope.
> 
> Kinzu v1 has 0.9ms click delay, even the first page says this, and that is the mouse that GuardiaN uses. SS Kinzu v1 Sudden Attack, 400 CPI (actually ~515), 500Hz polling rate.


Theres something about the Kinzu v1 the smoothing and the accel combination - like its so bad its good? I've hit some flicks with deagle and awp that I can't believe.


----------



## Alya

Quote:


> Originally Posted by *realistic01*
> 
> Theres something about the Kinzu v1 the smoothing and the accel combination - like its so bad its good? I've hit some flicks with deagle and awp that I can't believe.


There's zero smoothing on sensors made by STMicroelectonics, but the accel is very nice and I have an ongoing project to revive it for other mice, it's not perfect but I'm getting close.


----------



## realistic01

Quote:


> Originally Posted by *Alya*
> 
> There's zero smoothing on sensors made by STMicroelectonics, but the accel is very nice and I have an ongoing project to revive it for other mice, it's not perfect but I'm getting close.


Sorry didnt mean smoothing - correction instead.


----------



## Alya

Quote:


> Originally Posted by *realistic01*
> 
> Sorry didnt mean smoothing - correction instead.


You're right, it was definitely there but very mild, close enough to near non-existent on my Gigantus because of the jitter though, I need to play with Povo's driver and figure out how strong the angle snapping actually was.


----------



## TurricanM3

Did anyone test the M65 Pro RGB with latest firmware? Can't find a test.


----------



## badben25

Quote:


> Originally Posted by *TurricanM3*
> 
> Did anyone test the M65 Pro RGB with latest firmware? Can't find a test.


It's probably the same as the rest of Corsair's record so far, so if you care about the click latency stay away.


----------



## 508859

Judging from my past experience as a part of pro CS scene.

Teams on that level wins because of the following factors:
Tournament experience
Team play and communication
Preparation to opponents and maps individually (including whole strategic aspect, map drafting)
Positioning and movement skills
Mechanical aim (hand-eye coordination and reaction) of the players

The last one is not the most important and not defining. All pro players have mechanical skill significantly above average and top20 team's players might have a better reaction than particular NIP or SK players (its not even linear within each team, with some people being not bright at all). Otherwise, team of 25yo (updated from 16) nolifers would be dominant in the field.
It might surprise you, but significant part of CSGO pro players do not pay any attention to what sensor mouse use or button latency. They don't care, they would be satisfied by anything among 30 decent mice, if they "feel" it works good and shape is ok. There is also a part of players who pay attention, deeply care about technical aspect and trying to do the best to improve results.
From my personal experience, players with naturally good reaction cared the least, because they were dominating everyone even with wooden ball mouse.

But still, you cannot say, that if #10 team would all switch to best mouse (latency wise) they would be moving up the ranks. Overall impact of this "improvement" is not significant enough; how well you slept, your blood pressure, your hormones, your hydration will impact your mechanical skill much more than what is being discussed in this thread.


----------



## furywins

Quote:


> Originally Posted by *numberfive*
> 
> Judging from my past experience as a part of pro CS scene.
> 
> Teams on that level wins because of the following factors:
> Tournament experience
> Team play and communication
> Preparation to opponents and maps individually (including whole strategic aspect, map drafting)
> Positioning and movement skills
> Mechanical aim (hand-eye coordination and reaction) of the players
> 
> The last one is not the most important and not defining. All pro players have mechanical skill significantly above average and top20 team's players might have a better reaction than particular NIP or SK players (its not even linear within each team, with some people being not bright at all). Otherwise, team of 16yo nolifers would be dominant in the field.
> It might surprise you, but significant part of CSGO pro players do not pay any attention to what sensor mouse use or button latency. They don't care, they would be satisfied by anything among 30 decent mice, if they "feel" it works good and shape is ok. There is also a part of players who pay attention, deeply care about technical aspect and trying to do the best to improve results.
> From my personal experience, players with naturally good reaction cared the least, because they were dominating everyone even with wooden ball mouse.
> 
> But still, you cannot say, that if #10 team would all switch to best mouse (latency wise) they would be moving up the ranks. Overall impact of this "improvement" is not significant enough; how well you slept, your blood pressure, your hormones, your hydration will impact your mechanical skill much more than what is being discussed in this thread.


I think a lot of people underestimate the significance of personal preference (or habitual preferences). If you use the same equipment time and time again, you're going to form an attachment to it, regardless of its technical specifications. It's just a result of our brains compartmentalizing sensory information to be more efficient at processing it. That's why if you look at pro mouse preferences over time, the one constant is the mouse shape. Hell, forget CS, you can find examples of this in any field.

I also think a lot of people lack experience with CS, which is why it results in a lot of these conversations. Most people just look at highlights and think that aim is all about flicking and clicking heads. They ignore all the things that the player (or their team) did to put themselves in that situation. When people talk about Niko, they rarely talk about the amount of preparation and the groundwork he goes through just to peek an angle. They also ignore that these individual habits are also the result of playing with a very low sensitivity. Another example is Shroud or ScreaM where people rarely talk about their impeccable strafing and movement. Instead, they see all these clips and think it must be the mouse or the equipment that they use.

Although, I do believe that to a certain extent that preferences are normally distributed and that having settings/equipment closer to the median of the pro scene can improve your gameplay. However, there are diminishing and confounding effects that people don't realize. For instance, I think a player with outlying sensitivity can improve by decreasing/increasing their sensitivity to be within a certain interval of the median pro sensitivity. Or things like buying a 120hz+ monitor and having high, stable frames. However, once you're within that interval, the effect diminishes and your time/$$$ can be better spent elsewhere.


----------



## chr1spe

Quote:


> Originally Posted by *numberfive*
> 
> JOtherwise, team of 16yo nolifers would be dominant in the field.


Why? From everything I've read reaction times peak in the early to mid twenties and don't degrade much until the early thirties. On average a 30 year old probably has the same reactions as a 16 year old, but a 25 year old should be slightly better. At that age your brain and body are still developing.


----------



## 508859

Quote:


> Originally Posted by *chr1spe*
> 
> Why? From everything I've read reaction times peak in the early to mid twenties and don't degrade much until the early thirties. On average a 30 year old probably has the same reactions as a 16 year old, but a 25 year old should be slightly better. At that age your brain and body are still developing.


Yep, seems you are right.

_*Age*. Reaction time shortens from infancy into the late 20s, then increases slowly until the 50s and 60s, and then lengthens faster as the person gets into his 70s and beyond (Welford, 1977; Jevas and Yan, 2001; Luchies et al., 2002; Rose et al., 2002)
_

http://www.humanbenchmark.com/tests/reactiontime/statistics
difference between good and bad reaction times good be like 150+ms. 10ms from mouse clicks will not give enough leverage


----------



## chr1spe

Quote:


> Originally Posted by *numberfive*
> 
> Yep, seems you are right.
> 
> _*Age*. Reaction time shortens from infancy into the late 20s, then increases slowly until the 50s and 60s, and then lengthens faster as the person gets into his 70s and beyond (Welford, 1977; Jevas and Yan, 2001; Luchies et al., 2002; Rose et al., 2002)
> _
> 
> http://www.humanbenchmark.com/tests/reactiontime/statistics
> difference between good and bad reaction times good be like 150+ms. 10ms from mouse clicks will not give enough leverage


I think that website uses statistics they collect themselves though which means monitor, mouse, etc are all convoluted in to that. My reaction times changed by something like 50 ms according to that site going from an awful corsair mouse and 75hz monitor to a logitech mouse and 144hz 1ms monitor.


----------



## 508859

Quote:


> Originally Posted by *chr1spe*
> 
> I think that website uses statistics they collect themselves though which means monitor, mouse, etc are all convoluted in to that. My reaction times changed by something like 50 ms according to that site going from an awful corsair mouse and 75hz monitor to a logitech mouse and 144hz 1ms monitor.


Yes, they do, it is just an example of the median times and some statistics, scientifically it's not that great . But switching from 75hz to 144hz will give you 1-7ms and switching between mouses will be 10-15ms tops. It does not account for your 50ms difference.


----------



## chr1spe

Quote:


> Originally Posted by *numberfive*
> 
> Yes, they do, it is just an example of the median times and some statistics, scientifically it's not that great . But switching from 75hz to 144hz will give you 1-7ms and switching between mouses will be 10-15ms tops. It does not account for your 50ms difference.


Actually my corsair mouse had 12ms sampling of the buttons and a 24ms debounce time so on average it added over 20ms to my reaction time and made it inconsistent. Because of the low sampling it probably added 24-36 ms over a properly working 1000hz mouse with very little click latency and 30ms on average. Many people who aren't gamers are using 125 hz mice which may have terrible debouncing like that corsair just due to the low polling rate and not the mouse being ridiculous and not sampling the buttons at 1000hz even when the polling rate was 1000hz.

Also switching from 144hz to 75hz on a 144hz monitor should give you something like 3-4ms I think, but you have to consider older and cheaper monitors can have worse pixel response times. Also I don't know very much about monitors, but I think some of them may be slower at going from recieving a signal to actually trying to adjust pixels or whatever even if the display doesn't have to do scaling out anything. I could be wrong about that though. Also you have people taking that on phones and things and I have no clue how much time that adds. I'm pretty sure going from worst case to best case setup could probably change things over 100ms if we are talking about some really bad old lcd display and terrible mouse. I haven't seen many tests of office mice, but that corsair may be the worst gaming mouse available.

Edit: Well I tried it with my phone and averaged like 420ms with a min of 388ms lol. Last time I took it with my home computer I was in the 160s or 170s and as far as I remember I never got below 200 and was in the 210s and 220s with my old mouse and monitor. I'm out of town, but I still have the mouse and monitor and could do a direct comparison when I am home.


----------



## 508859

Disregard the mobile stuff, it is useless on this site.

I did few tries and averaged 205ms with lowest 175ms. Using 144hz and SS Kana v2 (12ms in the table), I'm 32 tho.


----------



## chr1spe

I was just trying to show that their results could be more a function of the device they are taken on than actual measure of reaction time. I'm sure other people have done that on their phone before which is included in thier stats and considering I can get anything from well below average to well above it a large portion of the varience may be due to what people are using.


----------



## badben25

Tested the Perixx MX-1000 vs a Kinzu v1 62010 and it trades blows; consistently 1.Xms more or less in 200 bump tests. The variation would have to be human error.

This was a surprise to me so I also tested it against G100s, WMO and Logitech G102. Same ballpark figures as earlier. It also didn't seem to have any quirks such as lmb+rmb issues. Nice mouse to play with as well, but can be a bit heavy for some.

I am quite surprised at the click latency result because it seems like just a rebadged factory mouse and I would've expected something like 15-20ms. Is someone else willing to test this mouse and verify these results? It's only about $15 on Amazon US / UK / Germany and you can still always return it.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *badben25*
> 
> because it seems like just a rebadged factory mouse .


It literally is.


----------



## cuad

Why does the FK1 have the same latency as the newer Zowie mice? I thought it was supposed to be worse.


----------



## dopeysparks

Quote:


> Originally Posted by *cuad*
> 
> Why does the FK1 have the same latency as the newer Zowie mice? I thought it was supposed to be worse.


Older FK1s were worse. If I recall correctly sometime around early to mid 2015 the FK1 latency was similar to all others.


----------



## subsoul

I'm sure I read somewhere the white logo versions of zowie mouses where the fastest.


----------



## notzi

Quote:


> Originally Posted by *subsoul*
> 
> I'm sure I read somewhere the white logo versions of zowie mouses where the fastest.


Like 2ms~ faster than benq ones.

The coating on benq versions, scroll wheel not getting stuck between the steps and randomly activating wins over the couple milliseconds of added latency. 16-step scroll wheel is is still not what i'd prefer, but better than a faulty one.


----------



## b0z0

https://youtu.be/wO22BuqLnYc

This guy Reckless Yuki is reviewing mice and checking input delay between mice.


----------



## badben25

Quote:


> Originally Posted by *cuad*
> 
> Why does the FK1 have the same latency as the newer Zowie mice? I thought it was supposed to be worse.


The first batches of FK1 (black & yellow) had the older worser click latency. The later batches (also black & yellow) then had the improved click latency, which carried on to the black & white models as well as the Benq ones. Amongst the black & yellow FK1s the only way to differentiate is to test. Apparently there was a product/serial number change that can help determine but I do not have information for this, and would like to have if possible.

Quote:


> Originally Posted by *subsoul*
> 
> I'm sure I read somewhere the white logo versions of zowie mouses where the fastest.


Quote:


> Originally Posted by *notzi*
> 
> Like 2ms~ faster than benq ones.


Can you show me where this information is from? This is the first time I've heard this. I have doubts about this being true.


----------



## rainbowkitty

this thread really tells us how biased Rocketjumpninja is. He really likes rapoo v300, a mouse with 25 ms click latency. Too bad, i thought his mouse recommendation was really good until i see this thread.

Thanks for testing them for us


----------



## Maximillion

In his Top 40 roundup he said the V300 was plagued w/ issues and he likes it regardless (due to physical properties). It's #4 on his personal list and #25 as a recommendation. Not trying to overly defend the guy or say he's not "swayed" in some ways, but yeah. His ranking system is inconsistent from a pure technical standpoint, but at least he _decently_ explains why he likes/dislikes a certain product.


----------



## Alya

Quote:


> Originally Posted by *Maximillion*
> 
> In his Top 40 roundup he said the V300 was plagued w/ issues and he likes it regardless (due to physical properties). It's #4 on his personal list and #25 as a recommendation. Not trying to overly defend the guy or say he's not "swayed" in some ways, but yeah. His ranking system is inconsistent from a pure technical standpoint, but at least he _decently_ explains why he likes/dislikes a certain product.


He put a mouse that wasn't even released at (what would likely be) his #1, and iirc it has a 3320 and angle snapping so I'm just confused at that point.


----------



## Maximillion

Quote:


> Originally Posted by *Alya*
> 
> He put a mouse that wasn't even released at (what would likely be) his #1, and iirc it has a 3320 and angle snapping so I'm just confused at that point.


Oh I know. I mean he had the *XM300* at #2 overall at one point, which still blows my mind. I'm just stating that while he may be biased there's a clear distinction between what he'd actually use and what he "suggests" as the best mice for others.


----------



## Alya

Quote:


> Originally Posted by *Maximillion*
> 
> Oh I know. I mean he had the *XM300* at #2 overall at one point, which still blows my mind. I'm just stating that while he may be biased there's a clear distinction between what he'd actually use and what he "suggests" as the best mice for others.


I didn't disagree with you, I'm just confused at his list for the same reason as you, he contradicts it relatively often, but it seems to not be from a technical standpoint but rather from a shape/comfort standpoint...which is weird because he put the G403 at #1 in that case.


----------



## ryuiko

Hi there!
First time posting haha but I'm really curious of how you downgraded the g402 software? I remember upgrading the firmware one time but I didn't know it would increase button latency so I was hoping how I can go back?


----------



## uaokkkkkkkk

don't bother. rafa's g502 and g402 results were done with the mouse sensor facing the pad.

non liffoff state=2ms / liftoff state= 5ms


----------



## Xanatos

Are there differences between microswitches (Omron vs Huano) or is lag based on the MCU?


----------



## uaokkkkkkkk

Firmware value.


----------



## Ramla777

Would love to see the Razer Krait 2013 on this.


----------



## uaokkkkkkkk

I'm positive it's +9ms. Though I don't own one.


----------



## Asec

Since optical switches are slowly becoming more popular for mechanical keyboards (offering response times as low as 1 ms), I was wondering if/when this technology will appear in mice. Anyone have an idea? Would it improve the latency noticably? At least it should improve durability, right?
Looking forward to replies


----------



## wareya

Mice use three-pin switches already. That's enough to be able to implement zero-latency debouncing without any problems. The issue is that mouse manufacturers are lazy. Even if they *do* implement optical switches for m1/m2/etc, you won't actually see a benefit from it, because the people who write commercial mouse firmware are almost always unspeakably incompetent. The overwhelming majority of mice don't even wire up all three of the pins for m1/m2/etc switches because the way that 99%+ of mice do debouncing doesn't benefit from using all three pins.


----------



## uaokkkkkkkk

In my opinion it would just work better in keyboards in general as of right now.

Also in my experience, the LK switches A4tech use in their mice have pretty poor click feeling. It would need a bigger player in the industry to get me on board with that.


----------



## uaokkkkkkkk

Oh, I should've remembered sooner.

props to mr. t for digging this up...
*
Old Zowie: +16ms
New Zowie: +8ms*

Those values are the actual debounce value in the firmware.


----------



## Lolcarrots

Does the Corsair Sabre have the latency listed out of box without downloading any software? Does the Katar have lower latency without software/with a different firmware than the one that's listed or is it stuck at 16? What about the Harpoon?


----------



## uaokkkkkkkk

Katar, Harpoon, Sabre, Scimitar, M65 Pro are all the same. I really can't remember the case with the Sabre. That mouse was so forgettable.


----------



## badben25

Quote:


> Originally Posted by *Lolcarrots*
> 
> Does the Corsair Sabre have the latency listed out of box without downloading any software? Does the Katar have lower latency without software/with a different firmware than the one that's listed or is it stuck at 16? What about the Harpoon?


Don't keep any hopes with Corsair. If you care about click latency then it's a brand you should always avoid.


----------



## Lolcarrots

I need to use a corsair mouse


----------



## Nawafwabs

Rival 700???


----------



## vanir1337

Quote:


> Originally Posted by *Nawafwabs*
> 
> Rival 700???


You don't wanna use that anyways lol


----------



## badben25

Don't have any figures but SteelSeries have predictable results, so I think it would be safe to say 7-8ms.


----------



## Nawafwabs

Quote:


> Originally Posted by *vanir1337*
> 
> You don't wanna use that anyways lol


why??

whats best mouse do u think?


----------



## dansi

Scimitar Pro is good latency?


----------



## badben25

Quote:


> Originally Posted by *dansi*
> 
> Scimitar Pro is good latency?


Corsair = most likely not


----------



## senileoldman

Didn't know about this. So I went ahead and tested my g400s, g9x and CMStorm Inferno agasint my m705 in the humanbenchmark webpage someone linked. And I got very alike results.

Are you guys sure this isn't some placebo thing?

I don't see how 20 ms would matter in a game.Or at least to me, as I stopped playing fps since I was like 16 years old.

I used to play a lot Quake 4 and World. And I was a beast at them. Also played some CS 1.6 and rekt everybody in that game.

I still hear the cries of a thousand of poor souls that spent their entire lives playing those games to get good at it, while I just started and rekt them and their grandma's too.


----------



## Nawafwabs

I want mouse with low latency and good sensor

I have rival 700 ( high latency)


----------



## vanir1337

Quote:


> Originally Posted by *Nawafwabs*
> 
> I want mouse with low latency and good sensor
> 
> I have rival 700 ( high latency)


*ok*


----------



## sprite08

I want to add click latency of:

Roccat Kone Pure Military (on fw 1.12)


----------



## badben25

Quote:


> Originally Posted by *sprite08*
> 
> I want to add click latency of:
> 
> Roccat Kone Pure Military (on fw 1.12)


Do you mean you have a result or are you asking for it to be added?


----------



## sprite08

Quote:


> Originally Posted by *badben25*
> 
> Do you mean you have a result or are you asking for it to be added?


yes ! "asking for it to be added". Sorry for my bad English


----------



## MaTpr0F

I would like to request the latencies of the following mice:
Razer Lancehead
Ninox Venator (i know it's not out yet, but they seem quite communicative, maybe they will provide the info)

Many thanks!


----------



## badben25

Quote:


> Originally Posted by *sprite08*
> 
> yes ! "asking for it to be added". Sorry for my bad English


Quote:


> Originally Posted by *MaTpr0F*
> 
> I would like to request the latencies of the following mice:
> Razer Lancehead
> Ninox Venator (i know it's not out yet, but they seem quite communicative, maybe they will provide the info)
> 
> Many thanks!


Requesting for latency figures is not going to go far as I cannot add anything unless either me or another reliable OCN user gets those mice and takes the time to test them and particular firmware. I doubt I will be provided any mice, so we will have to wait for someone like uaokkk, qsxcv or Ino. I am sorry about that but I will always be active in case someone else posts the results.


----------



## Alya

List has an error, Zowie EC1/EC2 (non-eVo/CL, so the 3060 version) is 11ms, not 16ms.


----------



## Fred23

Somebody knows it how good in terms of click latency the Kingston HyperX Pulsefire? Seems to be a good rat for me, but I didn't read a detailed review yet.

I found something:

I know, this isn't a scientific evidence.

End of the story: click latency almost identical with the Razer Deathadder 2013 that was 6.3 at OCN:


----------



## Alya

Quote:


> Originally Posted by *Fred23*
> 
> End of the story: click latency almost identical with the Razer Deathadder 2013 that was 6.3 at OCN:


Wat? That's not a click delay measurement, that's just a graph showing how fast he can get the mouse to move to see if he could get it to malfunction.


----------



## Fred23

True.







This was from a test, where the tester declared that HyperX Pulsefire almost identical in latency with the Deathadder (2013) illustrated it with this picture that I copied quickly & incorrectly. As I see, this pic shows the Perfect Control Speed rather than anything else, but I am not so competent. You said this with other worlds, I think. But the tester could have moved the mouse more quickly, Pulsefire can 130 IPS (3,3m/s) by specs.

What is the correct latency value, who knows?


----------



## badben25

If I had to guess, it would fall somewhere like 10-15ms on the spreadsheet.

Since you're already interested in the mouse, and if you have the possibility to return it, maybe you could order it and test for us?


----------



## uaokkkkkkkk

So why exactly is the MX Master listed at 47ms?


----------



## Elrick

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> So why exactly is the MX Master listed at 47ms?


Weird because I use it sometimes within spread sheets and it doesn't seem slow when pressed multiple times within a few seconds.

It works like all the other mice models, so for all the normal's out there you can't detect a slow latency especially when doing work.


----------



## badben25

Quote:


> Originally Posted by *Alya*
> 
> List has an error, Zowie EC1/EC2 (non-eVo/CL, so the 3060 version) is 11ms, not 16ms.


That seems like conflicting info

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> So why exactly is the MX Master listed at 47ms?


Because that's the number I got from on here? Not sure what you mean.


----------



## chr1spe

Quote:


> Originally Posted by *badben25*
> 
> That seems like conflicting info
> Because that's the number I got from on here? Not sure what you mean.


I'm pretty sure that is the release debounce time if it is anything. IIRC Logitech uses the asymmetric type of debouncing like on their gaming mice even on their office mice, but with longer times. Their gaming mice are a few ms on press and ~20ms on release while their office mice are ~50ms on release. Not sure what the actual press debounce is on their office mice though. Could even be wrong about all of that, but I seem to vaguely remember that being the case.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *badben25*
> 
> That seems like conflicting info
> Because that's the number I got from on here? Not sure what you mean.


Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Got a friend to test a MX Master I gifted him last year. *47ms release delay was the lowest value the program returned.*


Yeah?


----------



## badben25

Quote:


> Originally Posted by *chr1spe*
> 
> I'm pretty sure that is the release debounce time if it is anything. IIRC Logitech uses the asymmetric type of debouncing like on their gaming mice even on their office mice, but with longer times. Their gaming mice are a few ms on press and ~20ms on release while their office mice are ~50ms on release. Not sure what the actual press debounce is on their office mice though. Could even be wrong about all of that, but I seem to vaguely remember that being the case.


Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Yeah?


Thanks for the feedback guys. I'll update the spreadsheet. Will have to remove the entry for now.


----------



## Alya

Quote:


> Originally Posted by *badben25*
> 
> That seems like conflicting info
> Because that's the number I got from on here? Not sure what you mean.


Not sure where you got the idea that it was conflicting info from, I own one and have done the test multiple times against my Kinzu and with qsxcv's button delay program, it's locked at 10.9ms lowest.


----------



## badben25

Because the number came from multiple posts on older threads, and my own tests on an EC2 blue edition were the same. You might have something interesting on your hands. Could it have to do with batches?


----------



## tashcz

Which software is used for this testing?

And also, can anyone add ROG Gladius 2? I wonder if it's improved.


----------



## uaokkkkkkkk

You can adjust Gladius 2's debounce setting in the Armoury software.
Quote:


> Creative SoundBlasterX Siege M04 4.7 fw12 2ms with fw9


fw12 value = fw9 value


----------



## Alya

Quote:


> Originally Posted by *badben25*
> 
> Because the number came from multiple posts on older threads, and my own tests on an EC2 blue edition were the same. You might have something interesting on your hands. Could it have to do with batches?


That's bizarre, if you have an EC2 blue then I can give you the product S/N, might be related to batches or something, I can also provide some click delay tests for you if you're interested.


----------



## tashcz

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> You can adjust Gladius 2's debounce setting in the Armoury software.
> fw12 value = fw9 value


Could you please explain that a bit more to me? What's debounce? Will it lower click latency? I've got about few hours to decide whether to go with Gladius 2 or DA Elite. I'm biased towards Asus for a long time, and I don't like Razer products that much. Overall, they seem similar but the Gladius 2 looks prettier to me, also owns the 3360 sensor. Will I make a mistake going for it? A oppinion would be greatly appreciated.

Thanks!


----------



## tashcz

Okay I've read a bit about it. Seems like 8ms is the least you can set. Is that acceptable? Does the DA have that inside the firmware, which works better?


----------



## uaokkkkkkkk

No. Gladius 2 is 4ms-32ms. Gladius 1 is 4ms-32ms(mislabeled as 8ms-32ms in software)


----------



## tashcz

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> No. Gladius 2 is 4ms-32ms. Gladius 1 is 4ms-32ms(mislabeled as 8ms-32ms in software)


Is that acceptable for FPS? I'm sorry, it's been a while since I bought a mouse, my last serious one was the mx518. How does the 4ms setting compare to the DA elite? I'm trying not to make a bad choice today.


----------



## uaokkkkkkkk

What I consider acceptable for fps doesn't mean it is or has to be acceptable or vice versa. You'll get by somehow.

If I have to give an opinion...I'll arbitrarily pick 4ms as the maximum. Why? Because that was the 2004 Diamondback's debounce value.


----------



## tashcz

Thank you, I appreciate your oppinion regarding all the testing on mice you've performed.

In your oppinion, again, would you go with the DA Elite or the Gladius 2? I've read that you'd never buy another Asus mouse once you tried the Sica, but as I see they've adjusted a few things now.


----------



## uaokkkkkkkk

I'd personally choose the Gladius 2. Because I can open it up easily. Which means I can easily reduce the weight if I wanted to. Then there's the rear portion of the mouse(rog logo part) that can be removed. With that removed, it becomes the first ergonomic mouse I can actually stand to use.

I doubt any of those personal preferences would apply to you. But if you do get the Gladius II, if you want, you can order various switches off the internet and play around with that? It(Gladius II) is quite expensive though. Overpriced actually.

Despite branding Deathadder Elite and Gladius II come from the same manufacturer.

.....

Unrelated, but once the Pugio gets discounted I'm going to scoop one up. That's the one that actually interests me out of the current ROG mouse lineup.


----------



## tashcz

Then Gladius 2 it is. I've used a CM Storm Sentinel Advance 2 which is 140g! so I don't think the weight would be a problem. I wouldn't even switch from it but it started producing coil whine on my motherboard for some reason. Other mice I had didn't do it, but I really want a mouse I can adopt to and use it every day and get a really good feel of it, make it a part of my hand. Just got way tired of lots of bad choices after the mx518 and now I've got a cashback from a returned watercooler that I'm gonna spend on a mouse and an SD card.

Here, the price of the Gladius 2 is ~80EUR/85$ while the DAE is ~75EUR/80$. So it's not a big difference. If there were Logitech mice available where I'm getting this I'd probably go with the G403 or G402, but unfortunatly I don't have that option.

I'd just like to ask you to explain me some stuff, if you have spare time to do so. I've googled but can't seem to find the answer, seems like you're all hardcore out here









The setting adjustable in the Armoury is the ms value of registering a click, or a value that decides whether I removed my finger off the switch and then put it back on? Like 1 for the finger on and 0 on the finger of, so it's 1-0-1? Two clicks would take about 12ms give or take in perfect condition (not that it's physicly possible). But is that 4ms also the time till it registers the first time I clicked the switch?


----------



## KulaGGin

What about input latency of Arduino Leonardo?

I ordered Arduino Leonardo yesterday for my little home project. They say it is recognized as mouse and keyboard by default on Windows. So I was wondering what if in the future I wanted to make my own mouse based on Arduino, how fast Arduino actually is compared to all of these mainstream mouses(could be easily faster than all of them, right?)?
I'll probably test it myself in the future and compare it to my Logitech G502, but right now I'm wondering if someone else already know.


----------



## chr1spe

Quote:


> Originally Posted by *KulaGGin*
> 
> What about input latency of Arduino Leonardo?
> 
> I ordered Arduino Leonardo yesterday for my little home project. They say it is recognized as mouse and keyboard by default on Windows. So I was wondering what if in the future I wanted to make my own mouse based on Arduino, how fast Arduino actually is compared to all of these mainstream mouses(could be easily faster than all of them, right?)?
> I'll probably test it myself in the future and compare it to my Logitech G502, but right now I'm wondering if someone else already know.


It all depends on how you code the debouncing.


----------



## KulaGGin

Quote:


> Originally Posted by *chr1spe*
> 
> It all depends on how you code the debouncing.


https://www.arduino.cc/en/Tutorial/Debounce
https://www.arduino.cc/en/Reference/MousePress

Well, what if I didn't code debouncing(for testing raw input latency of Arduino itself), something like this:



Code:



Code:


const int LButtonPin = 2;

void loop() {
    int reading = digitalRead(LButtonPin);

    if(reading == HIGH){
         Mouse.press();
    } else if (reading == LOW) {
         Mouse.release();
    }    
}

I would be interested only in minimum and maximum latency of the first press, it doesn't matter how badly it glitches out(switch presses and releases of the button) later on because of the mechanical and physical issues.

I haven't worked with Arduino myself yet, so I don't really know anything about it. And I haven't really seen any MIY mices based on Arduino.
Another reason why I would like to test Arduino as a mouse is because of this thread(8000Hz mouse overclocking). I would like(just as a hobby) to use PCB with minimum input lag possible nowadays(Arduino?) and which can be overclocked to that 8000 Hz.

AFAIK there is no mouse on the market with 10 buttons+ on board(like G502, for example), PMW3366 sensor, very low click/input latency and which can be overclocked to 8000 Hz.


----------



## chr1spe

Quote:


> Originally Posted by *KulaGGin*
> 
> https://www.arduino.cc/en/Tutorial/Debounce
> https://www.arduino.cc/en/Reference/MousePress
> 
> Well, what if I didn't code debouncing(for testing raw input latency of Arduino itself), something like this:
> 
> 
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> const int LButtonPin = 2;
> 
> void loop() {
> int reading = digitalRead(LButtonPin);
> 
> if(reading == HIGH){
> Mouse.press();
> } else if (reading == LOW) {
> Mouse.release();
> }
> }
> 
> I would be interested only in minimum and maximum latency of the first press, it doesn't matter how badly it glitches out(switch presses and releases of the button) later on because of the mechanical and physical issues.
> 
> I haven't worked with Arduino myself yet, so I don't really know anything about it. And I haven't really seen any MIY mices based on Arduino.
> Another reason why I would like to test Arduino as a mouse is because of this thread(8000Hz mouse overclocking). I would like(just as a hobby) to use PCB with minimum input lag possible nowadays(Arduino?) and which can be overclocked to that 8000 Hz.
> 
> AFAIK there is no mouse on the market with 10 buttons+ on board(like G502, for example), PMW3366 sensor, very low click/input latency and which can be overclocked to 8000 Hz.


If you don't do any debouncing the delay will be extremely low regardless of what you use unless you are using something drastically wrong for trying to make a mouse. It really shouldn't matter what mcu or diy platform you use. Arduino vs Teensy vs whatever else really shouldn't matter. What will matter is how you program the debouncing.

Edit: Just to be clear though the debouncing example from Arduino would have a horrible 50ms delay.


----------



## KulaGGin

Quote:


> Originally Posted by *chr1spe*
> 
> If you don't do any debouncing the delay will be extremely low regardless of what you use unless you are using something drastically wrong for trying to make a mouse.


Ok, I see.
Quote:


> Originally Posted by *chr1spe*
> 
> It really shouldn't matter what mcu or diy platform you use. Arduino vs Teensy vs whatever else really shouldn't matter. What will matter is how you program the debouncing.


Ok. But what are the real latencies for all of these mouses on the test? All of these tests on the first page are relative to SS Ikari and don't tell us actual latencies. But I'm just wondering what's the actual delay of PCBs of these mouses(and now about Arduino in particular). Debouncing time included and excluded.

Without debouncing, what's the input latency time(from the moment of a key press to the moment when electrons reach end of the USB cable - PC's USB socket) of Arduino ? <1ms? 5ms?


----------



## gipetto

Quote:


> Originally Posted by *KulaGGin*
> 
> Ok, I see.
> Ok. But what are the real latencies for all of these mouses on the test? All of these tests on the first page are relative to SS Ikari and don't tell us actual latencies. But I'm just wondering what's the actual delay of PCBs of these mouses(and now about Arduino in particular). Debouncing time included and excluded.
> 
> Without debouncing, what's the input latency time(from the moment of a key press to the moment when electrons reach end of the USB cable - PC's USB socket) of Arduino ? <1ms? 5ms?


I built an arduino pro micro adns3050 based mouse from a kit here https://github.com/Tom101222/Adns-3050-Optical-Sensor. i found it unreliable due to wires tending to break. I removed the debouncing period by replacing it with a state machine. although i lost the source code in a hard drive crash, I kept the state machine code for a pmw3360 version, which I never tested. https://yadi.sk/d/fAuWBnWP3KtmV6

edit I found the adns3050 code here https://pastebin.com/F22uM0d0


----------



## Soo8

Nixeus Revel(beta firmware ver10-20-2016) - Left button
Mionix Castor(old hardware revision, v0.16 beta firmware, 0ms latency option) - Right button
Not a bump test. Actually soldered some wires and a switch together.


Looks like they finally fixed the latency on the old Castor.


----------



## SmashTV

Looks like ample room for improvement on the Revel. Maybe Peter can wave the wand and make it happen.


----------



## b0z0

Has anyone tested the sensei and rival 310 yet?


----------



## senileoldman

Quote:


> Originally Posted by *sprite08*
> 
> yes ! "asking for it to be added". Sorry for my bad English


Last I remember it was around DA 2013's latency, 4.5ms/6ms; no more than that.


----------



## Avalar

Quote:


> Originally Posted by *b0z0*
> 
> Has anyone tested the sensei and rival 310 yet?


Yus, pretty please anyone.

I've used both, though. Neither were noticeably slower than any Logitech mouse I've used, for example.


----------



## uaokkkkkkkk

If you owned them, you could have just done the tap test.


----------



## chr1spe

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> If you owned them, you could have just done the tap test.


People seem really lazy about doing that. I linked your thread and asked someone to do it in the main rival/sensei 310 thread and nobody did it.


----------



## roz133

Did the bump test on the Sensei 310, 7.8ms slower than my scream 1.

Anyone know how to revert to fw90.0.14 on the g402? I was trying out the g402 again and noticed that it is now slower than the scream 1 while earlier it was faster on the bump test and then saw this on the table. "Logitech Logitech G402 1.5 fw90.0.14 fw90.2.17 starts higher latency"

Any help would be appreciated.


----------



## badben25

Quote:


> Originally Posted by *roz133*
> 
> Did the bump test on the Sensei 310, 7.8ms slower than my scream 1.


For now I'm going to include this number, will update when I get something more thorough.


----------



## Offler

Did anyone tested PS/2 vs USB?

Just out of curiosity... I prefer to have PS/2 mouse and keyboard. In case of keyboard its because of no shadowing. In case of mouse its way how it uses its own IRQ, and its indepentent on CPU...

btw... I might test my old Logitech MX 518 just because its one of the first gaming mouse... (No idea what to expect, its basically 12 years old mouse)

Edit: Just tested Keyresponse PK. does work with PS/2, but results given say much more about MY response time than of mouse...


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *chr1spe*
> 
> People seem really lazy about doing that. I linked your thread and asked someone to do it in the main rival/sensei 310 thread and nobody did it.


Now that at least the Rival 310 is at Best Buy, I briefly considered picking one up and doing it myself. I decided against it though. It's not worth the gas.


----------



## SmashTV

Quote:


> Originally Posted by *roz133*
> 
> Did the bump test on the Sensei 310, 7.8ms slower than my scream 1.
> 
> Anyone know how to revert to fw90.0.14 on the g402? I was trying out the g402 again and noticed that it is now slower than the scream 1 while earlier it was faster on the bump test and then saw this on the table. "Logitech Logitech G402 1.5 fw90.0.14 fw90.2.17 starts higher latency"
> 
> Any help would be appreciated.


Latency change is only for lifted off state if I recall correctly.


----------



## roz133

Quote:


> Originally Posted by *SmashTV*
> 
> Latency change is only for lifted off state if I recall correctly.


Could you explain? I don't quite understand


----------



## senileoldman

Quote:


> Originally Posted by *roz133*
> 
> Did the bump test on the Sensei 310, 7.8ms slower than my scream 1.
> 
> Anyone know how to revert to fw90.0.14 on the g402? I was trying out the g402 again and noticed that it is now slower than the scream 1 while earlier it was faster on the bump test and then saw this on the table. "Logitech Logitech G402 1.5 fw90.0.14 fw90.2.17 starts higher latency"
> 
> Any help would be appreciated.


Scream1 clicks are super light, from what I've heard. That may change the results a bit when doing the bump test.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *roz133*
> 
> Could you explain? I don't quite understand


Logitech gaming mice, G502 and onward, all have a silly undocumented feature that adds a 2-3ms debounce delay whenever the sensor is in a liftoff state.

So when the mouse is on the pad, it's ~2-3ms. When lifted it's ~4-5ms.

Sorta related, but anyone know if logi ever fixed the broken dpi steps on the G402?


----------



## Melan

No, they didn’t.


----------



## roz133

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Logitech gaming mice, G502 and onward, all have a silly undocumented feature that adds a 2-3ms debounce delay whenever the sensor is in a liftoff state.
> 
> So when the mouse is on the pad, it's ~2-3ms. When lifted it's ~4-5ms.
> 
> Sorta related, but anyone know if logi ever fixed the broken dpi steps on the G402?


Not sure if I understand this right. Just tried the bump test again with the sensor blocked off and got the exact same results. This should prevent the sensor from going into lifted off state right?


----------



## daniel0731ex

Question, is the approach used in this utility:

http://blog.seethis.link/scan-rate-estimator/

useful in any way for a simplistic estimation of click debounce?


----------



## Offler

Quote:


> Originally Posted by *daniel0731ex*
> 
> Question, is the approach used in this utility:
> 
> http://blog.seethis.link/scan-rate-estimator/
> 
> useful in any way for a simplistic estimation of click debounce?


I see it somehow useful for the keyboard topics. Might help to tell you if you purchased quality keyboard or a fake if the bounce rate would be taking too much time.

In my case 13ms means PS/2 keyboard polling rate 80hz, regardless I have Cherry MX mechanical switches. So i am looking for some outdated software to get polling rate to 100 or 200hz.

But again in many cases you would get your own speed.

Edit: Ok, apparenlty my old Mx518 connected over PS/2 port has dpi up to 1800, and polling rate for PS2 is atm 200Hz. In Keyresponse PK 140ms, which is mostly my reaction time. Not bad for an old grandpa mouse...


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *daniel0731ex*
> 
> Question, is the approach used in this utility:
> 
> http://blog.seethis.link/scan-rate-estimator/
> 
> useful in any way for a simplistic estimation of click debounce?


You actually picked quite a good day to post that.


----------



## Jeppi

Is there any information of the Rival 110 yet?


----------



## raad11

What's the best firmware for the G403 wired?

Anyone test the Rival 310 yet? I have one. If someone can explain to me how to test it, I will. I also have a G403, a Nixeus Revel, and a Ventus X RGB Optical.


----------



## SmashTV

Quote:


> Originally Posted by *raad11*
> 
> What's the best firmware for the G403 wired?


Always the latest one.


----------



## JackCY

108.1.12 and that's what has been there since I bought it, no updates available and I don't think any are needed at all, no issues.


----------



## Viperl00

Anyone tested the Finalmouse Ergo 2 @1000hz yet?


----------



## gregwx

I'm glad to see the underdog joining to the list : Ventus R such a great little lightweight mouse. If some one is searching for an G100s or Abyssus alternative, you will be suprised: http://www.overclock.net/t/1634924/thoughts-on-thermaltake-ttesports-ventus-r/30


----------



## thrillhaus

Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> Logitech gaming mice, G502 and onward, all have a silly undocumented feature that adds a 2-3ms debounce delay whenever the sensor is in a liftoff state.
> 
> So when the mouse is on the pad, it's ~2-3ms. When lifted it's ~4-5ms.


That's actually a brilliant way of fixing the accidental click when lifting and bringing mouse back down, without increasing regular debounce too much.

In other news it seems Bloody has taken the bump testing software off their site... maybe they were paid a visit by the Zowie goons.


----------



## he4th

is there any mouse as good as or better than g403 that runs at faster ms. I'm considering a WMO upgrade and have already ruled out Zowie (due to tape trick doing the same) and Razer (due to deathadder shape not being to my liking. I see that 4th option is perhaps Ninox brand and they have new mouse on the way but any other mice faster than g403 any good?


----------



## gene-z

Quote:


> Originally Posted by *thrillhaus*
> 
> That's actually a brilliant way of fixing the accidental click when lifting and bringing mouse back down, without increasing regular debounce too much.
> 
> In other news it seems Bloody has taken the bump testing software off their site... maybe they were paid a visit by the Zowie goons.


It's still there:

http://www.bloody.com/en/download.php

Download the app called KeyResponse PK.


----------



## majkool

If these tests were done with application KeyResponsePK by Bloody and by just bumping the buttons on mice I can say that tests are not even good because latency is very different when you bump buttons in different place of button.

Tested it with Zowie ZA12 and DreamMachines DM1 Pro S.

Test should be done on opened mice just on switches.


----------



## badben25

Majority of these tests were done on mice disassembled with switches wired up directly, thanks to the work of users such as uaokkkkk, qsxcv, rafa


----------



## 2shellbonus

Quote:


> Originally Posted by *majkool*
> 
> If these tests were done with application KeyResponsePK by Bloody and by just bumping the buttons on mice I can say that tests are not even good because latency is very different when you bump buttons in different place of button.
> 
> Tested it with Zowie ZA12 and DreamMachines DM1 Pro S.
> 
> Test should be done on opened mice just on switches.


It rather depends on button stiffness. So to compensate for that, you really have to slam the mice together. Will yield the most consistent results from a bump test. Obviously wiring the switches is the more scientific and correct way of doing it.


----------



## CougarGaming

Dear all,

We have received feedback from some users pointing to this chart. Could we know the software that is being used to calculate these numbers? Our tests consistently give fairly different results and we'd like to replicate these. Our current testing, and our eSports teams seem to have no issues using our new gaming mice in national and international competitions, but we care about user feedback and would like to learn more abou tit.


----------



## thrillhaus

Quote:


> Originally Posted by *CougarGaming*
> 
> Dear all,
> 
> We have received feedback from some users pointing to this chart. Could we know the software that is being used to calculate these numbers? Our tests consistently give fairly different results and we'd like to replicate these. Our current testing, and our eSports teams seem to have no issues using our new gaming mice in national and international competitions, but we care about user feedback and would like to learn more abou tit.


Care to share the debounce time in your firmware? It would make it clear in that case what the intended latency is.


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *CougarGaming*
> 
> Dear all,
> 
> We have received feedback from some users pointing to this chart. Could we know the software that is being used to calculate these numbers? Our tests consistently give fairly different results and we'd like to replicate these. Our current testing, and our eSports teams seem to have no issues using our new gaming mice in national and international competitions, but we care about user feedback and would like to learn more abou tit.


You are better off just asking the factory. Whatever they say the firmware value is set at, that's it.


----------



## CougarGaming

Of course we can. 8ms for most of our newer models.


----------



## CougarGaming

Thanks for the suggestion







We of course know the values we set at our factories, our question is regarding the table on the first page of this thread. The results these users obtained are quite different from what we got; we want to look into this.


----------



## uaokkkkkkkk

The old stuff was +16ms, new stuff is +8ms.

lol "our"


----------



## thrillhaus

Quote:


> Originally Posted by *CougarGaming*
> 
> Thanks for the suggestion
> 
> 
> 
> 
> 
> 
> 
> We of course know the values we set at our factories, our question is regarding the table on the first page of this thread. The results these users obtained are quite different from what we got; we want to look into this.


The common "quick review" methodology is to have users do the Bloody KeyResponse PK "bump test" https://www.bloody.com/en/download.php

It involves hitting the RMB of one mouse against the LMB of another. It's not the most precise but if you do it right you can usually get a comparison that's accurate within 1ms, which is good enough for a general idea.

However there are also users who have tested by wiring the PCB of two mice together to one switch.

The compilation in the OP of this thread seems to be collected from both types of tests, whenever a user posts a test result of a new mouse.


----------



## CougarGaming

Quote:


> Originally Posted by *thrillhaus*
> 
> The common "quick review" methodology is to have users do the Bloody KeyResponse PK "bump test" https://www.bloody.com/en/download.php
> 
> It involves hitting the RMB of one mouse against the LMB of another. It's not the most precise but if you do it right you can usually get a comparison that's accurate within 1ms, which is good enough for a general idea.
> 
> However there are also users who have tested by wiring the PCB of two mice together to one switch.
> 
> The compilation in tthe OP of this thread seems to be collected from both types of tests, whenever a user posts a test result of a new mouse.


Thank you for the confirmation regarding the software







. For some reason our results using those same tools don't match the ones displayed on the table, but we'll keep looking into this.


----------



## thrillhaus

Quote:


> Originally Posted by *CougarGaming*
> 
> Thank you for the confirmation regarding the software
> 
> 
> 
> 
> 
> 
> 
> . For some reason our results using those same tools don't match the ones displayed on the table, but we'll keep looking into this.


No problem. If you'd like to send me your product line for retesting, I can do that too.


----------



## uaokkkkkkkk

Oh, I guess it was +14ms and not +16ms for the original Revenger(Cougar 580m).
Quote:


> Originally Posted by *uaokkkkkkkk*
> 
> edit: soldered on power cable. classy.
> 
> The Cougar Revenger is probably Dexin 14ms. I haven't even checked the output yet, all I needed to do was plug it in and tap the right button lightly.
> 
> ...
> 
> lol


Quote:


> ...or more specifically I'm never touching a Cougar branded product again.


Oops~


----------



## vanir1337

CM MM520 was roughly +2.4 ms average compared to a Ninox Venator, so it should be around +6.9 ms.
Not that accurate though, but most of the time there were 1.9 and 2.9 ms differences between the two, in favor of the Venator.


----------



## RevanCorana

Did they improve the clicks on the EC2-B ?


----------



## Leviathantony

Buy a ec 2 b and try for yourself!!!


----------



## thrillhaus

G203s were on sale for filthy cheap so I bought one for its sweet innards. I can also confirm that the Logitech debounce times are ~3ms higher when the mouse is not touching a surface, so in practice the newer editions perform just as good as their old stuff. This should probably be noted in the OP.


----------



## Avalar

Quote:


> Originally Posted by *thrillhaus*
> 
> I can also confirm that the Logitech debounce times are ~3ms higher when the mouse is not touching a surface...


How does this even happen...?


----------



## uaokkkkkkkk

Quote:


> Originally Posted by *Avalar*
> 
> How does this even happen...?


Three years ago, someone made a conscious decision to code in that feature?


----------



## thrillhaus

Quote:


> Originally Posted by *Avalar*
> 
> How does this even happen...?


I believe it's intended as a way to eliminate accidental double click when lifting and bring the mouse back down, without actually increasing normal in use latency. All the firmware has to do is read if the sensor is picking up a usable signal.


----------



## muso

I don't believe that the sensei 310 is correct. RJN tested against a 703. i've also tested against a gpro and g900 and its getting similar times. 

https://youtu.be/2E7RA-m9gm4?t=213


----------



## cdcd

"tested"


----------



## Aliandro1d

RJN posts should be banned from here and this is why ^^


----------



## Avalar

FM Ultralight?


----------



## vanir1337

CM MasterMouse MM530 +8.3 ms

+3.8 ms compared to a Ninox Venator black.
Average of 20 bumps, no outstanding values.


----------



## uaokkkkkkkk

lol bump testing


----------



## KulaGGin

lol, what's the problem to solder or twist wires up together?


----------



## ewiggle

So about this list, I'm not getting the same numbers.

Here's what I got: My Ventus R goes down to only 4ms, according to their software, and my white G203 beats it by about 4ms as well. And my Bloody P85 beats the 203 by 1ms. Also I can confirm that the 203 changes its response time to be higher when lifted in the air.


(note: about that bloody, something might be screwy there because changing the response time in their software doesn't seem to do anything to the mouse. Doing the same thing with my Ventus works perfectly though.)

Also did anyone test their finalmouse ultralight and report the results? I was curious how the logitech mice sized up.


----------



## badben25

ewiggle said:


> So about this list, I'm not getting the same numbers.
> 
> Here's what I got: My Ventus R goes down to only 4ms, according to their software, and my white G203 beats it by about 4ms as well. And my Bloody P85 beats the 203 by 1ms. Also I can confirm that the 203 changes its response time to be higher when lifted in the air.
> 
> 
> (note: about that bloody, something might be screwy there because changing the response time in their software doesn't seem to do anything to the mouse. Doing the same thing with my Ventus works perfectly though.)
> 
> Also did anyone test their finalmouse ultralight and report the results? I was curious how the logitech mice sized up.


I think you're missing the fact that this list's numbers are relative to the Ikari Optical, where the Ikari is 0ms and all other mice are slower/faster than the Ikari by the number of ms given.


----------



## ewiggle

badben25 said:


> I think you're missing the fact that this list's numbers are relative to the Ikari Optical, where the Ikari is 0ms and all other mice are slower/faster than the Ikari by the number of ms given.


If the 203 and the Ventus are seperated in his own test by x milliseconds, then if things were the same wouldn't it make sense that regardless of your starting point or comparison point that the difference in performance measured from a source would still give you a similar range of difference between those two mice? That's what I was considering, and that's what wasn't lining up for me.


----------



## jayfkay

4.9ms for the roccat kone emp...  shame I really like the mouse otherwise


----------



## nillington

uaokkkkkkkk said:


> lol bump testing


A bit late on the reply here, but why's there an issue with bump testing? In a practical sense, effective click latency is a fiction of how long it takes the end-user to actuate a button and how long it takes for that button actuation to be registered by the PC. Twisting/soldering wires together is good for testing the second part, pcb against pcb, but testing like that assumes an identical actuation time for both mice, which is affected by shell and switch stiffness. Take the internals of a g303 and put them in an old fk/fk1 shell and it will take you, the user, longer to actuate the click due to the increased amount of force required, thus increasing effective click latency.. Bump testing, done properly, actually simulates that effect.


----------



## r01d

Please test the GPW !


----------



## dhaine

Where's the G Pro Wireless ?


----------



## bovi77

badben25 said:


> 
> 
> Direct link to the spreadsheet.
> 
> Negative latencies: I have used the SteelSeries Ikari as the baseline hence it is 0ms. Anything else at 0ms means it has the same click latency as Ikari. Anything in negative numbers means it is faster than the Ikari by that amount.
> Currently the only way to benchmark is comparatively, since an absolute minimum is not known. (Please give it some thought.)
> 
> Some time ago I became very interested in click latency, so I started following and digging through numerous forum threads, mousing blogs and mouse review pages. I have been making a list for myself and have been very particular in keeping the list accurate and up to date. I went through with it in order to collect information for my own self, but I think it will be useful to others too. If anyone spots a possible correction, please post here so we can verify and maintain this list.
> 
> I will be updating this list whenever there is something to be updated.
> Almost all of these results are at 1000Hz polling rate. I have also tried to mention the best firmware versions wherever I could.


do you own all these mice? or are you saying all who contribute to this list use ikari as well?

impressive stuff all the same!


----------



## vanir1337

bovi77 said:


> do you own all these mice? or are you saying all who contribute to this list use ikari as well?
> 
> impressive stuff all the same!


The contributors mostly compare to a random listed mouse and then calculate the relative latency compared to the Ikari.


----------



## badben25

bovi77 said:


> do you own all these mice? or are you saying all who contribute to this list use ikari as well?
> 
> impressive stuff all the same!


The Ikari is the starting point and all other numbers are relative to it. Other users wanting to contribute can use another mouse that gives stable results to compare anything newer, and then we find and fit the figure on the sheet accordingly. Recent Logitechs are reliable for this and much more widely accessible than the Ikari.

At one point I did have a lot of mice on hand, either owned or borrowed or tested elsewhere; whichever way I could get some useful figures. It all started with an Ikari because the first such usable tests on the internet came up with an Ikari as the starting point, and I had it as well, so I just followed the same path as it made sense and did not unnecessarily increase work, since it already involved tons of digging and triple checking when I started building this sheet. A lot of figures have been gathered from various sources like forums and blogs, and lately most contributions come from certain users from this forum. I've linked whichever sources I could here: https://www.overclock.net/forum/375-mice/1607990-click-latencies-compiled.html#post25414692

Without the work of rafalog, uaokkkk and qsxcv, this sheet would probably not exist at all. Apart from them, some other names that contributed are Ino, vanir and Alya, and I am sure there are others but my memory is failing me.


----------



## vanir1337

@qsxcv @uaokkkkkkkk

Can you *confirm this* please? I would add some mice to the list if I'm correct in that post.


----------



## qsxcv

sorta but check voltages with a multimeter, i think g100s might be 5v and g102 3.3v or something like that. might not matter but you might accidentally fry something if you're not careful
also i think the logi mice after g100s still have like 4ms or something additional delay when the sensor is lifted


----------



## uaokkkkkkkk

I doubt it's related, but I have managed to fry a G100s once. I still don't know exactly what I did. It happened pretty early on, when I was messing around with simple ways of doing my own version of Rafa's setup.

As for your question, I'll take a bit. I'll need to find my G100s(buried somewhere), and I also need to replace the cable on the G102 that I own(apparently something viewed it as a chew toy).


----------



## vanir1337

I'll cover the sensors next time, thank you! Also, thankfully I didn't manage to fry anything yet.


----------



## vf-

bovi77 said:


> do you own all these mice? or are you saying all who contribute to this list use ikari as well?
> 
> impressive stuff all the same!


Interesting...

Steelseries Rival 310 is 4.4
Razer Lancehead TE is 7.9 yet the wireless is 6.3

What is even more interesting is the Razer Copperhead. 0.8ms with firmware 6.16i.

While the Deathadder Elite is 8ms. Effectively the same as the Lancehead TE.


I'm shocked at the Steelseries Sensei 310. 10.3ms


----------



## vanir1337

ASUS TUF Gaming M5: +5.7 ms with the method a few posts above. +1.2 compared to a Logi G102 with covered lens.


----------



## vanir1337

HyperX Pulsefire Surge 1.1.1.4 fw +6 ms compared to a Logitech G102 (covered lens), which makes it about +10.5 ms compared to Ikari. Didn't test it with other firmwares.


----------



## badben25

Thanks for your work vanir


----------



## MousePro

What kind of latency can we expect with the Ninox Astrum?


----------



## fts42

Hi all!

I'm looking for a new mouse with many buttons for a particular FPS game, such as a Logitech G502, Roccat Tyon/Leadr or SteelSeries Rival 500 and I need to know what's the lowest click latency that I can actually get from their current versions. In the table there is this information about G502:

0.9ms with fw88.2.16; fw88.1.13 is 1.5ms, fw88.3.17 starts higher latency

I assume that this is from the earliest version of the G502, which is called Proteus Core. I think that I won't be able to find and buy this new.

There's the second version, possibly still available, called Proteus Spectrum, which supposedly only added RGB (which I don't care about). Are these two hardware versions firmware-compatible (i.e. can I flash it with v. 88.2.16 or 88.1.13)? Also, it says v. 88.3.17 "starts higher latency", but how much higher (I can live with 5ms)?

Then there's the newest version called HERO, with the HERO sensor and also different switches that are rated to 50 million clicks, rather than the 20 million clicks of the older ones. Due to the new sensor I assume this mouse can't be firmware-compatible with the older ones. So I need to know the click latency of this particular version, G502 HERO. Both the newer firmware and the different switches seem to warrant a new test.

Would someone with a *G502 HERO* be kind enough to measure the click latency?

I'm also interested in Roccat *Tyon*'s click latency (there's only a test for the wireless Leadr).

Final note to manufacturers: You should be doing what A4-Tech (!) has been doing for more than a decade - just give users the freedom and responsibility to set whatever debounce time ("button response time") they want between 3ms and 30ms (16ms by default on the models I have), with a note about how longer times become necessary with age when double-click problems appear. They are also offering super low latency *optical switches* under their Bloody brand. The only thing that A4-Tech needs to do to get more/larger purchases from people like me is to offer models with more and better placed buttons (and perhaps better sensors).

Edit: Just to mention that I have already looked through this thread and through the sources linked and elsewhere and I was not able to find answers to my questions.


----------



## TranquilTempest

fts42 said:


> Final note to manufacturers: You should be doing what A4-Tech (!) has been doing for more than a decade - just give users the freedom and responsibility to set whatever debounce time ("button response time") they want between 3ms and 30ms (16ms by default on the models I have), with a note about how longer times become necessary with age when double-click problems appear. They are also offering super low latency *optical switches* under their Bloody brand. The only thing that A4-Tech needs to do to get more/larger purchases from people like me is to offer models with more and better placed buttons (and perhaps better sensors).
> 
> Edit: Just to mention that I have already looked through this thread and through the sources linked and elsewhere and I was not able to find answers to my questions.


The mouse manufacturers could just use the NC switch contact for debouncing, which lets you get rid of the delay completely.

I think the disadvantage, from the manufacturers' perspective, is that the mouse lasts longer. Switches debounced this way don't start double clicking, or releasing partway through a drag.


----------



## fts42

TranquilTempest said:


> The mouse manufacturers could just use the NC switch contact for debouncing, which lets you get rid of the delay completely.


You are right, I hadn't thought of that. I guess the only extra marginal cost is that of an extra trace and perhaps an extra controller pin for each such button (just two low latency buttons - left&right button - is probably enough for most).



TranquilTempest said:


> I think the disadvantage, from the manufacturers' perspective, is that the mouse lasts longer. Switches debounced this way don't start double clicking, or releasing partway through a drag.


Well, there are consumers who care and specifically ask for longevity and/or low latency. To those users I'd have to mention mice such as A4Tech/Bloody's, ASUS', Thermaltake/Tt eSports', Cooler Master/CM Storm's and also cheap optical keyboards such as A4Tech/Bloody's. It's not like there's a cartel that has removed the option to go for long lasting peripherals. If any manufacturer still has a way of thinking towards limiting longevity, they have some catching up to do.

I found just today in this thread that other companies besides A4Tech, all Taiwan-based as well, have adjustable debounce times. Maybe it's worth making a list of manufacturers who allow changing the debounce time through their software, and the range of custom values that they allow. Having such a list could help people make choices if they care about low latency and/or long-term usability of the buttons:



Spoiler






uaokkkkkkkk said:


> These Dexin mice have the adjustable debounce feature:
> 
> Minimum=0ms Max=32ms:
> Sentinel Advance I & II
> Inferno
> Reaper
> Havoc
> Black (Excluding V2)
> Black Element
> 
> Minimum=12ms Maximum=36ms:
> Theron
> Level 10M (Not 2016 version)
> 
> To be clear though the values I stated above are what they are "intended" internally to do. Well, except the Theron. That gains temporary amnesia after a firmware update.
> 
> I'd go into the current lineup of Dexin mice that now have the minimum set to 4ms. However I do not have them or have looked at them yet. I plan on buying the Ventus R, so when that happens I'll bother with it.


I assume that those are all Thermaltake/Tt eSports branded and Cooler Master/CM Storm branded models, manufactured by Dexin. So do I get this right: the debounce time can be adjusted from within the software provided by the respective companies selling the mice?

ASUS also has the option:


uaokkkkkkkk said:


> You can adjust Gladius 2's debounce setting in the Armoury software.





uaokkkkkkkk said:


> Gladius 2 is 4ms-32ms. Gladius 1 is 4ms-32ms(mislabeled as 8ms-32ms in software)






Looking forward to having a list of mice with even better button behavior, such as those with optical switches (A4Tech/Bloody) and also ones which implement a better algorithm by sensing both the NC and NO pins of the switch.


----------



## uaokkkkkkkk

Ah, that's an old quote for sure. That was back before I figured out how to trick the Theron to go below what was intended. Coolermaster's software since then has set the minimum to 4ms. Thermaltake's software has also since changed the minimum to 8ms.


----------



## vanir1337

Nixeus REVEL Fit
+6.5 ms (+5.1 ms compared to G100s)

Dark Project ME2
+10.9 ms (+9.5 ms compared to G100s)
All lenses were covered.


----------



## 2shellbonus

vanir1337 said:


> Nixeus REVEL Fit
> +6.5 ms (+5.1 ms compared to G100s)
> 
> Dark Project ME2
> +10.9 ms (+9.5 ms compared to G100s)
> All lenses were covered.


Me3 should be a bit faster after the fw upgrade. I think Max will sort out an update for the Me2 for the smoothing and response times


----------



## vanir1337

2shellbonus said:


> Me3 should be a bit faster after the fw upgrade. I think Max will sort out an update for the Me2 for the smoothing and response times


Yeah, I've addressed him about the smoothing, would be great to fix it otherwise it's definitely an awesome mouse.


----------



## iEl1an

What about finalmouse air58?


----------



## vanir1337

Fnatic Flick 2 & Clutch 2 are both +4.5 ms. 0 ms compared to a G102, average of 300 clicks.


----------



## asp93

what about tt esports iris?


----------



## vanir1337

asp93 said:


> what about tt esports iris?


PM me on Monday and I'll test it.


----------



## jayfkay

what about 518 leg.?


----------



## uaokkkkkkkk

jayfkay said:


> what about 518 leg.?


Same as G502, G303, etc etc etc etc....


----------



## jayfkay

uaokkkkkkkk said:


> Same as G502, G303, etc etc etc etc....


well the 502 has 0.9 and the 303 has 4.4ms click latency according to the chart. which one is it? 
ah, what does it even matter. all I know is the clicks feel too stiff.


----------



## vanir1337

asp93 said:


> what about tt esports iris?


Tt eSPORTS Iris Optical RGB

+1.5 ms compared to the Ikari baseline. (-3 ms compared to a G102 with covered lens).


----------



## Klopfer

vanir1337 said:


> Tt eSPORTS Iris Optical RGB
> 
> +1.5 ms compared to the Ikari baseline. (-3 ms compared to a G102 with covered lens).


rly?


----------



## vanir1337

Klopfer said:


> rly?


No, I'm lying.


----------



## MousePro

Does the G300s have the same latency as G300?


----------



## Timecard

Is the bump test a relatively accurate or repeatable method for measuring click latency across different systems or what is the variability between doing this on other systems? Assuming they have the same mice and each mouse has the same firmware, MCU, and switches for those vendor models. Also would having each mouse on a different controller noticeably impact the results?

I assume every system will have a base processing speed/latency between input buffers so differences on the test system should be relatively consistent or at least proportionate.

If this was discussed somewhere else let me know, I haven't found it yet or i missed it over the totality posts.


----------



## impopo

I would like to know if when we move the mouse and the latency of the click are the same ?


----------



## TranquilTempest

impopo said:


> I would like to know if when we move the mouse and the latency of the click are the same ?


Short answer is no. Long answer is that some sources of latency impact both(like USB polling rate), and some sources of latency only impact one or the other(image processing in the sensor, delay based debounce for switches).


----------



## sprite08

vf- said:


> Interesting...
> 
> Steelseries Rival 310 is 4.4
> I'm shocked at the Steelseries Sensei 310. 10.3ms


rival 310 isn't 4.4. KPM fw1.12 (right key) vs rival 310 fw 1.33.0.0 (left key)


----------



## vanir1337

Microsoft Pro IntelliMouse
+5.9 compared to Ikari, +1.4 compared to G203 (the test was done with covered lenses).


----------



## vanir1337

Cooler Master MasterMouse MM830
+6 ms to Ikari (+1.5 ms to G203, covered lenses)

(Sorry for posting this and the previous one separately, forgot to do this one.  )


----------



## RamenRider

Can someone test Cooler Master Mizar? It is my favorite mouse and I believe it to be test worthy. There is a setting on the software that allows it to change the Button Response time ranging from 250us to 32ms. There are also 2 firmware versions that change the latency of several buttons.


----------



## sprite08

rival 310 fw 1.33.0.0 (right key) vs kinzu v1 (left key) => rival 310 is 7 - 8ms


----------



## pox02

Msi GM60
+0.9 ms to Ikari (-0.6 ms to IRIS)


----------



## vanir1337

Zowie Divina S1 (also S2 I guess)
+6.5 ms to Ikari, +5.1 to G100s with covered lens. Not 100% sure on this one, there were many outliers, but most values were between 5 and 8 ms.


----------



## badben25

vanir1337 said:


> Zowie Divina S1 (also S2 I guess)
> +6.5 ms to Ikari, +5.1 to G100s with covered lens. Not 100% sure on this one, there were many outliers, but most values were between 5 and 8 ms.


It's probably the same as all other post-Benq Zowie mice, so I'll add it there with a note.


----------



## vanir1337

Razer DeathAdder Essential
+6.0 ms compared to G102, which should mean +10.5 ms to Ikari.

Cooler Master CM310
+17.4 ms compared to G100s, which means +18.8 ms to Ikari.
That's a lot. I'll contact CM about it for sure.

All lenses were attached properly then covered.


----------



## Menthalion

Gigabyte Aorus M2 1.9ms faster compared to G Pro Wireless (wired mode).


----------



## badben25

just realized we don't have good figures on the G Pro Wireless..


----------



## vanir1337

badben25 said:


> just realized we don't have good figures on the G Pro Wireless..


I'd test it but it's such a PITA to disassemble, plus if theres below ~2.5 volts on the switches, qsxcv's program doesn't work. I'll try it next week, remind me please.


----------



## vanir1337

HyperX Pulsefire Core
+7.8 ms to Ikari (+6.4 ms to G102)

HyperX Pulsefire FPS Pro
+9.8 ms to Ikari (+8.4 ms to G102)

All lenses were covered.


----------



## cdcd

Goes to show once again how unreliable the bump test is (I got +11-15 ms relative to Ikari). Thanks for the testing.


----------



## badben25

cdcd said:


> Goes to show once again how unreliable the bump test is (I got +11-15 ms relative to Ikari). Thanks for the testing.


My bump results in the past have been very close to wired test results, especially if I do a whole bunch and take an average.
Vanir's tests are all wired.


----------



## cdcd

badben25 said:


> My bump results in the past have been very close to wired test results, especially if I do a whole bunch and take an average.
> Vanir's tests are all wired.


I can get fairly consistent results on many mice, but some show a lot of variance (for whatever reason). The Pulsefire Core was one of those that fall in the latter camp. As to why, I don't know. It's good to have wired tests to act as a benchmark for sure though.


----------



## badben25

I've also noted some mice give flat out inconsistent results even when wired. From personal experience this was a real issue with Newmen mice, and Vanir has faced this with the Zowie S1/S2. I am not sure of the technical reason behind it, something must be off in the firmware.


----------



## vanir1337

cdcd said:


> I can get fairly consistent results on many mice, but some show a lot of variance (for whatever reason). The Pulsefire Core was one of those that fall in the latter camp. As to why, I don't know. It's good to have wired tests to act as a benchmark for sure though.


There's some variance, about 2-3 ms on average, but it can be even more. I usually do around 300 clicks and take their average in Excel (plus I check for any bigger outliers that would impact the average result).


----------



## vanir1337

vanir1337 said:


> HyperX Pulsefire Core
> +7.8 ms to Ikari (+6.4 ms to G102)
> 
> HyperX Pulsefire FPS Pro
> +9.8 ms to Ikari (+8.4 ms to G102)
> 
> All lenses were covered.


Alright, I'm stupid, took the G100s' baseline value for some reason. @badben25 can you please update the table with the correct values?


HyperX Pulsefire Core
+10.9 ms to Ikari (+6.4 ms to G102)

HyperX Pulsefire FPS Pro
+12.9 ms to Ikari (+8.4 ms to G102)


----------



## cdcd

So my numbers weren't that far off after all


----------



## badben25

haha, that's more like the HyperX we know


----------



## vanir1337

Tesoro Control R1 +16.8 ms to Ikari (+12.3 to G203), all lenses covered


----------



## Ephant

Kinzu v1: right click
Gigabyte AORUS M2: left click

My lowest result was 0.3ms


----------



## vanir1337

Dark Project ME1 is +10.5 ms to Ikari (+6.0 ms to G203).


----------



## ithehappy

***! I just stumbled upon this thread as I was checking for click latencies! But I am pretty shocked to see some results! Like the Zowie FKs have like 8 ms whereas inferior mice with inferior sensors have like less than half the latency compared to the Zowies! Does this really matter, 2 vs 4 vs 8 ms, in typically competitive CS?

Thanks for the effort nonetheless by the way.


----------



## Nx87

8ms is fine really, but above 16ms then I'd give pause to thought there, it could be a factor - 16ms is about 10% of a human reaction time.


----------



## vanir1337

Corsair Glaive RGB Pro
+4.4 to Ikari (-0.1 to G203, both lenses covered)


----------



## vanSCHYNEYDER

how to revert g402 to an old firmware ?


----------



## dontspamme

vanSCHYNEYDER said:


> how to revert g402 to an old firmware ?


I'd sure like to know this, too.

Using old versions of LGS has not done the trick for me.


----------



## the1freeMan

dontspamme said:


> I'd sure like to know this, too.
> 
> Using old versions of LGS has not done the trick for me.


Old lgs will not downgrade the frimware on it's own.
If the older lgs version has an older firmware in exe in the FWUpdate folder,
you need to use resource hacker to switch the firmware file from the old lgs fwupdater exe to the new one.
This it how it worked on the g303, the newer lgs will prompt you to update firmware every time and not work, so you need to use the older version.


----------



## dontspamme

the1freeMan said:


> Old lgs will not downgrade the frimware on it's own.
> If the older lgs version has an older firmware in exe in the FWUpdate folder,
> you need to use resource hacker to switch the firmware file from the old lgs fwupdater exe to the new one.
> This it how it worked on the g303, the newer lgs will prompt you to update firmware every time and not work, so you need to use the older version.



You wouldn't happen to have a tutorial for that, would you?

Have been waiting years to downgrade the FW on my G402.


----------



## the1freeMan

dontspamme said:


> You wouldn't happen to have a tutorial for that, would you?
> 
> Have been waiting years to downgrade the FW on my G402.


Download and install: http://angusj.com/resourcehacker/
Install old LGS with the FW version you want (you must know which one)
go to: C:\Program Files\Logitech Gaming Software\FWUpdate\G402
Open G402update_v??.exe with Resource Hacker
Navigate the left panel until you find the firmware file and extract it
Install new LGS and open G402update_v17.exe (or whatever the current version might be) in the same directory with RH
Substitute the Firmware file with the old one you extracted earlier
Save, close RH and run G402update_v17.exe (or whatever the updated version might be).
Reinstall old LGS version if you want to change setting on the mouse.


----------



## dontspamme

the1freeMan said:


> Download and install: http://angusj.com/resourcehacker/
> Install old LGS with the FW version you want (you must know which one)
> go to: C:\Program Files\Logitech Gaming Software\FWUpdate\G402
> Open G402update_v??.exe with Resource Hacker
> Navigate the left panel until you find the firmware file and extract it
> Install new LGS and open G402update_v17.exe (or whatever the current version might be) in the same directory with RH
> Substitute the Firmware file with the old one you extracted earlier
> Save, close RH and run G402update_v17.exe (or whatever the updated version might be).
> Reinstall old LGS version if you want to change setting on the mouse.


Thanks for this!

Sadly, I think there must only have been one FW update ever released for this mouse.
The first FW upgrade I'm able to find is the one that comes with LGS v8.76.155, which seems to be the same on all LGS versions thereafter. My G402 already has this FW. ;(

I guess the few lucky ones that never upgraded the FW are the ones still enjoying low click latencies.

I really despise Logitech for their "we know better than the end user" policy.
Won't allow us to revert back to (better) firmwares. And now their new sensors even come with auto surface tuning, ensuring the end user will never get the option of a higher LoD.

I think I've bought my last ever Logitech mouse.


----------



## SmashTV

Pretty sure it was discovered that the higher latency change only took effect when the mouse is lifted. 

Unless I'm remembering incorrectly.


----------



## dontspamme

SmashTV said:


> Pretty sure it was discovered that the higher latency change only took effect when the mouse is lifted.


A comforting thought...


----------



## vanir1337

dontspamme said:


> A comforting thought...


If the base latency was 1.5 ms, I have a wild guess they raised it to be on par with the other newer G-series Logi mice, so about 4.5 ms. That 3-4 extra ms won't matter. I used to play competitively on a high level with an EC2-eVo, which is known to have 16 ms (and a DeathAdder BE before, that wasn't too great either in these terms), and I never had any issues with it. This click latency thing is a bit overhyped if you ask me, anything below 10-12 ms should be negligible - in most cases, and even if it's higher it won't affect 99% of the end users.


----------



## Gordon59

I didn't read everything so maybe it had already been say, if not it might interest some of you !

I came accross this software when I bought my Bloody keyboard. It's named "KeyResponse PK" 



> In the intense gameplay, millisecond often determines the winner. You may not know how long it will take the computer receives the data after pressing the key of your mouse or keyboard. This time delay is commonly known as "Key response". This software is particularly made for the gamers. Through the simple PK face, gamers may explore the truth of the real key response of the gaming mouse and keyboard. Besides, gamers also may get full understanding of the key design difference from the dartboard explaination so as to avoid spending lots of money but obtaining the low response inferior products.


It works both with mouse and keyboard and it's available here : 

https://www.bloody.com/en/download.php?id=6 

I didn't test it yet but I think it worth to give it a try


----------



## RamenRider

So what's the methodology here when testing mice? Cause for the most part, most software have button response features such as my mizar that has click response time settings from 250us to 32ms but it might not work unless Lock OS settings is checked, and my corsair mice have something a bit different, but doesn't mention response time.

Also there are different versions of the Corsair Sabre. A 6400dpi version and a 10kdpi version, what are the differences between the two? Mine came with firmware v2.04.


----------



## daniloberserk

What's the difference between "click latency" and "response time (debounce time)" on mice? I honestly can't find a straight answer... Some people here on my country keep claiming that Logitech mice have the "fastest clicks" and a BUNCH of people are mad about double clicks, but seeing this chart shows that even Ventus R are "faster"... So the Ventus R have low click latency and high debounce time?.. So, rapid fire is "slower" but "sniping" is faster?


----------



## vanir1337

daniloberserk said:


> What's the difference between "click latency" and "response time (debounce time)" on mice? I honestly can't find a straight answer... Some people here on my country keep claiming that Logitech mice have the "fastest clicks" and a BUNCH of people are mad about double clicks, but seeing this chart shows that even Ventus R are "faster"... So the Ventus R have low click latency and high debounce time?.. So, rapid fire is "slower" but "sniping" is faster?


Same thing essentially. The higher the debounce the higher the click latency, and it reduces the chance of accidental double clicks. 
E.g: I've measured about 11.8 ms click latency on the Model O on 10 ms debounce, and 4.1 ms on the 4 ms setting.


----------



## TranquilTempest

daniloberserk said:


> What's the difference between "click latency" and "response time (debounce time)" on mice? I honestly can't find a straight answer... Some people here on my country keep claiming that Logitech mice have the "fastest clicks" and a BUNCH of people are mad about double clicks, but seeing this chart shows that even Ventus R are "faster"... So the Ventus R have low click latency and high debounce time?.. So, rapid fire is "slower" but "sniping" is faster?


Click latency is the time from when you physically press the button to when the computer recognizes that the button has been pressed.

Things that contribute to click latency are the mechanical travel of the switch, how frequently the microcontroller checks the state of the switch, debounce delay, USB polling interval, and how often the program you're using checks for input events.

There are many different ways to implement software debouncing, if a mouse has a lower latency than its debounce time, it's most likely using different values for press vs release. Other options are averaging out several samples, or waiting until you have x number of samples that are the same value.

Or if you hook up the NC contact of your switch, you can completely get rid of debounce delay.


----------



## daniloberserk

vanir1337 said:


> Same thing essentially. The higher the debounce the higher the click latency, and it reduces the chance of accidental double clicks.
> E.g: I've measured about 11.8 ms click latency on the Model O on 10 ms debounce, and 4.1 ms on the 4 ms setting.





TranquilTempest said:


> Click latency is the time from when you physically press the button to when the computer recognizes that the button has been pressed.
> 
> Things that contribute to click latency are the mechanical travel of the switch, how frequently the microcontroller checks the state of the switch, debounce delay, USB polling interval, and how often the program you're using checks for input events.
> 
> There are many different ways to implement software debouncing, if a mouse has a lower latency than its debounce time, it's most likely using different values for press vs release. Other options are averaging out several samples, or waiting until you have x number of samples that are the same value.
> 
> Or if you hook up the NC contact of your switch, you can completely get rid of debounce delay.


Thank you very much guys for clarifying this! But then.. Why the Ventus R have 2.4ms~ click lattency on the chart when the fastest option in the software is 4ms? I don't see the point going for extra low debounce times since no one can rapid fire so fast to justify 10ms~... But I do see a point going for lower click latency.

If everything is tied together.. Then things is more complicated then I thought.

Still, Logitech isn't the "fastest click in the west".


----------



## vanir1337

daniloberserk said:


> Why the Ventus R have 2.4ms~ click lattency on the chart when the fastest option in the software is 4ms?


See what TranquilTempest wrote: debounce isn't the only thing affecting the measurable click latency. It's set to 4 ms by the firmware, but the other factors are different than on a bunch of other mice in the list, hence the faster overall response time.
Tbh anything below ~10 ms is negligible anyways.


----------



## daniloberserk

vanir1337 said:


> See what TranquilTempest wrote: debounce isn't the only thing affecting the measurable click latency. It's set to 4 ms by the firmware, but the other factors are different than on a bunch of other mice in the list, hence the faster overall response time.
> Tbh anything below ~10 ms is negligible anyways.


I still think this is quite confusing... So, a mouse can have a click delay (button press) like 1ms (ignoring the travel time), but could have like 10ms for button release? Different values for different events?

Here on my country people says that Logitech mice have problems with double clicks because the debounce time is way to low. Isn't debounce time related only for button release? http://www.ganssle.com/images/debounceswitchq.jpg


----------



## vanir1337

ROCCAT Kova AIMO +7.1 ms
ROCCAT Kain 120 +3.2 ms


----------



## XeaL337

G305 vs Razer Jugan - The smallest delta was 0.9ms, with g305 always winning. I'd say most of the time the difference was 1-3ms.
G305 vs Steelseries Kinzu v2 - The smallest delta was 18.9ms, with g305 always winning. I'd say most of the time the difference was 22ms.

Which value do you take? an average, or smallest delta?

Using my numbers, and Kinzu v2= 25.2ms
Razer Jugan - 7.2ms~ (same as abyssus v1, which is 7.1ms)
G305 - 6.3ms~

Seems to line up.


----------



## Ephant

Endgame Gear XM1 vs Kinzu v1

XM1 faster by 0.9ms


----------



## vanir1337

Ephant said:


> Endgame Gear XM1 vs Kinzu v1
> 
> XM1 faster by 0.9ms


You can't measure the latency with the standard methods due to its debouncing technique. The correct value is approximately -7 ms to the Ikari according to Endgame Gear's testing. I'll ask them to provide this data to the public.


----------



## badben25

Found it interesting that at 6:28 he shows this sheet. Anyone have any idea what he's saying there?


----------



## cdcd

badben25 said:


> https://www.youtube.com/watch?v=IZshOoYYnG4
> 
> Found it interesting that at 6:28 he shows this sheet. Anyone have any idea what he's saying there?


He's talking about the values not being absolute but relative ones, in case someone's wondering why there are negative values included.


----------



## badben25

cdcd said:


> He's talking about the values not being absolute but relative ones, in case someone's wondering why there are negative values included.


haha that's cool, it's probably the most common question I've been asked too. Anyone know who he is here on OCN? Maybe he could lend a sample


----------



## kurtextrem

What does everyone think of the Razer Viper optical switches (especially vs the XM1), could they be faster?


----------



## the1freeMan

"What does everyone think of Razer?" earth starts shaking, people start vomiting.
btw pretty sure razer is not the first to optical switch.. 
Also pretty sure given the same switch most non-chinese-oem brands can make a better firmware than razer.
Wait bloody is actually a chinese oem brand.. kinda.. maybe worse.. still would put my money on them rather than razer..


----------



## vanir1337

kurtextrem said:


> What does everyone think of the Razer Viper optical switches (especially vs the XM1), could they be faster?


Highly doubt they're faster. They can be good though. I'm interested how they hold up to their nominal lifespan, and how their click-feel changes over use.


----------



## dontspamme

the1freeMan;28074938
btw pretty sure razer is not the first to optical switch.. ;)
[/QUOTE said:


> Yeah. Omen (by HP) have made a couple of gaming mice with optical switches.


----------



## detto87

vanir1337 said:


> Highly doubt they're faster. They can be good though. I'm interested how they hold up to their nominal lifespan, and how their click-feel changes over use.


According to this review https://www.digitaltrends.com/gaming/razer-viper-review/ it has an actuation time of 0.2 milliseconds.


That said, the shape doesn't really look easy to lift up. https://d4kkpd69xt9l7.cloudfront.ne.../h32/9209281675294/razer-viper-gallery-06.jpg It's more of a ambidextrous palm grip mouse than a claw grip mouse. At least I guess so from the pictures. Didn't find any real good description of its shape.


----------



## James N

There is something about the buttons though that makes me click consistently slower than other mice. (I know human benchmark is not accurate at all. But i kept doing the test on different days and i was always slower with the xm1. So i think the button shape/actuation force or whatever makes me perform worse with it.) It is a good clawgrip mouse though.

First one is the xm1 , second one is the Model O. I score faster with g403 and even with the Zowie Divina S1. For me it just doesn't work as well as the others. Let's see how the Viper performs, that arrives tomorrow.


----------



## SweetLow

JFYI, On the Latency of USB-Connected Input Devices
Small scientific article, theory and some interesting measurement results.  @uaokkkkkkkk thread Firmware Added Button Delay Testing Attempts(Tapping mouse buttons lightly) referenced.


----------



## muso

Any numbers on the viper?


----------



## James N

I just finished some tests with the bloody pk software.

I used the G303 and G403 as baseline (to make sure the results are not scuffed in some way and my G303/G403 have a 0.1ms difference between them in the pk test) and tested both against the Glorious Model O ( first gen, with the newest firmware and lowest possible debounce). As well as the G wolves skoll (first gen, newest firmware , lowest possible debounce) . I directly bounced the buttons against each other and the sensors were covered on all mice.

G303/G403 between 0.1ms-1.4ms faster than Glorious Model O

G303/G403 between 1.9ms-2.5ms faster than G Wolves Skoll

G303/G403 between 4.1ms-4.8ms faster than Zowie ZA-11 (this was done just to make sure results are somewhat accurate)

Of course its not an accurate test but this should be interesting to those who were wondering and don't have these mice.

I had to rma my Viper , since the M4 was double clicking right from the get go.


----------



## cdcd

Xtrfy M4: +1.4 ms relative to Ikari (baseline).


----------



## Klopfer

cdcd said:


> Xtrfy M4: +1.4 ms relative to Ikari (baseline).


that sounds nice ...
Im not sure if I would like the shape ... didnt tried it ... looks too wide in the rear ... but it's still on my List


----------



## James N

Klopfer said:


> that sounds nice ...
> Im not sure if I would like the shape ... didnt tried it ... looks too wide in the rear ... but it's still on my List


I like it, but its way too small for me. It looks bigger than it is.


----------



## 1ms_hand2eye

Has anyone tested on Linux? Based on this list - and the fact you'd not be able to change the firmware - which do you think would have the lowest latency on Linux? I'm guessing the Logitechs like the G303?


----------



## cdcd

Dream Machines DM5 Blink: +9.2 ms relative to Ikari (baseline)


----------



## uaokkkkkkkk

SweetLow said:


> JFYI, On the Latency of USB-Connected Input Devices
> Small scientific article, theory and some interesting measurement results.
> @uaokkkkkkkk thread Firmware Added Button Delay Testing Attempts(Tapping mouse buttons lightly) referenced.


Thanks for that @SweetLow! I would've never known otherwise.


....

NO 8000hz!?

>"The rafalog approach is destructive"

uhhhh... it's not destructive?

>Razor Diamondback
default 9.12ms, sd:2.30ms
1000hz 6.12ms, sd:2.67ms

That result caught my eye. 

I wonder which revision of the Diamondback was tested. I don't mean to imply that it matters though. Just curious and all because it's a Diamondback...

Anyway, twas' a fun read.


----------



## 5qvqes

*Viper test to ikari*

Hi,
i just ask here for the viper because she has the new opto mechanical switches. R there some test planned?
The endgame gear xm1 is also a test worth.

Greats.


----------



## kajks111

which of the list:

corsair ironclaw
logitech g305
deathadder elite
dm 1 pro s
xtrfy M4

not considering the price is the best in your opinion?


----------



## badben25

kajks111 said:


> which of the list:
> 
> corsair ironclaw
> logitech g305
> deathadder elite
> dm 1 pro s
> xtrfy M4
> 
> not considering the price is the best in your opinion?


If I had to choose for myself, any of those apart from the Ironclaw are fine. It would just come down to subjective preferences like wired/wireless, shape, weight etc. The DM1 Pro S is my mouse of choice here.


----------



## cdcd

ROCCAT Kone Pure Ultra:

+6.8 ms relative to SteelSeries Ikari (default)
-0.15 ms relative to SteelSeries Ikari (ZeroDebounce enabled)

'ZeroDebounce' is an option within the ROCCAT Swarm software that basically eliminates the debounce delay (resulting in occasional slam clicks).


----------



## cdcd

Glorious Model O-: +3.8 ms relative to SteelSeries Ikari (Model O was +4.1, so with the firmware being the same the difference is most likely due to variance)

Cooler Master M711 (MM710 too I suppose): +6.8 ms relative to SteelSeries Ikari

The MM711's MCU is the same Holtek one as the ROCCAT KPU by the way, so the click latency being identical may not be a coincidence.

Testing was done at the 4 ms debounce setting for each.


----------



## ZeBodscha

hey,

just found the thread on my search for a new mouse. could anyone explain what's meant in the note section when it says lmb+rmb = 20-30ms? kind of confused, cause the click latency values listed are much lower.

thanks in advance. o7


----------



## badben25

ZeBodscha said:


> hey,
> 
> just found the thread on my search for a new mouse. could anyone explain what's meant in the note section when it says lmb+rmb = 20-30ms? kind of confused, cause the click latency values listed are much lower.
> 
> thanks in advance. o7


It means that when LMB and RMB are clicked down together (or in quick succession) there is a major delay in response, 20-30ms in your mentioned example. This can be very noticeable when trying to rocket jump in Quake or quick-scoping in CS.

Reminds me of the Ninox Aurora, a mouse I really really liked but it had an LMB+RMB delay of 50-55ms which ****ed me in a few in-game situations. Too bad, everything else about that mouse suited me very well.


----------



## jonathah

Hey Im wondering what mouse I should get between those glorious model o/o- gpro wireless ktec ktm-9500+ microsoft wheel mouse optical overclocked to 2000hz Nmouse 4k or the roccat kone pure ultra with zero debounce on

I have rn a steelseries sensei 310 and need a mouse to butterfly click so less debounce delay is better because in the game I play I need alot of cps (click per seconds)


----------



## cdcd

Abkoncore A900: +13.1 ms relative to SteelSeries Ikari

Adesso iMouse X3: +16 ms relative to SteelSeries Ikari


----------



## ron028

Does anyone know the click latency of Logitech G90? I switched from DA essential and Logitech g403, but due to some reasons i feel mouse has great response time compared to DA that too at 500Hz.


----------



## cdcd

ron028 said:


> Does anyone know the click latency of Logitech G90? I switched from DA essential and Logitech g403, but due to some reasons i feel mouse has great response time compared to DA that too at 500Hz.


Should be the same as G100s


----------



## nlse

vanir1337 said:


> You can't measure the latency with the standard methods due to its debouncing technique. The correct value is approximately -7 ms to the Ikari according to Endgame Gear's testing. I'll ask them to provide this data to the public.


do you have any more info on this?


----------



## vanir1337

nlse said:


> do you have any more info on this?


Lots of posts about this in this thread and on Reddit too, especially in pzogel's review.


----------



## xnoreq

Is the "click latency" in the table in #1 truly the latency from the mechanical button down click to the OS receiving the mouse button down event?
Because if it is how long clicks last then it is pretty irrelevant for FPS games. Those typically don't care about click (down & up) events at all.

Also, are the G403 and G502 latencies also valid for their HERO versions?


----------



## cdcd

Glorious Model D: +3.8 ms relative to SteelSeries Ikari (4 ms debounce setting)

Dream Machines DM4 Evo: +6.4 ms relative to SteelSeries Ikari


----------



## Klopfer

When can you tell more about the DM4evo?
Edit: found a review oO
https://pclab.pl/art82688.html
G403 inspired, alps mwheel encoder, huano blue shell, good cable, ~97g...


----------



## cdcd

Another one: https://www.techpowerup.com/review/dream-machines-dm4-evo/


----------



## Klopfer

Thx, easier in English


----------



## badben25

xnoreq said:


> Is the "click latency" in the table in #1 truly the latency from the mechanical button down click to the OS receiving the mouse button down event?
> Because if it is how long clicks last then it is pretty irrelevant for FPS games. Those typically don't care about click (down & up) events at all.
> 
> Also, are the G403 and G502 latencies also valid for their HERO versions?


Yes the Hero versions should have about the same latency. I am curious myself but someone with those mice would have to test as I cannot.


----------



## xnoreq

Well yeah, the test program used measures something which is *irrelevant for FPS games*.
To avoid future confusion I'm asking kindly to rename that review section to "min click duration" because that's what it measures.


What matters in FPS games is the (mouse) input latency, that is the timespan from the physical button being pressed to the driver/OS receiving a button down event.



This is influenced mainly by the firmware and transmission protocol (USB polling rate, wireless protocols ...)
Mechanically, there's also the button travel which could also be considered being part of input latency.


----------



## fourthavenue

ron028 said:


> Does anyone know the click latency of Logitech G90? I switched from DA essential and Logitech g403, but due to some reasons i feel mouse has great response time compared to DA that too at 500Hz.


G90 is a "lower trim" version of G100s which has great click latency and has been a baseline in many reviews.


----------



## badben25

xnoreq said:


> Well yeah, the test program used measures something which is *irrelevant for FPS games*.
> To avoid future confusion I'm asking kindly to rename that review section to "min click duration" because that's what it measures.
> 
> 
> What matters in FPS games is the (mouse) input latency, that is the timespan from the physical button being pressed to the driver/OS receiving a button down event.
> 
> 
> 
> This is influenced mainly by the firmware and transmission protocol (USB polling rate, wireless protocols ...)
> Mechanically, there's also the button travel which could also be considered being part of input latency.



Maybe what you're looking for is one overall figure of a mouse's latency to the OS? Because that does not exist. Click latency is in the switches sending commands to your computer, and the other latency is of the mouse sensor's response being registered in the OS/game engine. That's a different thing from my knowledge and is not being measured.



xnoreq said:


> the timespan from the physical button being pressed to the driver/OS receiving a button down event.


That's exactly what's being measured.

I don't see anyone implying this is the overall latency from button switch to screen. That kind of latency is near impossible to measure consistently anyway because there's so many factors involved. One could even go further and add several non-technical factors to that too, like how tired you are, how you feel mentally, etc.

Neither is it implied that the list was gathered using bump testing numbers with the KeyResponse tool. If you want to get into the nitty gritty, doing the due diligence of going through the long linked threads (and this one) is on you. I have added a note among the first posts anyway so this is clarified for the future.

If these figures were irrelevant for FPS games, it's possible that the discrepancies would not have been noticed in the first place, and no one would have bothered looking into them. Of course there's more to it than the mere click latency of a mouse; ping alone would trump any other input figures that can help. When asked, I usually advise that shape/sensor/etc should be considered first and certainly not before practice. I am sure others do the same.
Don't you think that, the fact that different click latencies affect the execution of certain moves in FPS games, makes it relevant enough to consider? For many, it has influence in IRL use and maybe it doesn't to you, in your understanding.

I think you are mistakenly pushing your understanding as fact. If we began to scrutinize input latency, especially in the current era, it would go on forever and be fruitless. The sheet is meant to provide information to help others, whether that be with optimizing their setup, understanding mouse tech, making purchase decisions, or something else. There are others with more knowledge and experience than me on these very forums who can help if you want to go more in-depth.


----------



## fourthavenue

Why is Xtrfy M4 so good? Does it have slam click issues?
I'm becoming interested.


----------



## xnoreq

badben25 said:


> Maybe what you're looking for is one overall figure of a mouse's latency to the OS? Because that does not exist.


Then why do I know of some gaming mouse manufacturers that have measured this, at least internally, for years? How do you think they are optimizing e.g. wireless protocols for latency?
By measuring latency from button press to the OS receiving the command - the _input lag of the mouse_.




badben25 said:


> Click latency is in the switches sending commands to your computer, and the other latency is of the mouse sensor's response being registered in the OS/game engine. That's a different thing from my knowledge and is not being measured.


Exactly. But as I said, what is being measured here is the most _irrelevant _for FPS games where input latency matters most.




badben25 said:


> That's exactly what's being measured.


No, it's not. You're confusing a button down event with a click event.
A click event is a button down event followed by a button up event. This is also why I suggested renaming this to "_min click duration_" to reduce confusion.




badben25 said:


> If these figures were irrelevant for FPS games, it's possible that the discrepancies would not have been noticed in the first place, and no one would have bothered looking into them.


They are irrelevant for any shooter where you don't need to click to shoot but just hold down the mouse button. Because then all the game receives is the mouse button down event - _no clicking happened_ - and the latency from pressing the button to the OS receiving that event is the input latency that matters.

I mean just browse the web and you'll see people on the one hand calling it placebo and people on the other hand reporting that they're noticing a clear difference _"_even in Chrome" when _clicking_ browser tabs. 
No crap, GUI applications typically rely on click events provided by the OS. That's because you don't want to trigger an application button _immediately on mouse down_ but only once you've done a _full click._

This has nothing to do with how games are programmed, especially not competitive shooters where input latency matters most. So it was placebo in-game and latency is not lower _even _in chrome but in GUI applications that rely on click events. Yay, low click duration is great for Excel, Word & Chrome. 




badben25 said:


> Of course there's more to it than the mere click latency of a mouse; ping alone would trump any other input figures that can help.


This again is just muddying the water.
Network latency is just another one of those variables mentioned above, which is totally irrelevant for mouse performance.
Given the same network latency, there is a difference between two mice with different input latency.




badben25 said:


> Don't you think that, the fact that different click latencies affect the execution of certain moves in FPS games, makes it relevant enough to consider? For many, it has influence in IRL use and maybe it doesn't to you, in your understanding.


Let me give you some food for thought why_ low "click latency/duration" can actually lead to worse input latency:_
The firmware can just delay the mouse down event to shorten the timespan from mouse down to mouse up event (debouncing). This shortens what you call "click latency" but actually adds input latency.


As for your point: I take objective facts over subjective impressions (see above) and correlation is also not causation. 

Ignoring placebo effects, there are many anecdotes from people that switched from ancient, broken, crap mice to new gaming mice. Naturally they will report improvements "IRL" (where else do you use your mouse?), but that has nothing to do with "click latency/duration" ... unless they're talking about Excel .. or Chrome.

As for "certain moves", I can only guess what you mean, but in any competently programmed game (especially if it is used competitively) there should be no difference but cosmetic ones. For example, if the duration of mouse down starts some animation and mouse up stops it then a 5ms vs 25ms "click latency/duration" can result in a visual difference.

But consider this: _how fast_ can you click and what is the max. frequency that a game requires you to click? Can you do 18 clicks per second? That's still over 55ms.

What game requires you to do over 18 individual clicks per second? If it's a competitive shooter with a semi-automatic firearm then it will most likely have a much lower rate of fire limit anyway to prevent macro abuse.
And if that's not the case then just bind firing to your wheel and scroll away if you dislike macros... 




badben25 said:


> I think you are mistakenly pushing your understanding as fact.


 Please point out and explain where my understanding is not fact. If possible with facts and not anecdotes.




badben25 said:


> If we began to scrutinize input latency, especially in the current era, it would go on forever and be fruitless. The sheet is meant to provide information to help others, whether that be with optimizing their setup, understanding mouse tech, making purchase decisions, or something else. There are others with more knowledge and experience than me on these very forums who can help if you want to go more in-depth.


 I disagree.
Input latency of a mouse is easily defined as I did above. It can also be measured and has been for years e.g. by Logitech and others.


I have nothing against the information provided here, but the problem is that it seems to be _misleading _because there's no disclaimer as to the _irrelevancy _for gamers and an explanation of what is actually being measured and what is NOT being measured: input latency, which would be relevant.


----------



## xnoreq

fourthavenue said:


> Why is Xtrfy M4 so good? Does it have slam click issues?
> I'm becoming interested.


Firmware, but if you think click duration is relevant for competitive FPS games then I have to disappoint you.


----------



## Axaion

No one here has said it was click duration but you, youre reading something into all of this, and misunderstanding it on top of it.

Basicly this is smashing 2 mice together to see which one "reacts" fastest, the program records which one made an input to it first, and lists it.
No button tension doesnt matter when you smash them together, 20grams is not going to make a difference.


----------



## xnoreq

I'm sorry, I came from techpowerup's "Click Latency" section in their mouse reviews which links here and to qsxcv's program.

The review sections say "_Debouncing typically adds a delay (along with any potential processing delay), which shall be referred to as click latency_" and I therefore asked whether you're measuring that or actual input latency i this thread.
The question wasn't answered.
After another link to a techpowerup review from here my reply in #400 was in the context of qsxcv's program to measure what techpowerup also calls "click latency".

If you're measuring something else then _the data from techpowerup and here is incompatible and not comparable at all_ (even though you call it the same)_._ So I don't get why there's a reference from techpowerup to here.


----------



## badben25

Button down is when your gun in an FPS starts shooting. I think that alone is enough to question why it has to be a full click like you ask?
Not sure if you're still under misunderstanding, or if I'm not understanding your query.



xnoreq said:


> I'm sorry, I came from techpowerup's "Click Latency" section in their mouse reviews which links here and to qsxcv's program.
> 
> The review sections say "_Debouncing typically adds a delay (along with any potential processing delay), which shall be referred to as click latency_" and I therefore asked whether you're measuring that or actual input latency i this thread.
> The question wasn't answered.
> After another link to a techpowerup review from here my reply in #400 was in the context of qsxcv's program to measure what techpowerup also calls "click latency".
> 
> If you're measuring something else then _the data from techpowerup and here is incompatible and not comparable at all_ (even though you call it the same)_._ So I don't get why there's a reference from techpowerup to here.


This one might be for @vanir1337 @cdcd


----------



## vanir1337

badben25 said:


> Button down is when your gun in an FPS starts shooting. I think that alone is enough to question why it has to be a full click like you ask?
> Not sure if you're still under misunderstanding, or if I'm not understanding your query.
> 
> 
> 
> This one might be for @vanir1337 @cdcd


https://www.overclock.net/forum/375-mice/1607990-click-latencies-compiled-29.html#post27621372
Seems logical to me, even more so since qsxcv confirmed it.


----------



## cdcd

qsxcv's program records button press events, not button press and button release. Debouncing happens for the button press event, and that's what's measured. This applies to any figures gathered with qsxcv's program, i.e. both the ones in this thread here and on TPU.

Same goes for the Bloody program by the way (i.e. only recording button press events). When wiring the switches together, the Bloody program is functionally equivalent to qsxcv's program, just with added rounding errors and less convenient exporting/averaging.


----------



## xnoreq

badben25 said:


> Button down is when your gun in an FPS starts shooting. I think that alone is enough to question why it has to be a full click like you ask?
> Not sure if you're still under misunderstanding, or if I'm not understanding your query.



1) That's exactly what I have been saying in my previous posts. Because of the linking to techpowerup and techpowerup using the same term "click latency" (which I'd call "min click durations", as I've explained) I had assumed you're measuring the same here.
2) I never asked for a full click. I did the opposite and pointed out that techpowerup's "click latency" is irrelevant for competitive FPS where input latency matters most.
3) My query was quite simple, I've repeated it and you're still not understanding it.


Let's make this as simple as possible:
Q1) How do you define "Click Latency" _as used in #1 in this thread_?
Q2) How did you measure the values in the table in #1?






cdcd said:


> qsxcv's program records button press events, not button press and button release. Debouncing happens for the button press event, and that's what's measured. This applies to any figures gathered with qsxcv's program, i.e. both the ones in this thread here and on TPU.


The l.exe and r.exe programs measure click duration (mouse down to mouse up event) of the left and right button respectively. a.exe indeed measures difference between left and right mouse down events.


Debouncing dictates min click duration. For input latency (physically pressing the button to the OS receiving the button down event) it is irrelevant.
Which is why your second sentence makes no sense to me and I don't understand your last sentence. Debouncing doesn't happen for the button press event. When the firmware reads a button press it should immediately send this as an event and _start debouncing_. As such, debouncing doesn't have any effect on input latency.


But as I've already explained above, the firmware could be written to "cheat" with debounce time by delaying sending that initial press event. The l/r.exe programs would then display a shorter click duration even though physically debounce time wasn't worted (that's the cheating part). This would come at the cost of increased input latency.


----------



## cdcd

Debouncing absolutely happens at the point I described. If I set the Model O/O-/D to 16 ms debounce, a.exe will return values that are 12 ms higher than at 4 ms debounce. The same is true for Logitech's increased debounce time during lift-off, or ROCCAT's "Zero Debounce" feature, which eliminates debouncing entirely and results in accordingly lower values in a.exe.


----------



## xnoreq

cdcd said:


> Debouncing absolutely happens at the point I described. If I set the Model O/O-/D to 16 ms debounce, a.exe will return values that are 12 ms higher than at 4 ms debounce. The same is true for Logitech's increased debounce time during lift-off, or ROCCAT's "Zero Debounce" feature, which eliminates debouncing entirely and results in accordingly lower values in a.exe.


Then that would be the most naive "debouncing" implementation that I didn't think anyone was using as it is essentially a low pass filter that just delays the whole signal which just adds a flat delay.

If this is really the case for these mice then it is shocking as a better implementation (with much lower delay in detecting press/release after a stable period) can be implemented in a few lines of code.


----------



## TranquilTempest

xnoreq said:


> Then that would be the most naive "debouncing" implementation that I didn't think anyone was using as it is essentially a low pass filter that just delays the whole signal which just adds a flat delay.
> 
> If this is really the case for these mice then it is shocking as a better implementation (with much lower delay in detecting press/release after a stable period) can be implemented in a few lines of code.


There are a number of different software debouncing techniques, but they all have at least one drawback, be that delay when pressing, interfering with intentional click spam, or low tolerance to switch wear, resulting in double clicking on a single press, or releasing during a drag. I prefer using the NC contact for debouncing; no delays and the switch has to be in a pretty bad condition before it stops working.


----------



## Jonagold

I encountered an issue with my Razer Viper, seems like Razer have coded their firmware for optical switched so, that the first click after mouse lifting is always 7 ms delayed. Then, making it even worse, clicks after that are not delayed, so there is an inconsistency between consecutive clicks. This method is probably supposed to eliminate so called "slam clicks", unintentional mouse switch actuation caused by reckless mouse handling, dropping, slamming.


----------



## cdcd

ROCCAT Kain 100 AIMO: +7.9 ms relative to SteelSeries Ikari w/ ZeroDebounce set to off (default) // +2.9 ms w/ ZeroDebounce set to on


----------



## speed_demon

What software are you guys using to find latency? And how do you find out what firmware your mouse is using? I googled a bunch and can't find any clear way to tell what fw my first gen Logitech G5 is using.


----------



## Melan

Post #3 in this thread.

FW version is displayed by software for the mouse.


----------



## cdcd

Corsair Scimitar RGB Elite: +5.9 ms relative to SteelSeries Ikari


----------



## cdcd

ASUS ROG Strix Impact II: +11.9 ms relative to SteelSeries Ikari (Button Response: 12 ms within Armoury II, which is the lowest)


----------



## Vibe With Me

Does anyone have any idea where G Pro Wireless and Viper Ultimate sit among these mice? Sorry I searched through every comment and all I could find was that these mice have consistency issues and are hard to test? If there's something I'm missing forgive me as I am very new to all of this.


----------



## vanir1337

Vibe With Me said:


> Does anyone have any idea where G Pro Wireless and Viper Ultimate sit among these mice? Sorry I searched through every comment and all I could find was that these mice have consistency issues and are hard to test? If there's something I'm missing forgive me as I am very new to all of this.


Pretty sure the GPW is sitting around +4.5 like all the other newer Logi mice.


----------



## Klopfer

G305, also wireless, has +4.5 too


----------



## cdcd

SteelSeries Rival 3: +4.3 ms relative to SteelSeries Ikari


----------



## PMB

Can anyone logically explain to me how the 2008 ikari would be able to be faster than modern 1000hz low/no debounce mice? It just doesnt make sense to me. Did it use japanese omrons?


----------



## cdcd

PMB said:


> Can anyone logically explain to me how the 2008 ikari would be able to be faster than modern 1000hz low/no debounce mice? It just doesnt make sense to me. Did it use japanese omrons?


By using a correspondingly low debounce time value. As much as it was possible to select a value of 0.5 ms in 2008 it is possible to choose a value of 30 ms in 2020. Switches only enter the equation in terms of how low of a debounce delay without suffering from unintended double clicks they support.


----------



## PMB

cdcd said:


> By using a correspondingly low debounce time value. As much as it was possible to select a value of 0.5 ms in 2008 it is possible to choose a value of 30 ms in 2020. Switches only enter the equation in terms of how low of a debounce delay without suffering from unintended double clicks they support.



So the Ikari had incredibly low debounce value and as a result tons of double clicks?


surely there must be something in the board layout and used controller aswell, right? Things dont really add up to me, as an IT engineer. If debounce is the only factor, then the XM1 and viper both should be at least on par with the ikari (?)


----------



## cdcd

PMB said:


> So the Ikari had incredibly low debounce value and as a result tons of double clicks?
> 
> 
> surely there must be something in the board layout and used controller aswell, right? Things dont really add up to me, as an IT engineer. If debounce is the only factor, then the XM1 and viper both should be at least on par with the ikari (?)


Both XM1 and Viper are at least on par with the Ikari, possibly even ahead of it. If done correctly, low debounce doesn't necessarily result in unintended double clicks. See here for further details: https://www.youtube.com/watch?time_continue=1&v=v5BhECVlKJA


----------



## PMB

cdcd said:


> Both XM1 and Viper are at least on par with the Ikari, possibly even ahead of it. If done correctly, low debounce doesn't necessarily result in unintended double clicks. See here for further details: https://www.youtube.com/watch?time_continue=1&v=v5BhECVlKJA



Damn, that was super informative and interesting. Thank you! Even more reasons to change to japanese omrons. The way I understand this, this should even benefit the XM1 somewhat.


----------



## Jonagold

cdcd said:


> Both XM1 and Viper are at least on par with the Ikari, possibly even ahead of it. If done correctly, low debounce doesn't necessarily result in unintended double clicks. See here for further details: https://www.youtube.com/watch?time_continue=1&v=v5BhECVlKJA


Viper has varying latency, usually its +6-9 ms after picking up the mouse, latency goes close to 0 ms only for less relevant clicks after the initial click. This is true for my unit at least..


----------



## PMB

Jonagold said:


> Viper has varying latency, usually its +6-9 ms after picking up the mouse, latency goes close to 0 ms only for less relevant clicks after the initial click. This is true for my unit at least..



Thats terrible to hear tbh. How did you measure it?


----------



## Vibe With Me

Jonagold said:


> Viper has varying latency, usually its +6-9 ms after picking up the mouse, latency goes close to 0 ms only for less relevant clicks after the initial click. This is true for my unit at least..


Can everyone else confirm this?


----------



## badben25

If it is what I think it is, that's not unusual. All Logitech mice also switch to double their click latency when lifted.


----------



## 1ms_hand2eye

Has anyone bought this one?
http://realforce.co.jp/news/20200305/20200305_REALFORCE MOUSE_PR.pdf

Interesting... Capacitive.


----------



## Elrick

1ms_hand2eye said:


> Has anyone bought this one?
> http://realforce.co.jp/news/20200305/20200305_REALFORCE MOUSE_PR.pdf
> 
> Interesting... Capacitive.



My GAWD, finally a Thorpie Mouse for the addicts out there.

Now you can complete your PC input system with the whole Realforce gear, where can you buy it?


----------



## emanonRD

1ms_hand2eye said:


> Has anyone bought this one?
> http://realforce.co.jp/news/20200305/20200305_REALFORCE MOUSE_PR.pdf
> 
> Interesting... Capacitive.





Elrick said:


> My GAWD, finally a Thorpie Mouse for the addicts out there.
> 
> Now you can complete your PC input system with the whole Realforce gear, where can you buy it?



looks like it has a ton of travel.. not sure how good it'll end up being, and at that price point i'd rather wait for future revisions/models of their switches https://twitter.com/keshilog_kessy/status/1235852151978463233


----------



## Elrick

emanonRD said:


> looks like it has a ton of travel.. not sure how good it'll end up being, and at that price point i'd rather wait for future revisions/models of their switches https://twitter.com/keshilog_kessy/status/1235852151978463233



Actually looking forward to it due to being a rampant Realforce addict here. Just love the sound of the mouse, exactly like a Thorpie based keyboard :thumb: .

Have always loved their whole range of full sized keyboards, despite them producing very small amount of 55g models.

Their Mouse would be a natural extension of collecting more products produced by Realforce which have always been of the highest quality, being Japanese of course.


----------



## Jonagold

PMB said:


> Thats terrible to hear tbh. How did you measure it?


I measured it with KeyResponsePK -software. I hit XM1's and Vipers buttons against each other consistently, getting 0-2 ms variance within hundreds of hits. And every time I re-surfaced Viper, there was that 6-9 ms more delay on the first click.


----------



## Jonagold

Vibe With Me said:


> Can everyone else confirm this?


I am also waiting for someone else to confirm this. Could be a problem with only my unit.


----------



## PMB

Jonagold said:


> I measured it with KeyResponsePK -software. I hit XM1's and Vipers buttons against each other consistently, getting 0-2 ms variance within hundreds of hits. And every time I re-surfaced Viper, there was that 6-9 ms more delay on the first click.



So you think this would happen after every mouse lift?


----------



## Jonagold

PMB said:


> So you think this would happen after every mouse lift?


I have tested this like 20 times and every time I lift the mouse it happens, yes. It doesn't seem to matter how long you wait after lifting the mouse, there is always extra delay in the next mouse click.


----------



## microe

Vibe With Me said:


> Can everyone else confirm this?





Jonagold said:


> I am also waiting for someone else to confirm this. Could be a problem with only my unit.


I can confirm my Viper and Deathadder v2 behave this way as well.




badben25 said:


> If it is what I think it is, that's not unusual. All Logitech mice also switch to double their click latency when lifted.


The difference is when you put it back down the delay goes back to normal, for Logitech. The Razer implementation seems to require a button press to clear the added delay from lift-off. Firmware implementation minutiae.


----------



## Jonagold

I had hard time believing that nobody else would notice this, thanks for the confirmation. More mice needs to be tested to confirm the proportion of this issue.


----------



## cdcd

@Razer_TheFiend: Is this a known issue and/or something you can reproduce?


----------



## cdcd

ASUS ROG Pugio II: +11.5 ms relative to SteelSeries Ikari (tested in wired mode, wireless for whatever reason doesn't return any readings)


----------



## ak1234

Any information on new fk2b's (divina), finalmouse ul2 cape town ?


----------



## Athrutep

Wicked Bunny rapid rgb : +4 ms relative to SteelSeries Ikari. Tested against the model D with the bloody software and it alternated between the model d and rapid being faster by 0.1ms


----------



## cdcd

Corsair Dark Core RGB Pro: +0.0 ms relative to SteelSeries Ikari (tested in wired mode)


----------



## badben25

Athrutep said:


> Wicked Bunny rapid rgb : +4 ms relative to SteelSeries Ikari. Tested against the model D with the bloody software and it alternated between the model d and rapid being faster by 0.1ms


Interesting mouse. Can we have a review?



cdcd said:


> Corsair Dark Core RGB Pro: +0.0 ms relative to SteelSeries Ikari (tested in wired mode)


inb4 +20ms after firmware update


----------



## Athrutep

badben25 said:


> Interesting mouse. Can we have a review?


Sure, i can try doing a writeup and take some pictures. Although it might take till next week, since i got some stuff to do.


----------



## cdcd

badben25 said:


> inb4 +20ms after firmware update


I've suggested they should do the same thing ROCCAT is doing (ZeroDebounce) and make it an option, either very low debounce + slam clicks or slightly higher debounce + no slam clicks. Fingers crossed...


----------



## Ainalcar

badben25 said:


> If it is what I think it is, that's not unusual. All Logitech mice also switch to double their click latency when lifted.


Do you have any info on whether XM1 has the same issue?
Thanks


----------



## senileoldman

More or less obscure mouse, but the Valkyrie Pro 2.0 (only G9x clone on the market) has 16.1ms click delay compared to the Ikari.


----------



## jhana108

*Wireless Mouses Faster?*

Howdy,


Can someone tell me how Linus's 



 video fits into this discussion? Linus's test found that several good wireless gaming mouses have an equal and sometimes better click-to-screen-response time as good wired gaming mouses. He used an interesting method: frame by frame analysis with a 1000FPS video camera. I see the click latency table in the first post and it made me wonder if Linus's results support the click latency table or not. I will admit to being a true novice here so I welcome all replies! Thanks! --Jhana108


----------



## TranquilTempest

jhana108 said:


> Howdy,
> 
> 
> Can someone tell me how Linus's Wireless Mouse Response Time Test video fits into this discussion? Linus's test found that several good wireless gaming mouses have an equal and sometimes better click-to-screen-response time as good wired gaming mouses. He used an interesting method: frame by frame analysis with a 1000FPS video camera. I see the click latency table in the first post and it made me wonder if Linus's results support the click latency table or not. I will admit to being a true novice here so I welcome all replies! Thanks! --Jhana108


The test methodology isn't ideal, because some mice go into a power saving mode when not actively moving, and you're clicking at the end of the motion, not the start of it. It would be much better to compare the USB output of a mouse to the output of an independent linear encoder, so that you can compare linearity and latency over the whole motion, not just the start point. It's also dubious to use a high speed camera for this, when you could just read the USB data directly, and avoid all the confounding variables of the PC's render chain, and the monitor's refresh rate.


----------



## badben25

senileoldman said:


> More or less obscure mouse, but the Valkyrie Pro 2.0 (only G9x clone on the market) has 16.1ms click delay compared to the Ikari.


Do you have this mouse with you? I've been curious about it for quite a while.
And apparently you can adjust the click latency in the software. Have you tried doing so?


----------



## ucode

Noticed button up on the M545 wireless seems to take surprisingly longer.











Kinzu v2 USB showing better symmetry









24ms up or down FW 0.98. 

Logitech M150 wireless
Down : Avg 7.92, Min 5.99, Max 10.00, Median	8.00
Up : Avg 39.03, Min 38.00, Max 40.01, Median	39.97
Times in milliseconds
Again wireless showing much longer time for mouse button up

Generic Sigmachip MX8733 USB
Down 16 ms
Up 16ms

Measurements are absolute, not relative.


----------



## ELKR

Has any mouse with optical switches been tested yet for example the razer viper?


----------



## ELKR

I bought a zalman zm-m600r. The click latency chart says fm1.18 to 2.26. Mine came with firmware 2.29.

Was version 2.29 firmware tested?
Is it possible to downgrade firmware?


----------



## cdcd

First time I'm hearing that the M600R came shipped with a FW this recent. 

In general, I'd advise against updating to any FW past the release one on the Zalman. Read from here onward for further details.


----------



## senileoldman

badben25 said:


> Do you have this mouse with you? I've been curious about it for quite a while.
> And apparently you can adjust the click latency in the software. Have you tried doing so?


Yes, I still have it and use it daily. 
No, you can't change the click latency in the software. I can't see any option in the software to change it, but it would be cool if you could. I have the old one without the ugly SCboy logo and there's no option in both softwares.

Could you point me to where you read that?


----------



## Elrick

badben25 said:


> inb4 +20ms after firmware update



With all Dexin made junk, NEVER update the firmware at all.

In fact never install any of Corsairs Software at all, avoid like Razer Synapse because Corsair, will totally *Gordan Ramsay* your Mouse forever with any updates received.


----------



## 0oM

Why is the razer viper/deathadderV2 not on this list did really nobody test them?


----------



## nlse

Elrick said:


> With all Dexin made junk, NEVER update the firmware at all.
> 
> In fact never install any of Corsairs Software at all, avoid like Razer Synapse because Corsair, will totally *Gordan Ramsay* your Mouse forever with any updates received.


are there any test that show, that the latency get worse on for example 
The Viper Mini

from stock, and after an install of Software and change, it will and can be tested to have more latency?


----------



## badben25

senileoldman said:


> Yes, I still have it and use it daily.
> No, you can't change the click latency in the software. I can't see any option in the software to change it, but it would be cool if you could. I have the old one without the ugly SCboy logo and there's no option in both softwares.
> 
> Could you point me to where you read that?


After your post I was researching the mouse online and came across it here:
https://www.reddit.com/r/MouseReview/comments/cl7y0t/noteworthy_by_todays_standards_perhaps_not_but/

I am sure I saw someone mention it elsewhere as well, maybe it was just another reddit comment, can't recall.

I have some questions as a daily driver:
# There are metal 'hooks' poking out on the rear for fitting a grip shell. Do they bother you? Can they be removed?
# The side buttons look just as difficult to reach as they were on the naked G9/G9X. Is it the same case here? I know the force to press them may be different, but actually reaching them might still be an issue because they look small and flush with the side panel.
# How does the size compare to a Kinzu or ZA13? Actual dimensions might be close between these three, but what I really want to know is how it feels to be gripped with large hands. The ZA13 has more overall mass and felt considerably better to me than a Kinzu.
# Provided the mouse was suitable to the user's hand, would you recommend it for low sens FPS gaming? (45cm+/360)


----------



## cdcd

0oM said:


> Why is the razer viper/deathadderV2 not on this list did really nobody test them?


Only way to test optical switches is by using the bump test, which isn't all that accurate. For all intents and purposes they should beat the Ikari consistently though.


----------



## badben25

Since we have a number of questions come in for the XM1 and Viper (i've had some contact me directly via Google), maybe we should add a bump test average for these mice? Or maybe include them on the list with a note? What do you think @cdcd @vanir1337


----------



## cdcd

I have both the XM1 and the Viper Mini/Ultimate, but I'm really bad at bump testing unfortunately. Maybe it's simply due to my choice of the control subject, but I can't get variance down to acceptable levels when doing it.


----------



## ToTheSun!

I was just checking the list in the OP and noticed the Glorious mice are set to the lowest debounce delay, but the Roccat mice are not measured with the Zero Debounce setting. How come?


----------



## senileoldman

badben25 said:


> After your post I was researching the mouse online and came across it here:
> https://www.reddit.com/r/MouseReview/comments/cl7y0t/noteworthy_by_todays_standards_perhaps_not_but/
> 
> I am sure I saw someone mention it elsewhere as well, maybe it was just another reddit comment, can't recall.
> 
> I have some questions as a daily driver:
> # There are metal 'hooks' poking out on the rear for fitting a grip shell. Do they bother you? Can they be removed?
> # The side buttons look just as difficult to reach as they were on the naked G9/G9X. Is it the same case here? I know the force to press them may be different, but actually reaching them might still be an issue because they look small and flush with the side panel.
> # How does the size compare to a Kinzu or ZA13? Actual dimensions might be close between these three, but what I really want to know is how it feels to be gripped with large hands. The ZA13 has more overall mass and felt considerably better to me than a Kinzu.
> # Provided the mouse was suitable to the user's hand, would you recommend it for low sens FPS gaming? (45cm+/360)


That guy is a complete idiot, that's the breathing rate of the profile leds. No wonder he browses Reddit.

1) No. No matter how you hold it, those hooks won't bother yet as they are pretty far back and pretty hidden, they are not prominent at all. The hooks from the original G9 and G9x are more prominent but they still didn't bother me.
2) I use it without a shell. My thumb sits like a cm forward from mouse4 and I can hit them both pretty well. I've never had any problem hitting the sidebuttons on any mouse, so I don't know what to tell you. I hit mouse4 with my thumb and mouse5 with the middle phalanx.
3) I don't have a ZA13, but I do have a Kinzu: 
I palm grip my mouse and the Kinzu feels much smaller in my hands; the grip area of the Kinzu is 5.2cm wide and the grip area of the G9 is 5.7cm wide, while the Kinzu is around 11.2 cm long and the G9 is 9.5cm long. They are both equal in height, around 3cm, but the Kinzu has a sort of pronounced slope that makes it feel much smaller overall and doesn't fill my hand as nicely as the G9x does, which is the thing I like the most about it and dislike about newer mice; they force you to claw grip them and leave more space to control the mouse with your fingers, and I like to control my mouse with only the palm of my hand and wrist.
4) My sens is around 7inch/360, so I don't really know if it would suit you well because I'm not you and I don't have your hands. 
Given time, I can adapt and play the same with any mouse, so I really stopped understanding people who change mice every week thinking their mouse is hindering them.

One thing is the G9 and especially the clone have sharp edges that will bother you if you have thin skin and palm or claw the mouse. It's mostly a fingertip mouse.


----------



## uaokkkkkkkk

cdcd said:


> Only way to test optical switches is by using the bump test, which isn't all that accurate.


I would assume that there would still be a way to get that signal from elsewhere(on the pcb). 

Or just use the signal from one of the regular switches and call it a day.


----------



## qsxcv

actually bump test is fairly accurate (like less than 2ms) if you do it right i.e. firm tap


----------



## badben25

cdcd said:


> I have both the XM1 and the Viper Mini/Ultimate, but I'm really bad at bump testing unfortunately. Maybe it's simply due to my choice of the control subject, but I can't get variance down to acceptable levels when doing it.


I guess someone else with those mice could contribute. It's actually possible to get consistent results, and if you have the time you can even do it 100-200 times and then take the average if you want to be really selective.

Otherwise I'll just add them without a figure just above the Ikari and add a note.

Or maybe you could send the XM1 and Viper to me to do it


----------



## badben25

senileoldman said:


> That guy is a complete idiot, that's the breathing rate of the profile leds. No wonder he browses Reddit.
> 
> 1) No. No matter how you hold it, those hooks won't bother yet as they are pretty far back and pretty hidden, they are not prominent at all. The hooks from the original G9 and G9x are more prominent but they still didn't bother me.
> 2) I use it without a shell. My thumb sits like a cm forward from mouse4 and I can hit them both pretty well. I've never had any problem hitting the sidebuttons on any mouse, so I don't know what to tell you. I hit mouse4 with my thumb and mouse5 with the middle phalanx.
> 3) I don't have a ZA13, but I do have a Kinzu:
> I palm grip my mouse and the Kinzu feels much smaller in my hands; the grip area of the Kinzu is 5.2cm wide and the grip area of the G9 is 5.7cm wide, while the Kinzu is around 11.2 cm long and the G9 is 9.5cm long. They are both equal in height, around 3cm, but the Kinzu has a sort of pronounced slope that makes it feel much smaller overall and doesn't fill my hand as nicely as the G9x does, which is the thing I like the most about it and dislike about newer mice; they force you to claw grip them and leave more space to control the mouse with your fingers, and I like to control my mouse with only the palm of my hand and wrist.
> 4) My sens is around 7inch/360, so I don't really know if it would suit you well because I'm not you and I don't have your hands.
> Given time, I can adapt and play the same with any mouse, so I really stopped understanding people who change mice every week thinking their mouse is hindering them.
> 
> One thing is the G9 and especially the clone have sharp edges that will bother you if you have thin skin and palm or claw the mouse. It's mostly a fingertip mouse.


Thanks a lot for your input. It's a 3360 so I guess it should be alright for low sens in FPS.
The sharp edges you mentioned was one of my concerns too. Sometimes I lift and flick the mouse quickly, which tilts the mouse mid-air as it comes down on the pad. In pictures it looks like the bottom edge is such that it will scrape and be a hindrance to this kind of gameplay.
I'd really like to give it a try but the price and accessibility make it a concern, returning it would become a hassle.


----------



## uaokkkkkkkk

qsxcv said:


> actually bump test is fairly accurate (like less than 2ms) if you do it right i.e. firm tap


Yeah... it's overkill. Yet another reason why I never even really used the "lagbox" that I spent time putting together.

_"It works. That's great and all, but why did I make this?"_

Anyway! Nice to know you're alive and kickin'.


----------



## cdcd

Is there a way to export the data from the Bloody program (I got two of those)? I'm getting more variance with a.exe and it's not as convenient


----------



## ucode

Update to Sigmachip entry. Latency changes with polling rate. Up/down symmetrical. 











Measurements are absolute, not relative.


----------



## Fr3ak

If you bump test the XM1, you need to keep it at the surface or add tape to cover the sensor, otherwise, it's in a different mode resulting in higher latency. The same might apply to other mice.


----------



## ucode

Kinzu V2 1038:1378 FW 6.98, 6ms up or down. Measurements are absolute, not relative.


----------



## nlse

I'm adding it here also

is there anyone that want to do tests with the new Viper Mini Firmware, and know how to do it?


----------



## ELKR

cdcd said:


> First time I'm hearing that the M600R came shipped with a FW this recent.
> 
> In general, I'd advise against updating to any FW past the release one on the Zalman. Read from here onward for further details.


Yeah mine came right out of the box with almost the latest firmware. On another thread I read something along the lines of "I don't mind the 1ms of mcu smoothing. I don't even notice it, and I can disable angle snaping and fix lift of distance now" Not sure where he came up with 1ms of mcu smoothing if it's even true, but based on the thread the earlier versions of firmware did not have this.

The thread you linked is to FW 1.15 and the click latency chart says click latency is FM 1.18 to 2.26. I still don't know if the newer OR older firmware has been tested and why the chart says 1.18 to 2.26 but it would seem that would suggest any older OR newer firmware is inferior or untested.


----------



## ucode

Latency tests for Razer Viper Mini FW 1.00.04 left mouse button

Maximum clicks per second means activating left mouse button up as soon as left mouse button down is received via windows messaging and activating left mouse button down as soon as left mouse button up is received. Ot

Latency somewhat dependent on polling time for lower values.










Times are absolute, not relative.


----------



## badben25

I'll be honest, I think I understand your table but I don't know if my interpretation is correct.
What do you mean by absolute and not relative? How are you getting absolute figures? How are you testing this?


----------



## badben25

Also, does anyone have click latency for G-Wolves Hati/Skoll, and Sensei Ten?


----------



## cdcd

Sensei Ten is +7.8 ms. Thought I posted it somewhere?


----------



## badben25

cdcd said:


> Sensei Ten is +7.8 ms. Thought I posted it somewhere?


Thanks, added.


----------



## cdcd

ROCCAT Kain 200 AIMO (relative to SteelSeries Ikari): 
+7.2 ms (ZeroDebounce disabled/default)
+0.35 ms (ZeroDebounce enabled)

Measured in wired mode since wireless doesn't return any readings.


----------



## cdcd

Sharkoon Light² 200: +4.4 ms relative to SteelSeries Ikari, w/ the latest firmware (4 ms).


----------



## cdcd

SPC Gear LIX Plus: +3.7 ms relative to SteelSeries Ikari (w/ the latest firmware and software, 4 ms debounce delay setting)


----------



## badben25

cdcd said:


> SPC Gear LIX Plus: +3.7 ms relative to SteelSeries Ikari (w/ the latest firmware and software, 4 ms debounce delay setting)


is there a specific version number?


----------



## cdcd

badben25 said:


> is there a specific version number?


Software is version 1.1, no specifics in regard to the firmware. It's still in Beta as well, might be named differently once it's officially released.


----------



## ucode

badben25 said:


> I'll be honest, I think I understand your table but I don't know if my interpretation is correct.
> What do you mean by absolute and not relative? How are you getting absolute figures? How are you testing this?


Not relative as in not measured/compared against another mouse. Measurements are taken by activating the mouse switch by timestamped I/O from the PC and then another timestamp is taken when the button message is received from the OS. Thus it's the time from activation of the mouse button to recieving the Windows message for the mouse button command. Interfacing to the mouse can vary. For instance the Viper Mini was tested via phototransistor activation and alternately (not at the same time) by infrared diode deactivation. Reason for two methods here was due to the infrared diode operating at a frequency of around 2kHz and duty cycle of 75% although during UEFI testing there appears to be an extra 0.5ms activation time every 8ms.

So 5 clicks per second electrically activates mouse button down with timestamp, waits for mouse button down message to be received, records timestamp for that then waits another 100ms, then timestamps and sends the button deactivation (button up), waits for mouse button up message to be received, records timestamp, waits 100ms and so on. This runs a hundred times in succession.

The max clicks per second however activates mouse button down with timestamp, waits for mouse button down message to be recieved, records timestamp and immediately sends the button deactivation (button up) electrically, waits for the button up message and so on for a hundred times in succession. It seems for the Viper Mini if the preceding click up or down lasts less than about 29ms then the following click appears to be penalized. Not sure this would actually be a problem IRL though.

Now if I may be honest. I was happy enough using my mouse as it was until reading this thread but thought it would be interesting to measure latency by means previously stated to see what difference there might be but things spiraled out of control including messing with the Kinzu V2 firmware to give lower click latency. Luckily a poster in another thread helped me realize what was happening. 

So all said and done, the latency test you have devised appears to work really well and there isn't any need for me to do anything really other than returning to some form of normality. So keep up the good work and probably better to leave my results out of the main table IMHO as they would probably be more confusing than helpful. Thanks.


----------



## badben25

It was still interesting to see what you did. In case you go on to test more mice, feel free to post future results here or in your own thread. Rather have them online somewhere.

And yeah, don't obsess over a few ms. It can make some difference but most currently available mice have pretty decent figures without terrible implementation. Just focus on being good at the game you enjoy.


----------



## cdcd

ucode said:


> ...


How did you activate the phototransistor on the Viper Mini? I should be able to use my usual setup (alligator clip) with that.


----------



## ucode

I blocked the infrared diode and used an external transistor from some parts I already had, collector to collector. The emitter of the phototransistor is connected to ground so can just take the ground connection from the onboard USB chord connector. The base of the external transistor was driven from the PC I/O. 










Was able to make the connection by wire contact using some tape so no soldering which is nice. Using the phototransistor is not quite the same as manipulating the infrared diode as there isn't any PWM but results where similar when connected to infrared diode on the right hand side. Perhaps it's meant as a power saving feature? Don't have a scope either, PWM measurements were made using yet another interface to the PC so it might not be exact but should be close.


----------



## cdcd

Thanks, I'll look into it.


----------



## cdcd

ASUS ROG Chakram: +3.2 ms (wired, using 12 ms debounce setting and latest 1.28 firmware)

Dream Machines DM2 Supreme: +3.4 ms (latest firmware, no version number provided)

All figures relative to SteelSeries Ikari.


----------



## anomalyx2

Is there any available information regarding how fast Razer Viper, Bloody T50A by A4tech, or the Endgame Gear XM1 compared to the Steelseries Ikari baseline? Are all of these newer, optical mice on approximately the same level or we really don't know without a reliable "bump test"? Is there a ballpark figure without just going by the manufacturer reported latencies?

Thanks for compiling all this by the way, enjoyed looking through the thread.


----------



## badben25

They are equal, or atleast very close, to the Ikari. Others can explain better to be honest.


----------



## anomalyx2

badben25 said:


> They are equal, or atleast very close, to the Ikari. Others can explain better to be honest.


Okay, that's good to hear. Would any of the new optical mouses be outstanding over the others? Bloody T50A claiming a "0.2 ms" micro-switch, Endgame Gear XM1 claiming to be a "1 ms" response times, and Razer claiming to have a "0.2 ms" response time with an optical switch..


----------



## badben25

anomalyx2 said:


> Okay, that's good to hear. Would any of the new optical mouses be outstanding over the others? Bloody T50A claiming a "0.2 ms" micro-switch, Endgame Gear XM1 claiming to be a "1 ms" response times, and Razer claiming to have a "0.2 ms" response time with an optical switch..


That's hard to say, and I wouldn't believe in any marketing numbers. The only thing I can say is that Bloody has a known history with their optical switches being pretty fast. I reckon the others are just as good, but differentiating between the bunch is a bigger question.


----------



## cdcd

ASUS ROG Pugio II (wired): +3.0 ms relative to SteelSeries Ikari


----------



## badben25

cdcd said:


> ASUS ROG Pugio II (wired): +3.0 ms relative to SteelSeries Ikari


It is already on the list at 11.5ms, so was there some change in the firmware or is there adjustment in the software?


----------



## cdcd

badben25 said:


> It is already on the list at 11.5ms, so was there some change in the firmware or is there adjustment in the software?


Completely forgot about that. Yes, it's indeed a new firmware. Basically, the 12 ms setting has been lowered to 3 ms. No idea when or even if it'll be widely available, though.


----------



## bank1997

Hi, did anyone know click latency of Deathadder V2 that it's using optical switch 70M ?


----------



## Elrick

cdcd said:


> Completely forgot about that. Yes, it's indeed a new firmware. Basically, the 12 ms setting has been lowered to 3 ms. No idea when or even if it'll be widely available, though.



Yeah but lowering it from their standard 12 ms down to *3 ms*, is extremely good here :thumb: .

Just goes to show they can manipulate their firmware to a high degree when it comes to Latencies, which is always good for the end-user.


----------



## dontspamme

Elrick said:


> Yeah but lowering it from their standard 12 ms down to *3 ms*, is extremely good here :thumb: .
> 
> Just goes to show they can manipulate their firmware to a high degree when it comes to Latencies, which is always good for the end-user.


Anybody knows if this applies to the Strix Impact II as well?


----------



## cdcd

dontspamme said:


> Anybody knows if this applies to the Strix Impact II as well?


Unless there's been a new firmware, no.


----------



## cdcd

Abkoncore A530: +13.2 ms relative to SteelSeries Ikari


----------



## itzmydamnlyf

Hi,

Is the zowie EC2, the newer 2019 model with 3360 sensor?

Sent from my RMX1901 using Tapatalk


----------



## Klopfer

itzmydamnlyf said:


> Hi,
> 
> Is the zowie EC2, the newer 2019 model with 3360 sensor?
> 
> Sent from my RMX1901 using Tapatalk


yes
https://zowie.benq.eu/de-de/product/mouse/ec/ec2.html


----------



## cdcd

itzmydamnlyf said:


> Hi,
> 
> Is the zowie EC2, the newer 2019 model with 3360 sensor?
> 
> Sent from my RMX1901 using Tapatalk


If you're referring to the figure listed in the OP, no–that one refers to the older 3090 EC2. The 3360 EC2 should have click latency in the range of 6–8 ms (similar to the S series).


----------



## itzmydamnlyf

Thanks a lot for the reply. Lot of people get confused by that including me. Maybe we can update the chart to mention that its the older one with. 3090 sensor.

Sent from my RMX1901 using Tapatalk


----------



## Klopfer

ahhh lol , I completely misread ur question


----------



## itzmydamnlyf

Klopfer said:


> ahhh lol , I completely misread ur question


No issues. I should have referred to the figure listed in the chart.

Sent from my RMX1901 using Tapatalk


----------



## badben25

The post-Benq ones are 8ms, and they were named EC2-A or EC-2B. They are listed on the sheet as such.

I have added the 2019 releases that reverted to the old name, with a note about the 3360.


----------



## itzmydamnlyf

Awesome work OP. That will clear a lot of confusion.

Sent from my RMX1901 using Tapatalk


----------



## Pimp

can someone retest the rival/sensei 310 with the latest firmware? a fw update came out a few days ago that updates debounce timings (read here: https://techblog.steelseries.com/2020/06/11/new-in-3.17.9.html)


----------



## Melan

Anyone has commatech fkmini v3 for testing?


----------



## cdcd

HK Gaming Mira-S: +3.9 ms relative to SteelSeries Ikari (4 ms debounce time setting)


----------



## itzmydamnlyf

cdcd said:


> HK Gaming Mira-S: +3.9 ms relative to SteelSeries Ikari (4 ms debounce time setting)


Thanks. was looking for this.

Sent from my RMX1901 using Tapatalk


----------



## nlse

has anyone tested or know what latency the Microsoft Intellimouse 1.1 and Microsoft Wheel Optical have?


----------



## kr0w

nlse said:


> has anyone tested or know what latency the Microsoft Intellimouse 1.1 and Microsoft Wheel Optical have?


It's logged on the spreadsheet (Rows 203-205):

15ms @ 125Hz (Default)
12ms @ 500Hz (OC'ed)

The MS MLT04 sensor was measured relative to the Steelseries Ikari Optical (baseline comparison).


----------



## cdcd

ASUS TUF M3: +15.5 ms relative to SteelSeries Ikari (12 ms setting in Armoury II)


----------



## SmashTV

cdcd said:


> ASUS TUF M3: +15.5 ms relative to SteelSeries Ikari (12 ms setting in Armoury II)


Does that mean a review is coming soon?


----------



## cdcd

SmashTV said:


> Does that mean a review is coming soon?


Not too soon, I've found several sensor related issues ASUS is currently looking into.


----------



## xnoreq

The table in #1 is still just a source of huge *misinformation*.

Example: The table lists Sharkoon Light² 200 with +4.4 ms. This is the number that techpowerup published in their review. But for the Endgame Gear XM1 the techpowerup review contains this note: "_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._"

*What's obviously false is the testing methodology, regardless of the mouse.* So all values determined with this method are invalid.


I've explained this before. If you measure click duration (the timespan between the driver receiving a mouse down and mouse up event) then you measure something that is completely irrelevant for FPS games. It's only relevant for applications where you click GUI buttons, where the mouse down itself does not trigger any action. Like browsers. Hence special people on reddit that respond to "it's placebo" comments with: "but I can feel it is faster in my browser." :lachen:

For FPS games, you have to measure the latency between the user pressing down the physical mouse button and the driver receiving a mouse down event.


----------



## cdcd

xnoreq said:


> The table in #1 is still just a source of huge *misinformation*.
> 
> Example: The table lists Sharkoon Light² 200 with +4.4 ms. This is the number that techpowerup published in their review. But for the Endgame Gear XM1 the techpowerup review contains this note: "_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._"
> 
> *What's obviously false is the testing methodology, regardless of the mouse.* So all values determined with this method are invalid.
> 
> 
> I've explained this before. If you measure click duration (the timespan between the driver receiving a mouse down and mouse up event) then you measure something that is completely irrelevant for FPS games. It's only relevant for applications where you click GUI buttons, where the mouse down itself does not trigger any action. Like browsers. Hence special people on reddit that respond to "it's placebo" comments with: "but I can feel it is faster in my browser." :lachen:
> 
> For FPS games, you have to measure the latency between the user pressing down the physical mouse button and the driver receiving a mouse down event.


Non sequitur. By the way, I've already explained this to you before, so not sure why you're bringing up something already refuted.


----------



## nlse

cdcd said:


> Not too soon, I've found several sensor related issues ASUS is currently looking into.


are you asking if they can keep the 4 and 8 ms options as the support doesn't seem to handle it so the mices bought are going back, for no future support and no way to get the firmware if update and its going on forward in bad ways. with m5 and impact 2 also


----------



## nlse

kr0w said:


> It's logged on the spreadsheet (Rows 203-205):
> 
> 15ms @ 125Hz (Default)
> 12ms @ 500Hz (OC'ed)
> 
> The MS MLT04 sensor was measured relative to the Steelseries Ikari Optical (baseline comparison).


if the WMO is clocked to 1000 hz with Sweetlow, is it lower in latency


----------



## cdcd

Abkoncore A660: +19.0 ms relative to SteelSeries Ikari


----------



## badben25

nlse said:


> if the WMO is clocked to 1000 hz with Sweetlow, is it lower in latency


No, it seems to remain at 12ms from 500Hz onwards. This includes going higher than 1000Hz.


----------



## ucode

FWIW the Sigmachip MX8733 sensor I tested which endpoint data is set at 10ms (100Hz) when oc'd from 125Hz to 500Hz and 1000Hz shows similar results when stationary but if the mouse is moving during clicks then click latency reduces further.


----------



## nlse

ucode said:


> FWIW the Sigmachip MX8733 sensor I tested which endpoint data is set at 10ms (100Hz) when oc'd from 125Hz to 500Hz and 1000Hz shows similar results when stationary but if the mouse is moving during clicks then click latency reduces further.


are there some good guides on how to test click latency on you own, that you can link or know of


----------



## ucode

@nlse well there's this thread which has a database for cross reference. 

My own testing was done out of curiosity so methods were my own which meant writing some software to trigger a PC I/O which would electrically trigger a mouse button and the same software would wait for the mouse hook to report it noting the time of each event. Interfacing was made with what I had lying around and modified to deal with switching to ground or switching a voltage, in the case of IR LED to manipulate either the Phototransistor or drop the voltage on the IR LED enough to turn it off. In the case of the Viper Mini the IR was "made" to give a button down and broken for button up unlike what is mentioned in a few reviews that the 'beam is cut/broken' when the button is down.


----------



## 1ms_hand2eye

I hear the G400s is the latest successor to the g5 - in terms of the highest end wired mice by Logitech...
Anyone know the click latency of the G400s? G5 is listed as .5 and the G400 is listed as .7...


----------



## 1ms_hand2eye

Also, I saw the latest version of this doc:
https://docs.google.com/spreadsheets/d/1-QI7-LY9Ul_DsVE4ZOqBQxqqqqrdJ04Ite8IY3AQMds/htmlview

How can the G400s be almost double the latency of the G400 - they have extremely similar hardware - so this kind of casts doubt upon the original G400 measurement, I think...

Any idea what the lowest latency >500hz (that can be overclocked to 1000hz) *wired* mouse is?


----------



## Meat

New to this place but I'm going through my collection of mice doing the click latency test with alligator clips, 100 runs (if that's not enough do tell me)

Magic Refiner MG-3 +3.4 ms (1.1ms faster than my G102)

Gamdias Apollo Extension +1.4 ms (2ms faster than the MG3)

Gamdias Erebos Optical +1.4ms (constantly trading hits with the Apollo, 0.02ms diff average; deviation of 0.3ms a.k.a. too close to call)


----------



## badben25

1ms_hand2eye said:


> I hear the G400s is the latest successor to the g5 - in terms of the highest end wired mice by Logitech...
> Anyone know the click latency of the G400s? G5 is listed as .5 and the G400 is listed as .7...


I am curious, are you looking to buy a G400? Because the Logitech MX518 Legendary (with Hero sensor) is a pretty good option and has the same shape. I'm not even sure if you'll find the G400/G400s anywhere, maybe if you scour ebay.
While the G4xx/MX5xx share the same shape, the slight changes in the grooves on the G5 have never been truly mimicked again.



Meat said:


> New to this place but I'm going through my collection of mice doing the click latency test with alligator clips, 100 runs (if that's not enough do tell me)
> 
> Magic Refiner MG-3 +3.4 ms (1.1ms faster than my G102)
> 
> Gamdias Apollo Extension +1.4 ms (2ms faster than the MG3)
> 
> Gamdias Erebos Optical +1.4ms (constantly trading hits with the Apollo, 0.02ms diff average; deviation of 0.3ms a.k.a. too close to call)


I will add these.


----------



## ucode

1ms_hand2eye said:


> How can the G400s be almost double the latency of the G400 - they have extremely similar hardware - so this kind of casts doubt upon the original G400 measurement, I think...
> 
> Any idea what the lowest latency >500hz (that can be overclocked to 1000hz) *wired* mouse is?


Maybe the same way the SS Kana is 12ms vs Kinzu V2 at 24ms, firmware?

The Sigmachip MX8733 can be oc'd to 1000Hz which can give it a click latency of 3ms and can be bought brand new for about $1 if you look hard enough. Might be good for players who are having trouble with their shots as they can show people the cheap mouse and use it as an excuse and better still if raging then destroying the mouse with your fist isn't going to cost an arm and a leg


----------



## dontspamme

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)?


----------



## uaokkkkkkkk

dontspamme said:


> 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.


----------



## Meat

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)


----------



## Gonzalez07

no info on the xm1?


----------



## cdcd

Zephyr Gaming Mouse: +6.7 ms relative to SteelSeries Ikari


----------



## xnoreq

cdcd said:


> 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. :thumb:


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.


----------



## cdcd

xnoreq said:


> 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. :thumb:
> 
> 
> 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).


----------



## xnoreq

cdcd said:


> 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).





cdcd said:


> 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.


----------



## cdcd

xnoreq said:


> 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 (


----------



## xnoreq

cdcd said:


> Yes, there are other facts influencing click latency, but they tend to be either negligible (


----------



## cdcd

xnoreq said:


> 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.
> 
> 
> 
> 
> 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)? :laugher:
> 
> 
> 
> 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*.


 "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 (A) switch pins as physical contact points and (B) traditional debouncing being used. (A) is true for the XM1, (B) isn't." 

Do you get it now? Anyway, I can't be bothered to explain these things again and again. Other people have tried as well, but you appear to be immune to facts and reasons, and completely set in your tracks. Yes, all the people that wrote these programs, developed the methodology, and compiled the information don't know what they're doing. They're all incompetent, but you're the one (the only one) who saw right through it. It's all invalid. Happy now? Fine, then we can move on.


----------



## xnoreq

cdcd said:


> "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 (A) switch pins as physical contact points and (B) traditional debouncing being used. (A) is true for the XM1, (B) isn't."



*Still wrong. *The program (a.exe) merely requires a left+right button-down click event. Any mouse, regardless of switch implementation, firmware, etc. with a left+right button can produce this.
All you need to do is push the buttons at the same time. I've written this before, learn to read.


What you seem to be referring to is a setup where the two mice switches are _electronically _connected, so that only one button needs to be pushed. This brings with it its own flaws however.
Voltages may be different. Different switches also behave differently producing different signals. Firmware tuned for one switch can result in worse performance if it measures a different switch's signal, etc.

Even for identical mice this method could be problematic since the circuits can behave differently (thinking e.g. of analog filters here) if you connect them together.



Since there is no way of knowing how the connected circuits and firmware will behave (unless you have the schematics and code), you might as well post random numbers. Just as valid. :thumb:


----------



## cdcd

xnoreq said:


> *Still wrong. *The program (a.exe) merely requires a left+right button-down click event. Any mouse, regardless of switch implementation, firmware, etc. with a left+right button can produce this.
> All you need to do is push the buttons at the same time. I've written this before, learn to read.
> 
> 
> What you seem to be referring to is a setup where the two mice switches are _electronically _connected, so that only one button needs to be pushed. This brings with it its own flaws however.
> Voltages may be different. Different switches also behave differently producing different signals. Firmware tuned for one switch can result in worse performance if it measures a different switch's signal, etc.
> 
> Even for identical mice this method could be problematic since the circuits can behave differently (thinking e.g. of analog filters here) if you connect them together.
> 
> 
> 
> Since there is no way of knowing how the connected circuits and firmware will behave (unless you have the schematics and code), you might as well post random numbers. Just as valid. :thumb:


LMAO. So you didn't even get what I was talking about the whole time? Even though I plainly stated it several times? Totally clueless what the setup for this method even looks like, yet making bold claims. This is what, your 8th public demonstration of idiocy? By the way, all of this has been tested and verified. But you keep speculating, it's amusing at this point. Yes, clearly you know better than the guy who wrote the program.


----------



## badben25

@xnoreq

If I may add to this discussion: cdcd has been pretty clear with explaining the premise and methodology so far. I believe I also understand what you are saying, but that is not what this 'project' is for. The "latency" figures you are seeking include factors that we can deem as external, and are unrealistic to measure and apply widely. If you want everything from the physical click of the switch till a response is displayed on screen, it will require that every element in between this chain always stays the same. So the same chipsets and components, the same OS, the same software environment, maybe even the same person person doing the test, and so on.

One could even take this further and start adding different monitors, different game engines, etc. But I digress.

It would be a very comprehensive test, but would it be conclusive? No, because even if the tester maintains pristine test conditions, it becomes (unnecessarily) irrelevant to everyone else, especially with the passage of time. There are too many variables that are not necessary to include, and at that point it is not click latency, or even input lag. It becomes something that covers a very wide area of measurement, call it "real world input delay" if you will.

What we have here is what can be considered true click latency, since it is isolated to the mouse and applicable conditions, it only includes test factors relevant to the test, is a test that works as well as it can given the limitations, and is a figure that is applicable to everyone regardless of (and due to) excluding external factors.

I think what you see as your definition of "click latency" is something else; and I am not sure why you are unable to understand that and insist on pushing your definition instead. If you understand the difference in what you are seeking and what this data provides, then using a different (and more applicable) term would be enough to not go back and forth like this. And if the data here does not give you what you want, that does not make the data misleading; that just means your expectations are different. But what you are doing here is making a "misinformation" argument simply because of this mismatch; surely that's a flawed hill to die on?

As for mice like the XM1 and such, we could probably take an average from a solid sample of bump tests, and add it to the sheet with a note about it. It's not something everyone would agree on, but I would rather have these new mice on the sheet with an asterisk beside them, than not have them at all. I just cannot do this myself because of my real life limitations and will need the community to help.


----------



## xnoreq

cdcd said:


> LMAO. So you didn't even get what I was talking about the whole time? Even though I plainly stated it several times?


LMAO indeed, as this is just another lie.
When I asked for the precise methodologies used all I got was "we're using qsxcv's program" and something about smashing mice/buttons together.

I, on the other hand, always explained precisely what I was talking about. Like: pressing both buttons at the same time.
What don't you understand there? It seems that you are seriously challenged when it comes to reading.




cdcd said:


> This is what, your 8th public demonstration of idiocy?


Pure projection, when you can't even comprehend simple English sentences and you've shown this over and over again on top of making ridiculous claims because of it.




cdcd said:


> By the way, all of this has been tested and verified.


Cool,* please show me how this precisely this testing has been done with all the mouse combinations that have been tested. *I bet you cannot, just like you could not back up the other nonsense that you claimed just to say something that contradicts me.




cdcd said:


> Yes, clearly you know better than the guy who wrote the program.


You keep on saying this, but you clearly don't understand that the program is trivial. It just measures time of left/right button down events.
So it's clear that you are neither a software developer nor an EE, yet keep puffing yourself up as if you were. 

But from what you've written, all you demonstrate is inability to read and comprehend what is written and dangerous superficial knowledge about all of this ... resulting in a big pile of *invalid and misleading data*.


----------



## cdcd

Why are you even still talking to me? You have zero interest in the actual facts. You make this plain as day:



> Cool,* please show me how this precisely this testing has been done with all the mouse combinations that have been tested. *I bet you cannot


Why would I bother if you deem it impossible in the first place? 

You came into this thread all guns blazing, claiming that all the info and data is plain wrong, instead of politely asking how it's done and whether it might be flawed. Several people wasted their time trying to explain it to you, but you don't even make an effort to understand anything. With such a lack of intellectual integrity and genuine interest in this matter I have to assume you're trolling. Anyway, for you it's set in stone that the data is wrong, but who cares? Those who understand what is tested know that it's accurate, so I couldn't care less if some imbecile simply doesn't get it.


----------



## xnoreq

badben25 said:


> I believe I also understand what you are saying, but that is not what this 'project' is for. The "latency" figures you are seeking include factors that we can deem as external, and are unrealistic to measure and apply widely. If you want everything from the physical click of the switch till a response is displayed on screen, it will require that every element in between this chain always stays the same. So the same chipsets and components, the same OS, the same software environment, maybe even the same person person doing the test, and so on.
> 
> One could even take this further and start adding different monitors, different game engines, etc. But I digress.


I think it was you who already made a similar argument in the past and I refuted it.


This time it's worse as you include things (in your objection) that the program actually measures already. So if you object that we can arrive at valid measurements with that then *you're saying that all the data produced here and at TPU is invalid*. And no, I don't want everything till a response is displayed on the screen, or include network lag or any other completely irrelevant thing you can think of.

I've explained it like five times now. Button press to mouse-down event. That's the minimal measurement for the additional latency that a user will experience when pressing a button that is relevant to the mouse.





badben25 said:


> It would be a very comprehensive test, but would it be conclusive?


Pushing buttons and reading numbers off a screen is a comprehensive test?




badben25 said:


> No, because even if the tester maintains pristine test conditions, it becomes (unnecessarily) irrelevant to everyone else, especially with the passage of time. There are too many variables that are not necessary to include, and at that point it is not click latency, or even input lag. It becomes something that covers a very wide area of measurement, call it "real world input delay" if you will.


This objections are also invalid:
1) the measurement are relative, not absolute
2) that's what controls are for


Also, "latency from button pressed to the applicaton receiving the event" is a valid definition for input lag, or click latency. And yes, it is a "real world" measurement, not an artificial one where e.g. you only measure debounce time in isolation using a questionable _methodology that evidently doesn't work for several mice_.





badben25 said:


> What we have here is what can be considered true click latency


No, it's a click debounce latency measurement with a switch connected electrically from another mouse (potentially with a different switch and components in parallel that can change how the circuit behaves) plus transmission etc. latencies until the application receives the mouse-down event.



badben25 said:


> I think what you see as your definition of "click latency" is something else; and I am not sure why you are unable to understand that and insist on pushing your definition instead. If you understand the difference in what you are seeking and what this data provides, then using a different (and more applicable) term would be enough to not go back and forth like this. And if the data here does not give you what you want, that does not make the data misleading; that just means your expectations are different. But what you are doing here is making a "misinformation" argument simply because of this mismatch; surely that's a flawed hill to die on?


Dude, I've asked several times to clarify the precise methodology used and I didn't get any satisfactory answers. Instead I got people with reading disability posting back contradictions to what I said for the sake of contradicting me. That's not helpful.

As I now understand what and how you're measuring (even though it's not clear that all data in the spreadsheet is consistent), I think even more strongly that the data is misleading. In a completely different way than I initially thought, but still..

Your very first posts in this thread link to sources of data that use different methods and e.g. measure exactly what I described initially. Also with "misleading" I mean not matching an average reader's (also of TPU reviews) expectations of what is being measured, not what I or you know.




badben25 said:


> As for mice like the XM1 and such, we could probably take an average from a solid sample of bump tests, and add it to the sheet with a note about it. It's not something everyone would agree on, but I would rather have these new mice on the sheet with an asterisk beside them, than not have them at all. I just cannot do this myself because of my real life limitations and will need the community to help.


There are other easy methods to measure click latency easily and accurately, even in an absolute instead of just relative sense.
But I give up. I'll stick to my cheap mouse with firmware that beats even the "lowest latency" expensive "pro gaming" mice in terms of properly measured click latency and you guys continue posting numbers using a methodology with questionable and misleading and in some case impossible results.
Cya!


----------



## xnoreq

cdcd said:


> Why would I bother if you deem it impossible in the first place?


Reading incomprehension strikes again.
I never said it's impossible. But you evidently can't produce the evidence, as you just evaded again.





cdcd said:


> but you don't even make an effort to understand anything


LMAO, coming from the guy who cannot even understand simple English sentences that contain complicated phrases such as: "pressing both buttons". Hypocrisy and projection strike again.


And it's such a shame because if you'd actually read what I wrote then you could have corrected any misunderstandings with maybe 2 or 3 sentences. But no, contradicting me and pointing out imagined non sequiturs and premises contradicting conclusions (which was also wrong btw) is apparently more important. :wth:


And clearly I'm completely uninterested in any of this. I'm just here dealing with you because I'm a masochist.


----------



## badben25

xnoreq said:


> This time it's worse as you include things (in your objection) that the program actually measures already. So if you object that we can arrive at valid measurements with that then *you're saying that all the data produced here and at TPU is invalid*. And no, I don't want everything till a response is displayed on the screen, or include network lag or any other completely irrelevant thing you can think of.
> 
> I've explained it like five times now. Button press to mouse-down event. That's the minimal measurement for the additional latency that a user will experience when pressing a button that is relevant to the mouse.


I meant/said nothing irrelevant like that, don't get riled up. But button press to response on computer would involve your components, GPU and your monitor at the very least.
But clarify this: that's not what you want, correct? What you want is close to what we have now (ie. application giving output when it gets a response from mouse), but the starting point to be a physical press of a button rather than wiring them up. Is that right?



xnoreq said:


> Pushing buttons and reading numbers off a screen is a comprehensive test?


Strawman-ing? Or is this a discrepancy in what either of us are talking about? What I meant was it might be comprehensive if all components in the chain were accounted for, but as per my question above that's not what you wanted.



xnoreq said:


> Also, "latency from button pressed to the applicaton receiving the event" is a valid definition for input lag, or click latency. And yes, it is a "real world" measurement, not an artificial one where e.g. you only measure debounce time in isolation using a questionable _methodology that evidently doesn't work for several mice_.


*That's what this has been about all along, a difference in accepted definition.* Your definition may be right in it's own way, but that's not what this data is about. Does not make it misleading or incorrect whatsoever. Whether the title of the spreadsheet should be adjusted is a different discussion.

When you say _"methodology that evidently doesn't work for several mice"_ did you consider that when these methods and data first came about, mice like the XM1 etc were not even conceptualized, let alone available? People were making these measurements a few years before this thread even started. That just means the methodology needs to now cater for these new developments, which till date are an iota of the mice involved in such measurements. If such switches/debouncing methods become more common, we can obviously look into what can be done.



xnoreq said:


> Dude, I've asked several times to clarify the precise methodology used and I didn't get any satisfactory answers. Instead I got people with reading disability posting back contradictions to what I said for the sake of contradicting me. That's not helpful.





xnoreq said:


> Your very first posts in this thread link to sources of data that use different methods and e.g. measure exactly what I described initially. Also with "misleading" I mean not matching an average reader's (also of TPU reviews) expectations of what is being measured, not what I or you know.


The precise methodology has been well illustrated and exhausted in older threads by members like qsxcv and uaokk. It is wiring up the mice and testing with the response application developed by one of them. Those threads are linked near the start of this thread. I would get into the nitty gritty to explain it all with history, but I would have to refer to those posts myself, which means finding them. If you really want to dig deep, the burden of wading through all that material is on you I'm afraid. When random people message me asking about doing tests themselves or something, I tell them the same.

Some even older measurement threads/sites are also linked there, which can now be considered defunct. Many of those figures have been replaced with more accurate ones as and when possible. I try to do that whenever possible, and eventhough bump tests (when done properly) give very close results, I also replace them whenever possible. At this point, there are very few, only very old, mice that have figures from using older testing methods. I should have marked them as such on the sheet, but never got around to it and at this point it's probably unnecessary.
In the ideal world, I probably should have also kept the initial posts in this thread up to date. Ultimately, keeping the sheet accurate and updated is what matters, and that's been done diligently.

I have seen you bring up TPU in your posts, but I am not involved with TPU whatsoever so can't comment there.



xnoreq said:


> Another method would be to measure a relative delay by recording the sound of the mechanical switch clicking. Pro audio recording interfaces (as I have lying around) have a stable, configurable and low latency that can be measured on its own.
> Add that to the measured latency and you can even make "absolute" click latency measurements - without having to use any hacks with questionable results,


I would actually be interested in seeing that, so why don't you do it with whatever mice you have access to? In case you only have 1 or 2 performance mice, that's okay for a start.
That would have been more productive too, instead of making all these posts with this frankly terrible tone you have. There's much better ways of bringing up a discussion. It's good to see the conviction you have, but not about the wrong things and not in the manner you do. That just makes you come across like an educated idiot, and get into ridiculous internet arguments.

Bye.


----------



## ToTheSun!

This sub-forum has been great lately for the assburger trolls.


----------



## Athrutep

ToTheSun! said:


> This sub-forum has been great lately for the assburger trolls.


Quiet worm, bow down to the 2020 account master race. I got subdued already by the insanely quick-witted uberlords and many more will follow.



On a more serious note, is the Model O your main mouse now?


----------



## ToTheSun!

Athrutep said:


> On a more serious note, is the Model O your main mouse now?


With the improvements they made to the newer revisions, absolutely. I can't really find flaws on my unit. It's the perfect shape, weight, and coating for me, and the buttons are objectively great (crispy, and the scroll wheel is even lighter than the one on the first batches). The cable is pretty good, and these are the best stock feet I've tried so far.


----------



## Athrutep

ToTheSun! said:


> With the improvements they made to the newer revisions, absolutely. I can't really find flaws on my unit. It's the perfect shape, weight, and coating for me, and the buttons are objectively great (crispy, and the scroll wheel is even lighter than the one on the first batches). The cable is pretty good, and these are the best stock feet I've tried so far.


Good to hear. Whenever my first batch craps out on me, i can just get an updated one. So far no issues with mine though. I guess i got lucky.


----------



## ToTheSun!

Athrutep said:


> Good to hear. Whenever my first batch craps out on me, i can just get an updated one. So far no issues with mine though. I guess i got lucky.


I'd suggest you at least grab a new set of skates and replace the ones you have. The difference is huge.


----------



## b0z0

Athrutep said:


> Good to hear. Whenever my first batch craps out on me, i can just get an updated one. So far no issues with mine though. I guess i got lucky.


Yeah My Model O from the first batch suffered from the squeaky right mouse button, but other than that the mouse is amazing. I'm currently waiting for the Model D-.


----------



## Elrick

ToTheSun! said:


> This sub-forum has been great lately for the assburger trolls.



At least they taste good with some ketchup or mayonnaise, applied :wubsmiley .


----------



## Athrutep

ToTheSun! said:


> I'd suggest you at least grab a new set of skates and replace the ones you have. The difference is huge.


The new ceramic ones or the pfte ones? I already replaced the original ones with the tiger gaming arc, which i absolutely love.


----------



## ToTheSun!

Athrutep said:


> The new ceramic ones or the pfte ones? I already replaced the original ones with the tiger gaming arc, which i absolutely love.


I meant the PTFE ones, but I guess you're all set with your aftermarket ones.


----------



## OCmember

Is there any firmware for the Bloody SP30? I've had it for the past 4-5 months and it seems like it's changed since then due to degradation or electrical issues.

Thanks


----------



## SmashTV

ToTheSun! said:


> This sub-forum has been great lately for the assburger trolls.


If the mods owned a bank, it would be perpetually robbed.


----------



## Klopfer

anyone has it for the ROCCAT BURST PRO (LIGHTWEIGHT OPTICAL AMBIDEXTROUS) ?


----------



## Elrick

Klopfer said:


> anyone has it for the ROCCAT BURST PRO (LIGHTWEIGHT OPTICAL AMBIDEXTROUS) ?



Don't you mean this;

https://en.roccat.org/Headsets/Khan-Pro

There is nothing on their official website, referring to your quote;

https://de.roccat.org/Mice


----------



## Klopfer

Elrick said:


> Don't you mean this;
> 
> https://en.roccat.org/Headsets/Khan-Pro
> 
> There is nothing on their official website, referring to your quote;
> 
> https://de.roccat.org/Mice


ofc I dont mean a Headset ... !
so had to wait a bit I guess ... 
I think it would be near on the same level as the other actually released Roccat Mice ...


----------



## SmashTV

Klopfer said:


> anyone has it for the ROCCAT BURST PRO (LIGHTWEIGHT OPTICAL AMBIDEXTROUS) ?


Now now, not so fast. Tell me more.

This is something I've been suggesting Roccat do since I got to use a Kain.


----------



## Klopfer

SmashTV said:


> Now now, not so fast. Tell me more.
> 
> This is something I've been suggesting Roccat do since I got to use a Kain.


I found that somewhere in the Internet ( some Asian site ) 
also 2 new headsets ( stereo and USB 7.1 ) 
and new ( RGB ? ) Mousepads 
and new Keyboard 
from Roccat , but just the names , no pics , no data , nothing ...


----------



## SmashTV

Klopfer said:


> I found that somewhere in the Internet ( some Asian site )
> also 2 new headsets ( stereo and USB 7.1 )
> and new ( RGB ? ) Mousepads
> and new Keyboard
> from Roccat , but just the names , no pics , no data , nothing ...


Time to section out the money, just in case. 

Thank you for the info.


----------



## Elrick

SmashTV said:


> Time to section out the money, just in case.
> 
> Thank you for the info.



There is ALWAYS money set aside for any new Roccat gear, regardless of any given situation.

*This is my current FAVE company for Mice this year.*


----------



## ucode

Klopfer said:


> I found that somewhere in the Internet ( some Asian site )


Was it on a porn site or something? Just wondering why you didn't post the link.


----------



## Melan

Must have been mouse porn site.


----------



## Klopfer

ucode said:


> Was it on a porn site or something? Just wondering why you didn't post the link.


It was late... On the next day I thought the same , but that news were deleted
Edit:
was that site
http://www.jaywork.co.kr


----------



## abort

Anyone measured this for the refreshed BenQ Zowie ZA series (ZA11-B, ZA12-B, ZA13-B)?


----------



## Athrutep

abort said:


> Anyone measured this for the refreshed BenQ Zowie ZA series (ZA11-B, ZA12-B, ZA13-B)?


Probably the same as the the EC refresh and S series 8ms . I can test it next week though.


----------



## badben25

Athrutep said:


> Probably the same as the the EC refresh and S series 8ms . I can test it next week though.


We'd appreciate it.


----------



## Athrutep

Tested the ZA11-B against the G403 3366 wired and the ZA11-B was around 3.3ms-3.9ms slower than the G403 (tested with the bloody software, so its not 100% accurate but a good indicator).


----------



## cdcd

Glorious Model D-: +3.8 ms relative to SteelSeries Ikari (same as O/O-/D)
ASUS TUF M3: +10.7 ms relative to SteelSeries Ikari w/ firmware 1.0.11


----------



## cdcd

HK Gaming Mira-M: same as Mira-S

Sharkoon Light² 100: +3.9 ms relative to SteelSeries Ikari


----------



## Meat

Seenda LC-1601: +3.9 ms (2.45 slower than my Gamdias Apollo)

Combaterwing CW10 +3.6 (2.2ms slower than my Gamdias Apollo)


----------



## cdcd

Mountain Makalu 67: +5.0 ms (2 ms setting)

VAXEE ZYGEN NP-01: +1.2 ms (2 ms setting), +3.8 ms (4 ms), and +7.8 ms (8 ms)

All figures relative to SteelSeries Ikari.


----------



## Meat

Zalman ZM-GM7 +20ms (18,6 ms slower than my Gamdias Apollo)
(Why use optical switches if you're going to do this?, lots of variance too; goes from 22,8 ms slower to 14,5 ms slower than my Apollo)

Just for others, you can actually measure the click latency of the LK v1 switches using alligator clips like this;








It has to be that pin specifically, but it works like with any other mouse.


----------



## cdcd

Just to add my own findings to the post above:


Either the left or right bottom-row pin can be used.
Variance will most likely be high (expect up to 10 ms).
Verifying this method is possible by wiring LMB and RMB together. To do so, wire the left with the right pin together or the right with the left one. If done right, you'll exclusively see 0.0000 readings. From this we can conclude that the variance isn't introduced externally.
Since there is no variance between LMB and RMB, I strongly suspect that the high variance is native to the switches/logic/firmware used.


----------



## Meat

Bloody A90 +0.2ms (1.2ms faster than my Apollo, 250 clicks, variance of about 2.5ms (from 2.2ms faster to 0.3 slower))


----------



## cdcd

ASUS ROG Chakram Core: -0.9 ms relative to SteelSeries Ikari


----------



## badben25

cdcd said:


> ASUS ROG Chakram Core: -0.9 ms relative to SteelSeries Ikari


WHAT
At what firmware? And what relevant settings in the software?


----------



## cdcd

badben25 said:


> WHAT
> At what firmware? And what relevant settings in the software?


Latest firmware (forgot the exact number). Settings within Armoury Crate don't matter, the button reponse time slider isn't functional.


----------



## badben25

cdcd said:


> Latest firmware (forgot the exact number). Settings within Armoury Crate don't matter, the button reponse time slider isn't functional.


Sounds like one of those cases where early firmware has low latency, and then it gets higher with further updates. Keep an eye out if you can so we can update the sheet. Thanks.


----------



## cdcd

badben25 said:


> Sounds like one of those cases where early firmware has low latency, and then it gets higher with further updates. Keep an eye out if you can so we can update the sheet. Thanks.


There's a decent chance it's related to NVIDIA Reflex—the Chakram Core is among the first Reflex compatible mice, so ASUS has a vested interested in being able to show a nice and low figure within Reflex latency analyzer. We'll have to see what it'll be like on future Reflex compatible mice.


----------



## Melan

Roccat Burst Core ~5ms faster relative to G305. Might want to verify that though.


----------



## cdcd

Melan said:


> Roccat Burst Core ~5ms faster relative to G305. Might want to verify that though.


I'm getting similar results, so appears to be within 1 ms of the SteelSeries Ikari.


----------



## b0z0

cdcd said:


> I'm getting similar results, so appears to be within 1 ms of the SteelSeries Ikari.


Interesting. May have to pick one up.


----------



## badben25

cdcd said:


> I'm getting similar results, so appears to be within 1 ms of the SteelSeries Ikari.


If you could give me something more exact, along with FW version, I'll put it up.


----------



## cdcd

badben25 said:


> If you could give me something more exact, along with FW version, I'll put it up.


Can only do bump test, so not confident in numbers more precise than that. Firmware was latest, not sure about the exact version number.

I do have something else though:
HK Gaming Naos-M: +3.8 ms relative to SteelSeries Ikari


----------



## badben25

cdcd said:


> Can only do bump test, so not confident in numbers more precise than that. Firmware was latest, not sure about the exact version number.
> 
> I do have something else though:
> HK Gaming Naos-M: +3.8 ms relative to SteelSeries Ikari


I think at this point it might be fair to have the numbers with a note rather than not have them at all. With an acceptable number of bumps, let's add a figure for this mouse, as well as for the Vipers and XM1. I would've done it myself but I simply cannot afford to spend on them, so thanks in advance.


----------



## cdcd

Not sure how to best present those numbers (all relative to Ikari):
-wired Razer mice w/ optical switches: -0.5 to +0.5 ms
-wireless Razer mice w/ optical switches: same as above, but add ~1 ms for wireless delay
-ROCCAT Burst Pro: +0 to +1.0 ms
-Endgame Gear XM1: -1 to +0 ms


----------



## Melan

I'd guess by the highest value. The difference is negligible.


----------



## badben25

Melan said:


> I'd guess by the highest value. The difference is negligible.


Yes that's what I normally do. I'm gonna add them now with a note for each.


----------



## uaokkkkkkkk

cdcd said:


> Can only do bump test


I wonder if you could do it via light. As in, expose the ir sensors of two different mice simultaneously with a beam of light. 

I might as well just throw that out there... even though it sounds pretty "retarled"...


----------



## cdcd

uaokkkkkkkk said:


> I wonder if you could do it via light. As in, expose the ir sensors of two different mice simultaneously with a beam of light.
> 
> I might as well just throw that out there... even though it sounds pretty "retarled"...


There's this method: Click Latencies compiled


----------



## cdcd

Glorious Model O Wireless: +1.9 ms relative to SteelSeries Ikari (2 ms setting within Glorious Core, latest firmware w/ unspecified version number). Tested in wired mode.


----------



## cdcd

HyperX Pulsefire Haste: +4.5 ms relative to SteelSeries Ikari (Firmware: 1.1.0.3)


----------



## Melan

NVIDIA/Reflex-Latency-Analyzer-Mouse-Database


Database containing all NVIDIA Reflex Latency Analyzer compatible mice - NVIDIA/Reflex-Latency-Analyzer-Mouse-Database




github.com


----------



## cdcd

Xtrfy M42: +3.8 ms relative to SteelSeries Ikari

I also need to rectify my submitted value for the Xtrfy M4. I've found a typo in my year old Excel sheet. The corrected value is +2.0 ms.


----------



## cdcd

Redragon M913 Impact Elite: +13.1 ms relative to SteelSeries Ikari

Same as M686 Vampire Elite. Tested in wired mode.


----------



## Arxeal

Melan said:


> NVIDIA/Reflex-Latency-Analyzer-Mouse-Database
> 
> 
> Database containing all NVIDIA Reflex Latency Analyzer compatible mice - NVIDIA/Reflex-Latency-Analyzer-Mouse-Database
> 
> 
> 
> 
> github.com


Nvidia has Logitech mouse measured at lower click latency, especially the GPXWSL at 0.8ms, even lower than Razer vipers.
Maybe their methodology by pass the debounce time or something.


----------



## cdcd

Dream Machines DM6 Holey S: +4.2 ms relative to SteelSeries Ikari

Tested at 500 Hz due to 1000 Hz being generally unreliable/not stable.


----------



## cdcd

Redragon/LTC MoshPit WHM-01: +16.2 ms relative to SteelSeries Ikari. Tested in wired mode.


----------



## EastCoast

So help me understand this again.
If it's -0.X ms that means it's 0ms?

And is there any meaningful improvement between 0ms and 1ms latency?


----------



## frankster

EastCoast said:


> So help me understand this again.
> If it's -0.X ms that means it's 0ms?


-0.X means it has slightly lower latency than the reference mouse. The reference mouse therefore has 0 latency relative to itself, but the absolute latency of the reference mouse will of course be higher than 0 ms.



EastCoast said:


> And is there any meaningful improvement between 0ms and 1ms latency?


1) The human reaction time to a visual stimulus is approximately 200ms (with a fair amount of variance across individuals, but even within the reaction times of an individual).
2) The USB mouse polling period is probably between 1 and 8 ms (depending on your mouse).

Because of 1) sub-ms latency improvements are in the range to give a small edge to reaction times, but it is a very small edge.
Because of 2) sub-ms latency improvements will sometimes get a click registered 1 poll sooner, but sometimes/often will not get the click registered any sooner.


----------



## cdcd

Mad Catz R.A.T. 8+ ADV: +19.4 ms relative to SteelSeries Ikari


----------



## Meat

Redragon M601-3: +10.9ms relative to the Ikari


----------



## uaokkkkkkkk

cdcd said:


> Mad Catz R.A.T. 8+ ADV: +19.4 ms relative to SteelSeries Ikari


From my experience, that's practically unusable.


----------



## cdcd

ASUS ROG Keris Wireless: +2.9 ms relative to SteelSeries Ikari

Tested in wired mode. Firmware version is 11.11.12.


----------



## cdcd

SteelSeries Aerox 3 Wireless: +5.8 ms relative to SteelSeries Ikari

Tested in wired mode. Firmware version (mouse) is 1.6.8.


----------



## cdcd

Dream Machines DM6 Holey Duo: +16.2 ms relative to SteelSeries Ikari

Same as LTC MoshPit WHM-01, which is no surprise given the identical internals. Tested in wired mode.


----------



## dlul

how do you get your hands on so many mice ?


----------



## SmashTV

dlul said:


> how do you get your hands on so many mice ?


They set the mouse traps and use whatever gets caught.


----------



## cdcd

Sharkoon Light² S: +5.9 ms relative to SteelSeries Ikari


----------



## cdcd

Mad Catz M.O.J.O. M1: +0.8 ms relative to SteelSeries Ikari


----------



## cdcd

Corsair Katar Pro XT: +5.3 ms relative to SteelSeries Ikari


----------



## Ulexos

Neat thread/spreadsheet, many thanks to everyone involved! Has anyone compared the Razer Viper 8KHz and Zaunkoenig M1K yet? Am curious to see where they place on this.


----------



## cdcd

Pulsar Xlite: +4.3 ms relative to SteelSeries Ikari 

Tested at 2 ms debounce setting.


----------



## sprite08

endgame xm1 = 0ms lick latency at fw v1.62. Fw v2.00, 2.29 have much higher latency (same zowie)
G403 hero after update fw 25k dpi with zowie equivalent latency. when I do the bump test


----------



## Elrick

sprite08 said:


> endgame xm1 = 0ms lick latency at fw v1.62.


Never upgrade the firmware at all with this Model. Praise v1.62.


----------



## Meat

sprite08 said:


> endgame xm1 = 0ms lick latency at fw v1.62. Fw v2.00, 2.29 have much higher latency (same zowie)
> G403 hero after update fw 25k dpi with zowie equivalent latency. when I do the bump test


I don't know why they opted to change things around so much post-2.0, not only did the click latency seemingly worsen (caveat: I'm not that good at bump testing) but they also seemingly changed the whole way they register clicks, I don't exactly know what part is "analogue" but on 1.62 you could get clicks of 2-3ms duration to register but on version newer than and including 2.0 all the clicks would just be extended to ~20ms.
I assume the whole "analogue" tech is still present, otherwise somebody would've maybe tested the XM1 with a higher fw in a better way than bump testing.


----------



## cdcd

EVGA X17: +7.4 ms relative to SteelSeries Ikari

Tested at 8000 Hz, lower polling rates will have accordingly higher latency.


----------



## Elrick

sprite08 said:


> endgame xm1 = 0ms lick latency at fw v1.62.


Pity you can't download that firmware version anymore  .


----------



## Meat

ThunderX3 TM20: +10.8ms to Ikari Optical


----------



## sprite08

Elrick said:


> Pity you can't download that firmware version anymore  .








V1.62.rar







drive.google.com


----------



## Elrick

sprite08 said:


> V1.62.rar
> 
> 
> 
> 
> 
> 
> 
> drive.google.com




Thank you.


----------



## bruh69

so from this is the Rog Chakram Core the best?


----------



## nlse

Elrick said:


> Thank you.


----------



## fellcbr1

Anyone had done any testing on the newer Mad Catz R.A.T. 2 *+ *i found the shape to be extremely comfortable compared to logitech egg shapes


----------



## Elrick

fellcbr1 said:


> Anyone had done any testing on the newer Mad Catz R.A.T. 2 *+ *i found the shape to be extremely comfortable compared to logitech egg shapes


Unbelievable that this Company is still around, despite so many troubles.

Although their new releases seem quite interesting, despite all their previous mistakes 🆒 .

Love this Youtube video;


----------



## nlse

Elrick said:


> Unbelievable that this Company is still around, despite so many troubles.
> 
> Although their new releases seem quite interesting, despite all their previous mistakes 🆒 .
> 
> Love this Youtube video;


Zy's rail is out on the 30th


----------



## Axaion

nlse said:


> Zy's rail is out on the 30th


Dont forget to wash your face first


----------



## Elrick

nlse said:


> Zy's rail is out on the 30th


There's plenty of mice models to go around here. But the 'Zy's Rail' is really just for the youngsters, too small for me to effectively use.

I'm never loyal to any one company, when it comes to Mice or Keyboards, as long as it fits my daily usage.


----------



## uaokkkkkkkk

cdcd said:


> EVGA X17


ODM = Acrox Technologies.

Sorry, I only typed that out because the name was "on the tip of my tongue" for way too long today and that annoyed the hell out of me.


----------



## nlse

Axaion said:


> Dont forget to wash your face first


For pre-order


----------



## qsxcv

uaokkkkkkkk said:


> ODM = Acrox Technologies.
> 
> Sorry, I only typed that out because the name was "on the tip of my tongue" for way too long today and that annoyed the hell out of me.


where've you been and how do you figure out these things lol


----------



## Klopfer

uaokkkkkkkk said:


> ODM = Acrox Technologies.
> 
> Sorry, I only typed that out because the name was "on the tip of my tongue" for way too long today and that annoyed the hell out of me.


but is that a bad thing ? 
some of their producst I recognize as HP and Roccat ...


----------



## Meat

Dare-U (DareU?) A960 3389 = +19,7 ms to Ikari Optical

(Also Redragon M719 = +9.3 ms to Ikari Optical, but the deviation in click latency is so bizarrely bad it doesn't really represent it well (~10ms of deviation between clicks))


----------



## Elrick

Meat said:


> Dare-U (DareU?) A960 3389 = +19,7 ms to Ikari Optical
> 
> (Also Redragon M719 = +9.3 ms to Ikari Optical, but the deviation in click latency is so bizarrely bad it doesn't really represent it well (~10ms of deviation between clicks))


Both are perfectly fine for '*Office Mouse*' status and nothing more......


----------



## cdcd

Thermaltake ARGENT M5 RGB: +8.1 ms relative to SteelSeries Ikari (button response time set to 8 ms)
Thermaltake ARGENT M5 Wireless RGB: same as above (tested in wired mode)

Corsair Sabre RGB Pro: +1.6 ms w/ button response optimization set to on (default), +5.1 ms with BRO set to off


----------



## cdcd

Sharkoon Light² 180: +4.4 ms relative to SteelSeries Ikari (set to 2 ms debounce time within the software)


----------



## Elrick

cdcd said:


> Corsair Sabre RGB Pro: +1.6 ms w/ button response optimization set to on (default), +5.1 ms with BRO set to off


Just received my plain Jane NO - RGB version of Sabre Pro, from Jeff Bezos.

Surprised how decent the shape is, a super fine IE 3.0 wannabe using a decent sensor and switches. Downside, NO huanos installed anywhere within this design.

Whoops, the ugly but fast iCUE software driver updated the mouse firmware to v1.9.23, behind my back. Talk about deceitful, busy updating itself like Trojan 10.


----------



## nlse

Does any one have an update on the Corsair Harpoon RGB Pro with latencies and before or after the later 3,08 firmware update

is it possible to revert to an older firmware with that mouse


----------



## cdcd

Xtrfy MZ1: +4.3 ms relative to SteelSeries Ikari

Tested at 2 ms button setting. 4 ms is approximately 8 ms, 8 ms is 16 ms, and 12 ms is 24 ms. Standard deviation at 2 ms is 0.98, but increases exponentially at higher settings.


----------



## cdcd

SteelSeries Rival 5: +9.5 ms relative to SteelSeries Ikari (SD: 0.79 ms)


----------



## cdcd

ASUS ROG Keris: -0.9 ms relative to SteelSeries Ikari (SD: 0.94 ms)

ASUS ROG Gladius III: -0.5 ms (SD: 1.04 ms)

ASUS ROG Gladius III Wireless: +0.2 ms (SD: 0.68 ms). Tested in wired mode.


----------



## Meat

Xtrfy M1: +6.4ms to Ikari Optical


----------



## cdcd

MSI Clutch GM41 Lightweight: +3.6 ms relative to SteelSeries Ikari (STDEV: 0.60 ms)

MSI Clutch GM41 Lightweight Wireless: +2.3 ms (STDEV: 0.62 ms). Tested in wired mode.


----------



## cdcd

Redragon M808 Storm Pro: +13.1 ms relative to SteelSeries Ikari (StDev=0.51 ms). Tested in wired mode.


----------



## uaokkkkkkkk

cdcd said:


> Not sure how to best present those numbers (all relative to Ikari):
> -wired Razer mice w/ optical switches: -0.5 to +0.5 ms
> -wireless Razer mice w/ optical switches: same as above, but add ~1 ms for wireless delay
> -ROCCAT Burst Pro: +0 to +1.0 ms
> -Endgame Gear XM1: -1 to +0 ms


How's the LDAT? Having any fun with it?


----------



## cdcd

uaokkkkkkkk said:


> How's the LDAT? Having any fun with it?












Quite good, but some room for improvement once I get a better monitor.


----------



## cdcd

Zowie EC3-C, relative to SteelSeries Ikari:
+7.8 ms ("Normal Response," default), STDEV=0.88 ms
+4.0 ms ("Fast Reponse"), STDEV=0.95 ms


----------



## badben25

cdcd said:


> Zowie EC3-C, relative to SteelSeries Ikari:
> +7.8 ms ("Normal Response," default), STDEV=0.88 ms
> +4.0 ms ("Fast Reponse"), STDEV=0.95 ms


What do the 2 types of responses mean? Does the EC3 have some click latency settings?


----------



## Klopfer

yes it has


----------



## cdcd

Default is normal response, fast response can be enabled by holding the back button (mouse 4) pressed while plugging in.


----------



## gunit2004

cdcd said:


> Quite good, but some room for improvement once I get a better monitor.


Oh, this is the first time I've seen a MM720 click latency result done with the LDAT.

If you ever had the time or were interested, I wonder if you could try going into the MasterPlus software and exporting a mouse profile (it will give you a .json file that is easily editable via Notepad) and within that .json file, go to the "button_respond_time" value and change it. By default 4ms within the software will have a value of 1, 8ms = 2, 12ms = 3, 16ms = 4, etc all the way up to 8 which is 32ms in the software.

Basically I was wondering if you see an difference in click latency on the LDAT with the MM720 if you were to change the "button_respond_time" value to something even lower than 1? I would suggest trying 0 and it even seems to accept negative values as low as -500...

Would love to know with solid proof if this actually does anything or would just be placebo?

Of course, after editing the .json value with an edited "button_respond_time" value, the .json file has to be re-imported to the mouse via the MasterPlus software and then the test should be done immediately afterwards. The reason being that if the MasterPlus software is opened a 2nd time afterwards, it does seem to overwrite any profile that you had imported to the mouse during the previous session. So basically the edited .json file needs to be imported to the mouse any time the MasterPlus software is opened.

Anyways.. just something interesting in case you had some time to test... would greatly appreciate it as no one really has access to that elusive LDAT except reviewers lol.


----------



## cdcd

I'll be tinkering with MasterPlus next week anyway, so can give it a try as well then.


----------



## Klopfer

MM731 review is coming?


----------



## cdcd

Sure is!


----------



## badben25

Klopfer said:


> yes it has





cdcd said:


> Default is normal response, fast response can be enabled by holding the back button (mouse 4) pressed while plugging in.


Good to know. Is this something they mention in the manual?


----------



## cdcd

badben25 said:


> Good to know. Is this something they mention in the manual?


It is indeed mentioned in the included user guide.


----------



## cdcd

Marsback Zephyr Pro, relative to SteelSeries Ikari:

"1 ms" setting: +0.2 ms (STDEV=0.84 ms)
"20 ms" setting (default): +2.0 ms (STDEV=0.70 ms)
"100 ms" setting: +9.9 ms (STDEV=0.76 ms)


----------



## cdcd

gunit2004 said:


> ...


Finally got to it. MasterPlus+ forced me to upgrade the firmware to 1.3, which has two effects: (1) Button Response Time slider no longer being functional (fixed value), and (2) latency being roughly 3 ms lower now. Accordingly, the import/export thing did nothing, either.


----------



## cdcd

Ninjutso Origin One X: +13.1 ms relative to Ikari (STDEV=0.49 ms)

Tested in wired mode. Identical to all other mice equipped with the Compx CX58210, as expected.


----------



## uaokkkkkkkk

cdcd said:


> Quite good, but some room for improvement once I get a better monitor.


Why? I thought the process was pretty simple- oh~ I see... I thought the LDAT was an even more streamlined lagbox.

lol its sousu's improvised diy method from 2009- just with actual tech and a corporate budget behind it.


----------



## umea

cdcd said:


> Ninjutso Origin One X: +13.1 ms relative to Ikari (STDEV=0.49 ms)
> 
> Tested in wired mode. Identical to all other mice equipped with the Compx CX58210, as expected.


Is there no debounce option at all? Very disappointing if that's the case


----------



## cdcd

umea said:


> Is there no debounce option at all? Very disappointing if that's the case


Unfortunately, there is none.


----------



## Axaion

Thats unfortunate, but i also feel like ninjutso needs to be called out for having this on their website..
Betting the sensor latency is also higher than most wired.
..and yes while they say "some wired" they also say "no input lag. no delays"


----------



## Elrick

Axaion said:


> View attachment 2521655


Smells like more useless PR, without any Proof .

Much like what the whole world runs on, these days.


----------



## Axaion

Elrick said:


> Smells like more useless PR, without any Proof .
> 
> Much like what the whole world runs on, these days.


I 100% agree, which is why i put it up there, even though id LOVE a larger version with a wire, but calling out blatant bullshit needs to be done too


----------



## cdcd

SPC Gear GEM Plus:
Key Response set to 1 ms within the software: +0.6 ms relative to Ikari
Key Response set to 20 ms within the software (default): +19.5 ms relative to Ikari

Scales linearly up to 100 ms. Latest firmware is required for this setting to function (don't know the version number).


----------



## QyXyy

Hi guys where i can find Steelseries firmware 1.3.1 for SS Xai , for minimal click latency?


----------



## gunit2004

cdcd said:


> Finally got to it. MasterPlus+ forced me to upgrade the firmware to 1.3, which has two effects: (1) Button Response Time slider no longer being functional (fixed value), and (2) latency being roughly 3 ms lower now. Accordingly, the import/export thing did nothing, either.


Thanks for checking into that.

They seem to have released another firmware recently (1.4). I wonder if they reduced the latency some more.


----------



## uaokkkkkkkk

QyXyy said:


> Hi guys where i can find Steelseries firmware 1.3.1 for SS Xai , for minimal click latency?





uaokkkkkkkk said:


> *Oh, and 1.4.2 has the same fw debounce delay as 1.3.1*


Anyway...

@cdcd Have you pestered Cougar for a review sample of the Airblader? Shape looked interesting.


----------



## abso

Has there been done any testing about USB ports that run through the chipset vs the ones that rund directly through the CPU when it comes to input latency? I just read about it in my new mainboard manual and was wondering if it makes a difference what type of USB port I use for latency sensitive devices.


----------



## cdcd

uaokkkkkkkk said:


> Anyway...
> 
> @cdcd Have you pestered Cougar for a review sample of the Airblader? Shape looked interesting.


Don't have a Cougar contact, not sure there even is one.


----------



## gunit2004

There is a newer firmware manually downloadable here for the MM720: https://masterplus.coolermaster.com/downloads/file/MM720/

This 4.01 version seems to be slightly newer than what is available from the MasterPlus desktop app (which only prompts you for 4.00 as of this writing).

Feels like this 4.01 version has better click latency but I can't say for sure...


----------



## cdcd

Just gave it a quick go, click latency is identical between v3 and v4.1.


----------



## cdcd

Gamesense Meta: +1.2 ms relative to SteelSeries Ikari (STDEV=0.82 ms)


----------



## cdcd

Pulsar Xlite Wireless:
+1.3 ms relative to SteelSeries Ikari (0 ms debounce time, STDEV=0.51 ms)
+4.3 ms (4 ms debounce time, STDEV=0.54 ms)

Tested in wired mode. Scales linearly up to 30 ms debounce time with standard deviation remaining constant.


----------



## cdcd

Glorious Model D Wireless:
+0.8 ms relative to SteelSeries Ikari (0 ms debounce time, STDEV=0.58 ms)
+1.9 ms (2 ms, 0.60 ms)
+10.0 ms (10 ms, 0.62 ms)

Tested in wired mode. Scales linearly up to 16 ms debounce time with standard deviation remaining constant.


----------



## serizi

Do You know where to update to SPC Gear GEM Plus?


----------



## uaokkkkkkkk

uaokkkkkkkk said:


> On Pad(Non-Liftoff State)20ms delay between button presses
> Off Pad(Liftoff State)26ms delay between button presses.
> 
> I'm also thinking there might be a "slam click prevention" firmware function too...However, I'd have to prove it first.


Apparently this feature is not present on the Kone Pro(Wired). 

*Quick and lazy test. I bought it back in September and updated the firmware only once. No idea if anything has changed since then

Swarm Version 1.9396
Kone Pro Firmware: 1.0005


----------



## Meat

uaokkkkkkkk said:


> Apparently this feature is not present on the Kone Pro(Wired).
> 
> *Quick and lazy test. I bought it back in September and updated the firmware only once. No idea if anything has changed since then
> 
> Swarm Version 1.9396
> Kone Pro Firmware: 1.0005


Things have changed, I'm on firmware 1.18, at some point they added a "debounce time slider", default setting is 10ms. When lifted 6ms is added on top no matter the chosen "debounce time".
And yes this does seem to affect click latency negatively.


----------



## uaokkkkkkkk

Meat said:


> Things have changed, I'm on firmware 1.18, at some point they added a "debounce time slider", default setting is 10ms. When lifted 6ms is added on top no matter the chosen "debounce time".
> And yes this does seem to affect click latency negatively.


Thanks for the heads up. 

Did a little digging. 1.18 is the driver version. There were two versions of the Kone Pro(Wired) firmware. 1.0005 and 1.0006. The current firmware is 1.0006.


----------



## Meat

uaokkkkkkkk said:


> Thanks for the heads up.
> 
> Did a little digging. 1.18 is the driver version. There were two versions of the Kone Pro(Wired) firmware. 1.0005 and 1.0006. The current firmware is 1.0006.


I like how Swarm tells me conflicting things based on where I look, top of the window claims Driver is V1.9398 and Firmware 1.18, but update center claims the driver is 1.18 and the firmware is 1.0006. 
Very useful, can't wait for Neon to be worse >:I


----------



## Melan

Anyone did the click latency test for MX 518 Legendary? Rtings says it has 20ms in their review, but I feel like that's just wrong.


----------



## cdcd

Melan said:


> Anyone did the click latency test for MX 518 Legendary? Rtings says it has 20ms in their review, but I feel like that's just wrong.


Rtings get vastly different numbers for the exact same mouse (FK1-B vs FK2-B, 9 vs 14 ms), so those are best ignored. 

I'd estimate the MX518 Legendary is around the other Logitech mice, i.e. +2-4 ms.


----------



## uaokkkkkkkk

Klopfer said:


> but is that a bad thing ?
> some of their producst I recognize as HP and Roccat ...


Not a bad thing.

.......


I don't think I've ever done a brand/odm list....



> *Roccat Mice*
> 
> Kone Pure Owl-Eye *=* LaView
> Kone EMP *=* LaView
> Kone Pure Ultra *=* LaView
> Lua *=* LaView
> Kiro *=* LaView
> Kone Aimo */* Aimo Remastered *=* LiteOn
> Kain *=* Liteon
> Kova */ *Kova[+] *=* Acrox
> Pyra *=* Acrox
> Kone Pro */* Kone Pro Air *=* Primax
> Kova(2016) */* Kova Aimo *=* Primax
> Nyth *=* Primax
> Leadr *=* Primax
> Savu *=* Dexin
> Tyon *=* Dexin
> Kone 3200 */* Kone+ */* Kone XTD Laser */* Kone XTD Optical */* Kone Pure Laser */ *Kone Pure Optical *=* Sysgration
> Burst Core */* Burst Pro *=* G.Tech Technology
> Burst Pro Air(Not Yet Released) *=* ?


_Apparently I came up with this reply eight months ago and either forgot to or decided not to post it. Anyway, current me disagrees with past me._


----------



## Melan

uaokkkkkkkk said:


> I don't think I've ever done a brand/odm list....


I think we should make this list for all mice. Pretty much like with sensor/mcu list.


----------



## goodzilla

Just found this and registered so I can post. Looking through the list, there's a large latency difference between the fastest mice and some of the mainstream mice competitive gamers use.

My question is: how important are the milliseconds in real world applications? Is 5ms a lot, or is 20ms a lot? What threshold is considered good (i.e., anything under XXms is good)?

Edit: Also, why are RTINGS latency results so wildly different to these results?


----------



## Melan

People won tournaments using Zowie eVo mice with ~20ms latency. Now when you have most mice in ~5ms range, there's no reason to sweat over click latency.
Even modern sensors are kind of w/e now. Days of 3090 and 3310 are gone. People will still complain though.


----------



## goodzilla

Melan said:


> People won tournaments using Zowie eVo mice with ~20ms latency. Now when you have most mice in ~5ms range, there's no reason to sweat over click latency.
> Even modern sensors are kind of w/e now. Days of 3090 and 3310 are gone. People will still complain though.


RTINGS shows a lot of “top tier” mice in the 9-10ms range. Would you say that’s too slow or doesn’t matter compared to other mice in the 1-2ms range?


----------



## Melan

cdcd said:


> Rtings get vastly different numbers for the exact same mouse (FK1-B vs FK2-B, 9 vs 14 ms), so those are best ignored.
> 
> I'd estimate the MX518 Legendary is around the other Logitech mice, i.e. +2-4 ms.





goodzilla said:


> RTINGS shows a lot of “top tier” mice in the 9-10ms range. Would you say that’s too slow or doesn’t matter compared to other mice in the 1-2ms range?


Just ignore those numbers.

I'm not sure why you worry about click latency so much. It won't be the bottleneck on modern mice.


----------



## goodzilla

Melan said:


> Just ignore those numbers.
> 
> I'm not sure why you worry about click latency so much. It won't be the bottleneck on modern mice.


I mean... this is _literally_ a thread on click latency and in my above post I said I specifically made an account to ask some questions for clarification and get a better understanding. I don't "worry," I'm trying to learn.


----------



## badben25

Something was always off with RTINGS tests, but I haven't checked them myself. I just took a look now:









Our Mouse Control Tests: Click Latency


Even in the world of technology, where messages are sent around the world in a matter of seconds, nothing is instantaneous. With PC gaming, each piece of equipment introduces some sort of delay, called latency or lag.




www.rtings.com





Audio of click and registering the click on screen? That's a very strange (and inconsistent) method they use. They even say system latency is an obvious con. Maybe we should reach out to them and ask them to follow what we have here, assuming they want to measure the same thing.


----------



## goodzilla

badben25 said:


> Something was always off with RTINGS tests, but I haven't checked them myself. I just took a look now:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Our Mouse Control Tests: Click Latency
> 
> 
> Even in the world of technology, where messages are sent around the world in a matter of seconds, nothing is instantaneous. With PC gaming, each piece of equipment introduces some sort of delay, called latency or lag.
> 
> 
> 
> 
> www.rtings.com
> 
> 
> 
> 
> 
> Audio of click and registering the click on screen? That's a very strange (and inconsistent) method they use. They even say system latency is an obvious con. Maybe we should reach out to them and ask them to follow what we have here, assuming they want to measure the same thing.


Yeah, there would be a lot of natural system latency with that methodology... do they remove system latency from the final number?


----------



## badben25

goodzilla said:


> Yeah, there would be a lot of natural system latency with that methodology... do they remove system latency from the final number?


Probably not. How would they know the exact number to subtract from the total captured latency?


----------



## goodzilla

badben25 said:


> Probably not. How would they know the exact number to subtract from the total captured latency?


Yeah, I would have no idea. Would be too many variables to take into account and even then you’re getting just a best guesstimate. 

Question on the chart in this thread though. All the numbers work off +/- of the 0ms baseline, but what is that mouse’s actually latency? For instance I see a lot of Razer mice being +1.5ms slower from the baseline, but not sure what that means for total actual latency. Sorry if I just glossed over the number somewhere.


----------



## badben25

goodzilla said:


> Yeah, I would have no idea. Would be too many variables to take into account and even then you’re getting just a best guesstimate.
> 
> Question on the chart in this thread though. All the numbers work off +/- of the 0ms baseline, but what is that mouse’s actually latency? For instance I see a lot of Razer mice being +1.5ms slower from the baseline, but not sure what that means for total actual latency. Sorry if I just glossed over the number somewhere.


We don't have an absolute number for the baseline. I am pretty sure one of the guys contributing to the older threads said the Steelseries Ikari's (baseline mouse) absolute latency is 4-5ms, but at most this can be a good close estimate, not a 100% certain number. If we had a good way of measuring absolute latency we wouldn't be using a baseline on the spreadsheet.


----------



## goodzilla

badben25 said:


> We don't have an absolute number for the baseline. I am pretty sure one of the guys contributing to the older threads said the Steelseries Ikari's (baseline mouse) absolute latency is 4-5ms, but at most this can be a good close estimate, not a 100% certain number. If we had a good way of measuring absolute latency we wouldn't be using a baseline on the spreadsheet.


For sure, still very helpful though, thank you!


----------



## cdcd

In order to get absolute numbers, you can add something like 1.5 ms, that'll be quite close.

Genesis Krypton 750: 

+0.7 ms compared to the SteelSeries Ikari (10 ms setting, STDEV=0.72 ms),
+1.5 ms (20 ms, 0.73 ms),
+7.1 ms (100 ms, 0.73 ms).


----------



## goodzilla

cdcd said:


> In order to get absolute numbers, you can add something like 1.5 ms, that'll be quite close.


Easy enough for me. It seems like plenty of mice to choose from out there with incredibly low latency and a surprising number of “mainstream” ones that I’m surprised to see how “slow” they are.


----------



## Elrick

goodzilla said:


> It seems like plenty of mice to choose from out there with incredibly low latency and a surprising number of “mainstream” ones that I’m surprised to see how “slow” they are.


Because many mainstream mice are used in offices and warehouses everywhere, they don't need 1.0ms latency when selecting Excel or scripts and database within Access.

They just require ease and reliability of their chosen Mouse Model, above all else  .


----------



## goodzilla

Elrick said:


> Because many mainstream mice are used in offices and warehouses everywhere, they don't need 1.0ms latency when selecting Excel or scripts and database within Access.
> 
> They just require ease and reliability of their chosen Mouse Model, above all else  .


Sorry I'm talking mainstream as in used commonly by eSports professionals. I'm not talking about the Dell office mice, lol.


----------



## Elrick

goodzilla said:


> Sorry I'm talking mainstream as in used commonly by eSports professionals. I'm not talking about the Dell office mice, lol.


Yeah, suppose Logitech, Corsair and Razer might be at odds with you, because they are the most well-known mainstream manufacturers. Not all of their range of Mice have ultra low latencies, yet they still sell far more than any Dell Mice over this whole Planet and mostly used in some offices, warehousing and many homes.

Also, tonnes of various Alibaba Mice models being sold throughout China and South East Asia. Too Many to count.

Never used any Dell mouse since 1989.


----------



## cdcd

All figures relative to SteelSeries Ikari:

Mionix Avior Pro/Castor Pro/Naos Pro:
+17.0 ms (STDEV=0.67 ms) on launch firmware
+3.0 ms (STDEV=0.67 ms) on latest (1.04) firmware

Zaunkoenig M2K:
-1.3 ms (STDEV=0.45 ms) using full-speed USB
-1.9 ms (STDEV=0.47 ms) using high-speed USB

ASUS ROG Strix Impact II Moonlight White: same as ASUS ROG Strix Impact II

Glorious Model O-/D- Wireless: same as Model D/O Wireless


----------



## Melan

cdcd said:


> Mionix Avior Pro/Castor Pro/Naos Pro:
> +17.0 ms (STDEV=0.67 ms) on launch firmware
> +3.0 ms (STDEV=0.67 ms) on latest (1.04) firmware


Joys of having a flashable mcu.


----------



## Elrick

Did anyone post any click latencies for the latest:
*Roccat Kone XP RGB Gaming Mouse Black*
ROC-11-420-01 

?


----------



## cdcd

All figures relative to SteelSeries Ikari.

AQIRYS T.G.A. Wired: 
+4.4 ms (STDEV=0.92 ms) at 2 ms debounce time
+6.8 ms (STDEV=1.15 ms) at 4 ms debounce time

AQIRYS T.G.A., tested in wired mode:
+1.3 ms (STDEV=0.54 ms) at 0 or 1 ms debounce time
+4.3 ms (STDEV=0.55 ms) at 4 ms debounce time
Scales linearly up to 30 ms. Same as Pulsar Xlite Wireless, which too runs on a CompX CX52850.


----------



## cdcd

All figures relative to SteelSeries Ikari.

Xtrfy M4 Wireless:
+2.3 ms (STDEV=0.64 ms) at 2 ms debounce time
+4.3 ms (STDEV=0.59 ms) at 4 ms
+8.3 ms (STDEV=0.60 ms) at 8 ms
+12.3 ms (STDEV=0.57 ms) at 12 ms

Tested in wired mode.


----------



## cdcd

All figures relative to SteelSeries Ikari.

Fnatic BOLT:
+0.9 ms (STDEV=0.63 ms) at 1 ms debounce time
+3.9 ms (STDEV=0.64 ms) at 4 ms

Firmware version is 1.4.2. Tested in wired mode.

In order for the click latency settings to actually stick, one has to unplug and re-plug the mouse each and every time. Fnatic OP is easily one of the buggiest and most annoying pieces of software ever unleashed upon unsuspecting customers.


----------



## uaokkkkkkkk

cdcd said:


> In order for the click latency settings to actually stick, one has to unplug and re-plug the mouse each and every time.


haha oh wow


----------



## animationcanceling

do you have plans to test out the fantech xd5? I am very curious of the click latency of this mouse


----------



## Elrick

cdcd said:


> All figures relative to SteelSeries Ikari.
> 
> Fnatic BOLT:
> +0.9 ms (STDEV=0.63 ms) at 1 ms debounce time
> +3.9 ms (STDEV=0.64 ms) at 4 ms


Best staying with the ancient SS Ikari model instead. Have never bothered to waste any money on Fnatic product lines, more Gamery Junkware, for the inept.

Too much choice for better quality Mice out there already. Same goes with the Razer brand as well, they both seem to be the same outfit for making Junkware acceptable, during 2022.


----------



## animationcanceling

Fantech seems to have re-branded themselves/changed the target audience. Years ago they were focused on producing mass quantities of cheap mice but recently I noticed they've upgraded the components like the sensors, switches, cable, ect yet tried to maintain a reasonable price for their products. I am very curious on where the XD5 and XD3-V2 would be in the click latency spreadsheet.


----------



## cdcd

animationcanceling said:


> do you have plans to test out the fantech xd5? I am very curious of the click latency of this mouse


I do, but not sure when.


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms)

Ninjutso Katana:
+2.3 ms (STDEV=0.57 ms) at 1 ms debounce time (currently not functional)
+11.1 ms (STDEV=2.46 ms) at 10 ms debounce time (default)

Gamesense MVP Wired:
+2.1 ms (STDEV=0.46 ms) at 1 ms debounce time
+3.1 ms (STDEV=0.45 ms) at 12 ms debounce time

Gamesense MVP Wireless:
+2.9 ms (STDEV=0.51 ms) at 0/1 ms debounce time
+5.9 ms (STDEV=0.55 ms) at 4 ms debounce time
Scales linearly up to 30 ms. No different from any other mouse using the CX52850.


----------



## gunit2004

Seems like there have been some firmware updates to the Coolermaster MM720, MM730 and MM731.

In MasterPlus, the options for button respond time used to be greyed out for the MM730 & MM731 but now in the newest version of MasterPlus have a slider for 1ms - 6ms range.

MM720 still shows a slider range of 4ms - 32ms like it always has in the past, so not sure if anything has changed there. But it did receive a FW update practically the same time as the MM730 so perhaps something did change?

If you still have these mice on hand, it might be worth checking out the click latencies again with the newest firmwares & MasterPlus software.

Latest versions can be found here if not prompted within MasterPlus: www.coolermaster.com.cn - /DriveDownload/Firmware/CMT_Peripheral/


----------



## cdcd

gunit2004 said:


> Seems like there have been some firmware updates to the Coolermaster MM720, MM730 and MM731.
> 
> In MasterPlus, the options for button respond time used to be greyed out for the MM730 & MM731 but now in the newest version of MasterPlus have a slider for 1ms - 6ms range.
> 
> MM720 still shows a slider range of 4ms - 32ms like it always has in the past, so not sure if anything has changed there. But it did receive a FW update practically the same time as the MM730 so perhaps something did change?
> 
> If you still have these mice on hand, it might be worth checking out the click latencies again with the newest firmwares & MasterPlus software.
> 
> Latest versions can be found here if not prompted within MasterPlus: www.coolermaster.com.cn - /DriveDownload/Firmware/CMT_Peripheral/


The MM731 change is from earlier this year, and the result can be seen here: Cooler Master MM731 Review


----------



## pastuch

cdcd said:


> The MM731 change is from earlier this year, and the result can be seen here: Cooler Master MM731 Review


MM720 definitely needs a retest, it's at firmware 1.5 now. Remember to change debounce to 2ms (the minimum) because the firmware update resets everything. I find it very odd that Rtings shows stellar input lag for the MM720 and your list shows quite poor performance. Of the 14 mice I own the MM720 is my favorite.

I wish we had numbers for the Xenics Titan GE Air (Wireless MM720 clone), any chance TPU will review?


----------



## cdcd

pastuch said:


> I find it very odd that Rtings shows stellar input lag for the MM720 and your list shows quite poor performance.
> 
> I wish we had numbers for the Xenics Titan GE Air (Wireless MM720 clone), any chance TPU will review?


I don't, Rtings click latency testing is notorious for being inaccurate. The fact that the ZA13-B, ZA12-B, and ZA11-B all score differently despite sharing their internals demonstrates how off their testing is. 

Don't have a contact at Xenics, so likely not happening. 

I can take another look at the MM720 next time I'm reviewing something from Cooler Master (i.e., MM712).


----------



## pastuch

cdcd said:


> I don't, Rtings click latency testing is notorious for being inaccurate. The fact that the ZA13-B, ZA12-B, and ZA11-B all score differently despite sharing their internals demonstrates how off their testing is.
> 
> Don't have a contact at Xenics, so likely not happening.
> 
> I can take another look at the MM720 next time I'm reviewing something from Cooler Master (i.e., MM712).


Thanks very much!


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms).

Redragon M991 Enlightenment (AKA "Enlightment"): +13.5 ms (STDEV=0.45 ms, tested in wired mode)

DeepCool MG510: +14.6 ms (STDEV=1.25 ms, tested in wired mode)


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms). 

EVGA X12: 
+5.0 ms at 1000 Hz (STDEV=0.40 ms)
+4.5 ms at 8000 Hz (STDEV=0.31 ms)


----------



## Ephant

cdcd said:


> I don't, Rtings click latency testing is notorious for being inaccurate. The fact that the ZA13-B, ZA12-B, and ZA11-B all score differently despite sharing their internals demonstrates how off their testing is.


They've updated their testing bench a few days ago. 

Still not perfect but eh.









Test Bench 1.1: Changelog







www.rtings.com






> Test revamped. We now use a purpose-built USB capturing device to measure lower latencies.
> Increased sampling size to 200 points per connectivity.
> Added a video of the test running while the mouse is used in-game.
> Added a graph to see how consistent results are, as well as giving users the ability to see the individual data values.


GPX video, for example: https://i.rtings.com/assets/product...Mp4_Avc_16x9_1920x1080p_30Hz_8.5Mbps_qvbr.mp4


----------



## badben25

Ephant said:


> They've updated their testing bench a few days ago.
> 
> Still not perfect but eh.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Test Bench 1.1: Changelog
> 
> 
> 
> 
> 
> 
> 
> www.rtings.com
> 
> 
> 
> 
> 
> 
> GPX video, for example: https://i.rtings.com/assets/product...Mp4_Avc_16x9_1920x1080p_30Hz_8.5Mbps_qvbr.mp4


I guess it depends on what they're trying to capture and show. Their updated method is more than just click latency, it's more like system/total latency, or input lag, or whatever the right term would be. It's a button-to-screen, action-to-response kind of measurement that they have here. That still involves more than just the mouse, so it's still hard to agree with (for me atleast).


----------



## cdcd

Results at least are much closer to reality now, though I don't understand why they're testing in-game, and STDEV isn't cited, either.


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms).

Fantech XD3 V2/XD5: +2.9 ms (0/1 ms debounce time, wired)

For the record, I didn't actually test those, but they're CX52850, so there is no way for click latency to be different.


----------



## cdcd

Ingore the post above, had to do it properly after all.

Fantech Helios XD3 V2:
+2.7 ms (STDEV=0.48 ms, 0/1 ms debounce time, wired)

Fantech Helios Go XD5:
+4.7 ms (STDEV=0.48 ms, 0/1 ms debounce time, wired)
+6.7 ms (STDEV=0.47 ms, 4 ms debounce time, wired)
+14.7 ms (STDEV=0.52 ms, 12 ms debounce time, wired)

For whatever reason, both have 0.2 ms lower latency than other CX52850 mice have, and the XD5 has a flat 1 ms higher latency than the XD3 V2 across the board. In addition to that, 0/1 ms setting is broken on the XD5 and behaves the same as 2 ms.


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms). 

HyperX Pulsefire Haste Wireless:
+7.9 ms (STDEV=0.58 ms, wired)


----------



## uaokkkkkkkk

cdcd said:


> Ingore the post above, had to do it properly after all.


Yeah, I wouldn't expect consistency. Even if it's the same from the same brand/same odm. Dexin stuff over the years is a great example of that.


----------



## yinx

I'm eager to see the click latency for the updated MM720.


----------



## cdcd

All figures relative to Zaunkoenig M2K (which equals [Ikari]+1.4 ms). 

SteelSeries Aerox 5: +7.2 ms (STDEV=0.56 ms)
SteelSeries Aerox 5 Wireless: +6.8 ms (STDEV=0.86 ms, wired)
SteelSeries Aerox 9 Wireless: +6.9 ms (STDEV=0.90 ms, wired)

I'm sure the debounce value is identical between them, Aerox 5 being slower is due to Holtek and Aerox 5 and 9 Wireless are within margin of error.


----------



## cdcd

cdcd said:


> Fantech Helios Go XD5:
> +4.7 ms (STDEV=0.48 ms, 0/1 ms debounce time, wired)
> +6.7 ms (STDEV=0.47 ms, 4 ms debounce time, wired)
> +14.7 ms (STDEV=0.52 ms, 12 ms debounce time, wired)
> 
> For whatever reason, both have 0.2 ms lower latency than other CX52850 mice have, and the XD5 has a flat 1 ms higher latency than the XD3 V2 across the board. In addition to that, 0/1 ms setting is broken on the XD5 and behaves the same as 2 ms.


New firmware brings the 0/1 setting down to 3.7 ms. Everything else unchanged.

Pulsar Xlite V2 Mini Wireless is the same as Xlite Wireless V2/V1.


----------



## badben25

cdcd said:


> New firmware brings the 0/1 setting down to 3.7 ms. Everything else unchanged.
> 
> Pulsar Xlite V2 Mini Wireless is the same as Xlite Wireless V2/V1.


is there a firmware version number?


----------



## cdcd

badben25 said:


> is there a firmware version number?


None I'm aware of at least.


----------



## p1r4nh4

Has anyone tested the Delux M800 PRO?


----------



## cdcd

p1r4nh4 said:


> Has anyone tested the Delux M800 PRO?


Provided it is still running on a Sino Wealth SH68F1000, click latency will be in the 15 ms range.


----------

