Blur Busters Forums

I can see that there is maybe no sense in arguing with you and maybe it's just not worth the hassle.

0. This tells all:

I won't take the time to address your points in detail, because it doesn't seem your analysis is good enough to be worthy of that.

Regrettably you aren't mention why do you think that I'm wrong or why do you think that my analysis isn't correct.

1. Yes I know that you are only measuring the latency between packages with different keypresses, which indicates the scan rate and not the latency of how long it perform a key registration at all. In theory you can measure inconsistency with it, but not from the device and only from your system. If you really want to measure the potential inconsistency of a keyboard you would need to stick a LED on top of the sensor of the Wooting and switch it with a dedicated controller within an constant time.

2.

We know they're lying because there's a minimum latency of 0.5 ms caused by the USB polling...

This statement is false, the minimun delay of a 1 kHz polling rate is around (but not exactly at) 0 ms, there the maximun delay is at 1 ms, because the real time isn't discrete. This means that the average delay of a 1 kHz polling rate alone is around 0.5 ms (this is called Median in statistics). But the polling rate has nothing to do with the scan rate of a USB device. Wooting claim that their scan rate is around (just a bit faster than) 1 kHz on Tachyon mode, so the values are the same. Because I dont think that the scan rate is joint with the polling rate, the minimum delay from both is at (nearly) 0 ms, the maximum is at 2 ms and so the average at around 1 ms. But this is most probably not the total delay how long it takes to register a new input, because I bet there is an unknown nearly constant delay in addition which must be added to it.
But regardless of the scan rate, because the polling rate is at 1 kHz and this is handled by the USB controller chip from the hardware itself, there is no way that the time between two packages is not within nearly full milliseconds. So it's impossible to get a time differences between two packages of 0.5 ms or 1.5 ms and so on, no way!

3. As written before your linked program don't measures the keyboard-to-computer latency, it only measure the delay how long the PC takes to handle keypresses within your program, one key after another in a serial manner. So if multiple keys are sent in a single package, your program will handle them one after the other and not altogether. Because of that you getting numbers which aren't correspond with the polling rate.

4. Here is an old post (on an old beta firmware) there someone checked the scan rate of the Wooting with an oscilloscope. But I wouldn't call it a good test either. Unlucky, scientific tests are very rarely. https://twitter.com/sunjun_kim/status/9 ... 7173860352
You can read about Wooting perspective in the topic "How Wooting measures input latency" under https://blog.wooting.nl/what-influences-keyboard-speed/

5. Your program adds unfortunately so much delays that you can't measure inconsistency with it. How much depends on the system and hardware. I repeated my little test with my mouse, so you can compare the results on the screenshot. You can clearly see that the USB data is sent and received from my PC around every millisecond (with only a few and small exceptions), there your program even shows values up to 13 milliseconds. Remember these are mouse inputs, but your program must handle them the same way as keyboard inputs. My Logitech G903 is set to a 1 kHz polling rate as you can see in Wireshark. But like any other modern gaming mouse, the scan rate isn't constant on slow movements, meaning only on fast movements, packages are send out really every millisecond. You can see this behaviour very good on the last packages there the movement from me was ended and so the speed of the mouse was slow, so that the packages were sent out at a lower rate. The last value was just a mouse click, a few seconds after the movement was done.

6. As I wrote there are still some bugs and you are right that they are prioritize other things at the moment. Wooting is still a very small company with only 4 people in total.


@Edit:
If you still want to stick with your program I would suggest to really decouple the output from the measuring completely.

• Remove the measuring from the loop to a separate function which is called later on, after loop is ended.
  Let the process still be active to prevent an untimely undesired exit.

Then you can't see the results at realtime anymore, but at least the delay from the output didn't influence the measurements anymore. The delay of the serialize handling will be still present.

Example: https://github.com/ad8e/input-polling-test/pull/1