Mouse 41 Rate 6 Network

[Yaima President]

JeffAtwood has some great points on this article Coding Horror:Mouse DPI and USB Polling Rate and has included a link to a tool to check your mouse polling Direct input mouse rate tool that would be a help to your information quest on the m705.

I found a few forum/howto explaining how to change "mousepoll" of USBHID.but I still get 0 in /sys/module/usbhid/parameters/mousepoll and still 22Hz.Moreover, I have a bluetooth mouse....not sure if USBHID can influence here?

by the way, If I do "rmmod usbhid", I immediatly loose my USB keyboard, USB mouse, but the laptop keyboard, touchpad and my laggy bluetooth mouse still works (and still laggy)...I guess it means the mouse is not managed by usbhid....

I had a problem connecting my bluetooth mouse to the ubuntu mate latest version running on raspberry pi4. I tried almost all the tips and tricks in the internet to change the poll rate with little success and reallised that I just had to edit aliases.conf file in the modprobe.d folder

I'm looking for an authoritative answer, backed by data. A friend asked me the other day whether he would benefit from plugging his mouse into a USB 3.0 port instead of an available 2.0 port. I flippantly replied that it would make no difference at all. Certainly I'm not the only one to think that. See answers on:

So you are entirely correct: plugging a mouse into a USB3 connector confers no benefit whatever. If a mouse responds slowly, it is because something else is hogging the CPU to the detriment of the mouse driver.

USB 3.0 controllers support backward compatibility by performing enumeration in a way that is compatible with USB 1.x and 2.0 devices, and exposing a logical EHCI controller as part of the register map.

The mouse will identify itself as a USB full-speed device regardless of the port and controller it is connected to. This will cause the mouse to appear logically connected to the EHCI controller (sometimes even OHCI/UHCI).

Having a logical EHCI controller does not mean that the device is attached to a USB 2.0 circuit. The connection between system and USB 3.0 host controller will be higher speed, probably multi-lane PCIe. It's also much less likely to go through a PCIe-PCI bridge, which causes buffering and slight additional latency.

Besides the host-side connection, the transistors driving the USB pins will also have a higher switching rate, and instead of passive components for noise filtering, the bus will use digital switches in the filter network, to allow it to be removed and not slow down USB SuperSpeed devices. (This was probably a bigger deal for the jump between USB 1.x and 2.0)

The passive filter components present in the mouse should dominate. Still, rise and fall times could be a few nanoseconds faster.

In summary, a USB 3.0 host controller with a full-speed or high-speed USB 2.0 device is not the same circuit as the same device attached to a USB 2.0 host controller, and the timing will not be identical.

However, any latency improvement will be at most a couple microseconds. I suppose it's possible that with some probability this would cause the mouse input to be relayed to the server in time to be processed one frame earlier; the probability is extremely low (well under 1%), and anyone claiming it affects their game performance is confused.

In particular, the effects of network congestion are several orders of magnitude larger. Anyone trying to give themselves every technical advantage in the competition should focus their efforts there. QoS markings probably do determine the outcome of games at the highest levels of play. Choice of service provider almost certainly does.

We need to take a look at the mouse's polling rate and from that we can have a better idea of how much data is being transmitted.If a mouse has a 100hz polling rate, it is sending data to the computer 100 times a second.

A standard mouse will send a 3 byte packet containing info on X/Y position information as well as button information. Considering that 3 bytes are transferred each cycle of the polling rate, you could have 300bps being transferred.

USB 3.0 and USB 2.0 controllers on modern motherboards are implemented differently, primarily due to the data throughput USB 3.0 requires. In some chipsets you'd find the USB 2.0 appear as essentially PCI device on a supercommunications hub that also handles all the other slow devices, like hard drives, audio, ethernet, parallel and serial ports, etc. This existed in the southbridge chip, which was then connected to the northbridge through a media layer similar to a PCIexpress bus. The northbridge handled the high speed stuff, such as memory, graphics, PCIexpress etc.

USB 3.0 was introduced at the same time that the northbridge/southbridge gave way to the PCH(Platform Controller Hub). Most of the northbridge duties were absorbed into the CPU itself - memory, PCIexpress, etc, while the remaining northbridge duties and southbridge duties went to the PCH. The PCH is essentially running off a PCI express slot.

The paths, however, are still very different. Even though USB 3.0 and USB 2.0 are integrated into the PCH, the USB 2.0 is still implemented as though it's a slow PCI controller device. There's no reason for Intel to redesign the silicon of a proven part, so it's integrated into the PCH the same way it was integrated into the southbridge, with all the attendant bottlenecks and additional latency that it had before.

However, the USB 3.0 is much closer to the CPU. While this is meant primarily to account for the increased throughput, it also affects latency - there are fewer transactions involved in getting a USB 3.0 transaction to memory, or to the CPU, and the interrupts may be triggered more quickly.

However the difference between USB 2.0 latency and USB 3.0 latency would be measured in nanoseconds. Certainly not noticeable by even the best twitch gamers today. It exists, but it's practically useless.

While I do not believe that on most conventional mouse models you would get any advantage whatsoever, you are likely trying to determine that even if there was any difference, it would have to be noticable by the user?

In that case, it is simple enough to test the case in a mouse-performance demanding game or application, by plugging it into both ports. I have tried this myself, and found no difference that I could notice, which was sufficient for me (test results beat theory for personal use scenarios, as in some cases even a psychological difference could help you perform better - in which case it would still be better for you).

Communication latency also should not be a factor, a properly built (any generation) USB device should respond far faster than human reflex speed, so you should not experience any lag due the technology of the port.

Of course there are many other factor if you experience mouse lag: system may be busy, driver may be not working as intended, software can be stuck waiting for other events (most of times, it is a network-related event problem), mouse itself can be broke, and finally the port hardware may be faulty - so trying another mouse/port is a good start.

I don't have the best internet, but i don't believe it is causing the problem (i've attached my speedtest results). With my apartment setup the living room is the only room that has a working coaxial connection, so i can't connect my PC and Mac Mini directly to the router, since they are setup in my bedroom. I did read this article here that there is a specific issue on Mac that my be causing the issue, but i have no idea if it's been fixed and there is no date on the article. Is there anything i can do to fix this?

Also, Synergy does not use the internet to work - only the local LAN network (ie. from your computer to the router). As long as the devices are not too far from the router the connection will be fast/stable enough.

I'm also experiencing the same issue after the update to 1.14.3 from 1.14.1: My computers are both connected to the same wifi and is about 3 meters away from the modem/router. The main computer with the keyboard and mouse is a PC and is connecting to a M1 Mac, I've tried changing the ports but that didn't help unfortunately.

I forgot to mention that i am also having issues where both the client and server computers freeze for up to 10 seconds. This happens randomly on the client computer with normal use, but it also triggers after being idle for awhile and then moving the cursor from client computer to server computer and vice versa.

I first ran this command on the client (m1 mac mini) "sudo ifconfig awdl0 down" (undo the command with "sudo ifconfig awdl0 up") this is basically the wifriedx solution. I honestly don't know if this did anything or not.

After that things felt a whole lot smoother and i haven't noticed any freezing, but lag was still present.

So while still using a wifi connection, i decided to switch to a wired connection between the Windows PC and Mac Mini. Follow this thread here:

Clipboard sharing seems to only work with urls, i cannot copy pictures or any other type of file, drag and drop does not work. When pasting a url from server browser into client browser everything freezes for about 10 seconds, i have not found a solution to this yet.

I'm also experiencing some serious lag on the client side. I am running windows 10 on the server side and connected to an MacbookPro M1 on the client side. Just started happening this morning. Tried to update to the newest version as well as changing the port and it's still happening. Please help

I have a Windows 11 server and a MacbookPro Intel client. Previous Synergy versions worked well, but version 1.14.4 lags quite a lot. I have 300+Mb upload and download on wireless so I don't believe wireless is the issue. However, I have a network adapter ordered and will try wired when I can.

I have connected a wired network adapter to my Mac, bringing the upload/downloads speeds up to 900+Mb. The lag issues have disappeared so far. I still don't understand why I wireless worked well for quite a long time and started failing right after I updated to v1.14. However, with wired ethernet, the software works well again.

3a8082e126