High polling rate USB device causes issue and information loss

Submitted by Zombiefruit on #1

Sorry for the vague title, I'll try to summarize as best I can. 

TL;DR: my sim racing wheel (polling at 1000Hz) coupled with a racing game sending data at any rate over 133Hz, causes problems (game lockup - potentially game specific - and missing data - non game-specific). This occurs with both wired connection (5Gbps) and wireless (~500Mbps). I believe that I've ruled out all possibilities save for it being an incompatiblity or bug with VirtualHere. 

Long version. I recently upgraded to a new sim wheel (Simagic Alpha U), and connected it to my client PC via VirtualHere (as I did with my previous wheel, the T300RS). Unfortuantely, while trying to play Assetto Corsa Competizione at a feedback rate higher than 133Hz (200Hz, or 400Hz), the game starts to have problems. At 200Hz a warning of "CPU usage >99%" is shown and the game stutters (in reality, CPU usage is quite reasonable, between 40% and 50%, in at most one core). At 400Hz, the game crashes as soon as I start to drive (and presumably, FFB values begin to propagate). Before upgrading to this new wheel the 400Hz setting worked fine, which led me to believe that the issue was with the new wheel, but when I connect the wheel directly to the PC (via USB), everything works fine at 400Hz - no warning messages, no stutters, no crashing. And subjectively, I was shocked at the high frequency information suddenly provided by the wheel (even at 133Hz) - it was like having a new wheel, and I realized that something about this connection had been stripping away high frequency information. 

What's strange to me is that mice connected via VirtualHere work fine, and gaming mice poll at very high rates, but perhaps the data transferred is smaller? I don't have enough technical know-how to debug any more than this, all I know is that VirtualHere does not fully support this setup. 

I'm happy to provide any additional information. Does VirtualHere even support polling rates this high? 1ms updates seems pretty wild to do over the network, although I never faced any issues with my other peripherals.

Thanks!

 

Submitted by Michael on Wed, 2024/08/14 - 09:38

#2

VirtualHere never drops packets and never corrupts packets. 

My guess:

What is probably happening is that the driver for the wheel is requesting 1000 updates/sec and puts them in a queue to be taken off and put on the usb bus for the wheel to respond. VirtualHere takes these off the queue as fast as possible.

 Because your network latency is high (even 1ms would be high at 1000Hz) it simply cannot keep up. So the queue overflows and the wheel software crashes.

So its physically impossible with your current setup to accept that high a polling rate.

Take a look in the virtualhere client, right click USB Servers->About->Statistics and see the latency. Even a small number of spkies > 1ms will probably cause problems.

 

Submitted by N4n0 on Sun, 2026/01/25 - 15:14

#3

Hello, sorry to revive an old post, but did you ever solve this problem?  I have the exact same issue with ACC, except with a Moza wheelbase.

Submitted by Zombiefruit on Sun, 2026/01/25 - 19:08

#4

Sory for not responding Michael, thanks for the helpful response! And no, unfortunately I was never able to solve it and resorted to running a very long USB cable between my main PC and simulator. Sorry I can't be of any help :/ 

Submitted by N4n0 on Mon, 2026/01/26 - 06:15

#5

Thanks for the reply.  

Yeah, from my tinkering I've come to the conclusion that we hit a ceiling in the technology.  A long USB cable is impractical in my case, but I'm looking into using USB extenders instead.  These run USB commands through dedicated Cat5 or Cat6 cables for long distance low latency runs.  They are a little on the expensive side, but much much cheaper than buying another entire PC just for the sim rig. For now, I have ACC set to 100hz, and it's working "good enough."