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!
.
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.