Are Wireless Mice ACTUALLY Faster??

[graveyj2000]

I would be interested in seeing this test with a more consistent strike point on the mouse.  With the hammer hitting the mouse at different points, it could have easily affected the amount of time it took the sensor to register the movement of the mouse.

[Stig Vildmark]

3 hours ago, adam10603 said:

A tick rate of 64 doesn't mean that everything is updated only 64 times a second. Well technically it does, but there's also interpolation which makes this a non-issue, and also mouse inputs and camera rotation (aim) is always done per-frame locally, not per-tick. So what they were testing, which is the way a higher refresh rate affects one's ability to track and shoot a target, is not affected by a lower tick rate. If it was, there would be no point in playing on higher than 60Hz and 60fps whenever a server is 64-tick, but there clearly is.

Interpolation is a guessing game where you take two frames as a reference. Let's call those ticks for clarity and we use those ticks to calculate and make assumptions.

 

The frames of reference was 0 movement in Linus test. Nothing have happened during the previous two ticks. The game has no reason to assume that he will move until the next tick. The next frame of reference arrives as a tick, the hammer have hit the mouse. 15.625ms have passed since the last tick. All the engine can see is that the mouse has moved. The engine decided to update the positions and we have no way of going back in time to redraw the screen. We can't get rid of this delay.

 

The game now have a tick where Linus is moving his mouse, the game may assume that Linus will continue to move his mouse until the next frame of reference. The game decides interpolate his movements and act accordingly. 15.625ms ms later and the next frame of reference arrives, the engine was correct! Linus is still moving his mouse and we may assume that he will continue to do so until we get a tick that says no.

 

Most professional players have given up on Valve and play exclusively on ESEA servers. They will tell you it's a night and day difference and that everything is a lot smoother. That is probably because ESEA servers have twice the tick-rate, 128 compared to 64.

 

Counter-strike players have since 1999 talked about rates and shared their configurations. Why do they do this? They want to take advantage of the extra positional data that you get from a 128 tick server. A frame-rate over 64 on a 64 tick server will only reduce screen tearing and the overall latency. You can't get more positional data then the server is sending you. The game can only assume that people will keep doing what they do and act accordingly, we call this interpolation.

[Mira Yurizaki]

There is the fundamental principle that the speed of light in air is much faster than the speed of light through copper wiring. But I'm pretty sure this is so beyond human perception that it doesn't matter.

[mariushm]

23 hours ago, Mira Yurizaki said:

There is the fundamental principle that the speed of light in air is much faster than the speed of light through copper wiring. But I'm pretty sure this is so beyond human perception that it doesn't matter.

The mouse isn't using LIGHT through the air to talk to the receiver plugged in a USB port.

Also, there's no such thing as speed of light through copper wiring. There's speed of electricity through wires.

The speed of light is 299 792 458 meters per second... and you get almost that through fibers. The speed of electricity through copper is close enough, around 280 000 000 meters per second (it depends on quality of copper wire and the thickness, for example with AWG12 wire you have 285,102,627 meters per second, BUT mice use much thinner wires, like AWG26 or AWG24)... it doesn't matter anyway because over 2-3 meters of cable it's a difference of nanoseconds.

 

It uses a radio transmitter to send data packets to the radio receiver (the usb dongle plugged in the back of the PC) - the radio receiver decodes the packets and converts them to the packets a regular wired mouse would send and sends them through the USB port.

 

The packet of data send over the air travels SLOWER compared to speed through wire, or through a fiber (optical) and probably is also slower than infrared or some "outside normal viewing range" transmission (but this is not used because it's kinda directional, mouse must be pointed to a receiver/sensor and that kind of defeats the point, a CS player waving the mouse on desk would get packet loss as mouse loses contact with sensor)

 

Anyway, at the end of the day with a distance that's at most a few meters long, the difference of time between methods of transmitting data is super small, much smaller than the amount of time it takes to decode packet of data, convert it to usb and then push actual data into USB (again, USB polls once every 1ms at best if the polling rate is set to 1000 Hz), and it takes way less than 1ms for data to be pushed from actual mouse to USB controller.

 

[Mira Yurizaki]

11 minutes ago, mariushm said:

The mouse isn't using LIGHT through the air to talk to the receiver plugged in a USB port.

It's using RF waves which travel at the speed of light, last I checked

 

Quote

Also, there's no such thing as speed of light through copper wiring. There's speed of electricity through wires.

If you want to be pedantic, okay.

 

Quote

It uses a radio transmitter to send data packets to the radio receiver (the usb dongle plugged in the back of the PC) - the radio receiver decodes the packets and converts them to the packets a regular wired mouse would send and sends them through the USB port.

Uh, thanks for telling me what I already know?

 

Quote

The packet of data send over the air travels SLOWER compared to speed through wire, or through a fiber (optical) and probably is also slower than infrared or some "outside normal viewing range" transmission (but this is not used because it's kinda directional, mouse must be pointed to a receiver/sensor and that kind of defeats the point, a CS player waving the mouse on desk would get packet loss as mouse loses contact with sensor)

Pretty sure the whole point of using omnidirectional RF as the transmission medium is so that the mouse doesn't have to point at anything.

 

Also don't really see how the transmission medium of using RF is slower than using electricity or fiber considering the velocity factor of the latter tends to make the speed a lot slower than RF in air, which travels close enough to the speed of light in a vacuum.

 

In fact, day traders use open-air lasers or microwave transceivers because it's faster than using wires or fiber: https://www.reuters.com/article/us-highfrequency-microwave/lasers-microwave-deployed-in-high-speed-trading-arms-race-idUSBRE9400L920130501

Edited July 9, 2019 by Mira Yurizaki

[mariushm]

3 minutes ago, Mira Yurizaki said:

Also don't really see how the transmission medium of using RF is slower than using electricity or fiber considering the velocity factor of the latter tends to make the speed a lot slower than RF in air, which travels close enough to the speed of light in a vacuum. 

You have a processor in your mouse that converts the data packet that would normally through wires in a wireless data signal, along with error correction information and other crap. It takes some amount of time for this processor to convert the data packet - extremely small amount of time but nevertheless it's some amount of time.

Data then travels through the air in lots of directions, and it may not be a signal directly between transmitter and receiver, for example the dongle may be in the back of a PC and the receiver in the dongle may receive the radio signal as a reflection from the wall instead of direct air transmission.

The dongle has a processor which receives the radio signal and applies error correction and other stuff to recover the data packet - keep in mind it's a common radio frequency like 2.4 Ghz, where there's wireless routers and other devices so the received in the dongle can get interference and has to be smart enough to throw away what's not needed.

Also think for example having 4-8 such wireless mice in an office, the receives would receive data from all mice but throw away the data from mice it's not paired with.. but the data still has to be processed.

So that's another processing time, the amount of time it takes to convert from radio signal back into USB data packet...

wireless mice .... process sensor data -> create data packet -> time required to convert data to radio signal + time to travel through air + time to process radio signal and convert to data packet + wait time until next usb polling

wires mice ... process sensor data -> create data packet -> wait for usb polling -> time to transfer bits through copper

 

another thing that's worth keeping in mind and i mentioned it in previous threads is the wake up penalty... you have battery powered device, so it's only natural if the sensor doesn't report change for some time, the mouse will shut down the transmitter to save battery power. That's probably a few tens or hundreds of microseconds of wake up time / initialization for the radio transmitter in the processor but mouse probably only goes to sleep after 15s-30s-1m of no movement, which is kinda rare while in games so it won't affect people that much (if at all)

 

It's most likely microseconds or nanoseconds worth of difference but a wires mouse will pretty much always send the data faster to a usb controller. Not willing to bet on it, not that confident, but I just don't see how multiple conversions + air travel would at any point be faster than wired connection.

 

[OSKrueger]

Just some thoughts on the testing latency / responsiveness of computer mice

 

In the beginning and at the end of the video Linus mentions, that they have no way of intercepting the signals along the USB cable or the wireless connection. I think that this is not even necessary.

You are using a transceiver(dongle)-air-transceiver(mouse) setup to replace a cable and want to see which performs better. It does not matter how the signals get from one end to the other, just how fast they reach your USB controller.

An interesting early comment also touching this point has already been made.

 

On 7/4/2019 at 8:51 PM, mariushm said:

Unless they come up with an internal pci-e card, you're still gonna be limited by the USB polling rate, which is 1ms at best (default is 125 Hz or an update every 8 ms)

 

So a good way to approach this problem would be to use a USB packet sniffer (If you like GUIs, 'wireshark' is an option.), that just listens to the raw USB signals reaching the controller. This will also prevent any bias caused by (proprietary) device drivers converting the raw signals into actual onscreen movement and software (e.g. games) interpreting input signals.

Also error prone is comparing the absolute measurements. A relative measurement could improve this ("Which mouse responded faster?").

 

The test setup I propose requires:

• 2+ USB mice (cable, wireless/Bluetooth dongle, whatever)
• a computer with 3+ free USB ports (you want to connect a keyboard, too)
• a GNU/Linux installation of your choice (with the usual tools: bash, lsusb, grep, sed, awk, bc, cat, cut, vim... yes, this is going to be hard core command line. I told you, you’ll need a keyboard =P )
• a shell script (provided in this post, UsbCaptureRace.sh)

It does not require

• a high-speed camera (sorry, Slow Mo Guys)
• a hammer (sorry, Edzel)

Note: I’ve tested this with a “stock” kernel. It might be better to use a “low-latency” or “real-time” kernel (as is used for audio recording).

 

Preparations (after booting into GNU/Linux)

Mount debugfs (very possible it is already mounted)

$>sudo mount -t debugfs none_debugs /sys/kernel/debug

Check if the “usbmon” modul is loaded.

$> lsmod | grep usbmon

If it’s not loaded (no reply on the prompt), load the module.

$> sudo modprobe usbmon

Do some testing... The path for the next command may vary depending on your GNU/Linux distribution.

$> sudo cat /sys/kernel/debug/usb/usbmon/0u

Move your mouse/mice, type on the keyboard and take a deep look into the Matrix.

CTRL-C stops the Matrix.

 

Sample output:

ffff9b0112b3e9c0 3444903484 C Ii:1:005:1 0:1 8 = 01000000 02000000
ffff9b0112b3e9c0 3444903518 S Ii:1:005:1 -115:1 8 <
ffff9b0112b3e9c0 3444904481 C Ii:1:005:1 0:1 8 = 0100ffff 00000000
ffff9b0112b3e9c0 3444904507 S Ii:1:005:1 -115:1 8 <
ffff9b0112b3e9c0 3444908484 C Ii:1:005:1 0:1 8 = 01000000 01000000
ffff9b0112b3e9c0 3444908513 S Ii:1:005:1 -115:1 8 <
ffff9b0112b3e9c0 3444913491 C Ii:1:005:1 0:1 8 = 01000000 01000000
ffff9b0112b3e9c0 3444913532 S Ii:1:005:1 -115:1 8 <
ffff9b0112b3e9c0 3444947487 C Ii:1:005:1 0:1 8 = 01000000 01000000
ffff9b0112b3e9c0 3444947527 S Ii:1:005:1 -115:1 8 <
ffff9b0112b3e9c0 3445006489 C Ii:1:005:1 0:1 8 = 01000000 01000000
ffff9b0112b3e9c0 3445006529 S Ii:1:005:1 -115:1 8 <

Notable columns:

• The 2nd column is a timestamp in microseconds.
• The 3rd Column are event types: callbacks or submissions. Callbacks are the packets send from the device(mouse) to the host (at least if I can trust my interpretation of wireshark logs)
• The 4th column contains the device address Ii:<bus>:<device>:<endpoint>.
  The <bus> and <device> of a USB device can be displayed with

  $> lsusb 

  The <endpoint> is usually 1 for a mouse, but can differ if you have a touchpad on a multimedia keyboard or a ‘gameboard’ (like a Logitech G13), which can emulate a mouse. (Would be interesting to see how an Xbox controller behaves.)
  Rebooting, unplugging and replugging a device can change its address.
• The last two columns on lines with a callback event and a mouse address are horizontal and vertical mouse movement.
  (Note for future testing: How fast is a change in direction detected?)

Download the UsbCaptureRace.sh and move it to a directory of your choice (e.g. $HOME/usbcapture/), enter that directory and make the script executable.

$> chmod u+x UsbCaptureRace.sh

Read the licence and author’s notes ;-).

$> head -n 13 UsbCaptureRace.sh

Have a look at the script in general and edit as needed. I tried to comment as much as possible.

$> vi UsbCaptureRace.sh

Okay that might be a bit too masochistic, at least use ‘vim’.

Connect all your remaining mice to the computer.

The preparations are done.

Run the script with elevated privileges (the system’s debug path is not accessible to "normal" users)

$> sudo ./UsbCaptureRace.sh

What the script does:

• Find the mice connected to the computer (incl. bus number, device number, etc.)
• Let’s you select your reference mouse. All time calculations are done relative to this mouse.
• It waits for you to press the "anykey", for when you’re done with your physical test setup and all is quiet.
  
  Initially I wanted to push all of my two mice upward simultaneously with a ruler and ended up just putting the mice close together and banging my fist on the desktop. (Come to think of it… a hammer would have been useful...)
   
• Then it records from /sys/kernel/debug/usb/usbmon/0u (default path, change in script) for 3 seconds (default value, change in script).
  
  Move your mice as simultaneously as possible with in this time. You do not have to move them for the whole 3 seconds.
  Only the first movement will be evaluated and must occur with in these 3 seconds.
   
• Find the timestamp of the first packet received from the reference mouse.
• Find the timestamps of the first packets received from the remaining mice.
• Calculate the time differences.
• Print the result.

Mice with a negative time difference "reacted faster" than the reference mouse.

Mice with a positive time difference "reacted slower" than the reference mouse.

 

Rinse and repeat for more data points and better averages. (Not implemented, you have to take notes or modify the script)

 

Personal Conclusion

My Compact Optical Mouse, Model 1016 by Microsoft Corp. reacts 16ms to 30ms slower than my Roccat Tyon (black edition).

 

Cheers!

PS:

tested with

GNU/Linux kernel 5.1.15

usbutils 010-1
bc 1.07.1
GNU coreutils 8.31
bash 5.0.7
sed 4.7
grep 3.3

didimissanything 1.0

 

[SnipeKing17]

Hey guys.. I wish I get answer to this question.

 

In this video: 

 

You guys had a 540p@480hz monitor. Why didn't you use that instead?

 

It'd have surely helped with the accuracy of your tests. 

Also.. You could've made an estimation about the poling rate(which you left) from testing the poling rates 500hz and below; about poling rates as a whole.

 

I wish you'll do the input lag test later sometime.. But with  this or a even faster monitor(That video was from 2017!)

 

Or talk to some custom board makers (like the one in the above video) to get yourself one.

 

I need answers . Thanks for reading!