Hi, I am using Intel Realsense T265 camera on Jetson TX2 via USB. There was also a wireless USB dongle for mouse and keyboard. TX2 first is connected to an USB hub, and T265 and mouse were plugged into the hub. When I ran T265 I found the mouse and keyboard response is very slow, and sometimes I could totally lost the muse. If I used wired mouse or keyboard, they worked fine.
How can I fix the mouse slow response issue?
Hi,
Is the wireless USB dongle enumerated as high speed or superspeed? We have seen bandwidth issue in USB2 + USB3 webcams. Please check
connected more than two usb cameras problem on deepstream-app (Jetson Nano Dev Kit) - #12 by DaneLLL
If the dongle is in USB2 and Realsense is in USB3, it can be a similar case.
And you may connect micro-B port on TX2 to micro-B to type-A adapter, and connect to the wireless dongle. Realsense cameras need much bandwidth. It is better to use another port for the dongle.
Hi @DaneLLL DaneLLL:
Thank you for replying. I am not sure about the USB being high/super speed. It is just a normal wireless mouse dongle. (It is not the Logitech “universal” receiver).
My USB hub is USB3 and TX2 USB is 3.0, so everything should be USB 3.
I tried plug mouse to USB-b, but it was still slow.
I do not think this is the USB port issue, since if I used a wired mouse/keyboard through USB, they worked normally. I think the issue had to been that the mouse is wireless.
I remember read a post somewhere about reconfigure TX2 wireless band/frequency or something to solve this kind of issue, but forgot the details…
Run command “lsusb -t”. The end of each line indicates 5000M if it is USB3.1 gen. 1, 10000M if USB3.1 gen. 2, 480M if USB2, 12M for USB1.1, and 1.5M for USB1.0. The root_hub entry is the actual controller.
Note that in both “lsusb -t” and plain “lsusb” that a “Bus” and “Device” are given. You can identify a relevant device with plain “lsusb”, and then use the “Bus” and “Device” combination in “lsusb -t” to find its mode.
Hardware IRQs are probably all handled in CPU0 (other than timers). This includes USB. The Realsense cameras probably run in “isochronous” mode, though they could run constantly in bulk mode. Isochronous mode is a real time mode where interrupts are running at a given interval 100% of the time like a clock. Bulk mode would be a lot of interrupts, a brief pause, and then a lot of interrupts, so on. I suspect there just are not enough interrupts available for the mouse and that the camera is reserving it all (I think the Realsense camera probably says it should be used by itself on a port). A mouse using only USB1.0 (1.5M) or USB1.1 (12M) would less likely to suffer from a lack of interrupt availability (“IRQ starvation”) than a USB2 (480M) device.
If two different USB controllers run for two different USB devices, then even if the total IRQ requirement is high for one controller due to an isochronous mode, then the timing for the other controller with the mouse isn’t particularly critical due to buffering, but if the mouse and the isochronous load (near the max load for that USB controller) are using the same controller, then the mouse will only be able to be serviced and buffer between the higher priority isochronous device’s frames. Any mouse interrupt at a bad time, when on the same USB controller as the isochronous mode device, would be summarily dropped. I suspect (in this long winded explanation which is basically the same thing @DaneLLL is getting at, that you’re seeing bad behavior because of the reserved bandwidth for the camera taking priority when on the same USB controller.
Since not all CPU cores can handle hardware IRQs, it is possible that even if two separate USB controllers are used, then lower priority interrupts could still be lost (IRQ starvation). Simply moving the shared devices to different controllers though would mean the mouse might buffer instead of dropping or rescheduling interrupts.
Hi @linuxdev Thank you for your input.
Here is the output of lsusb -t
Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 38, If 0, Class=Vendor Specific Class, Driver=, 12M (remote control)
|__ Port 2: Dev 39, If 0, Class=Human Interface Device, Driver=usbhid, 12M (mouse)
|__ Port 2: Dev 39, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 19, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 1: Dev 19, If 1, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 1: Dev 19, If 2, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 4: Dev 40, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 4: Dev 40, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 4: Dev 36, If 0, Class=Vendor Specific Class, Driver=, 480M (real sense)
|__ Port 5: Dev 7, If 0, Class=, Driver=, 480M
Port 4, dev 36 is the Realsense
Port 2, Dev 39 is the mouse
Port 1, Dev 38 is an remote control, which is also very critical for have real time response.
All others are sensors. The USB hun connected to TX2 is https://www.amazon.com/gp/product/B07X7V4KS5/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1. It has 7 USB ports. All suppose to be USB 3
However, I am still puzzled why wired mouse works, but wireless mouse is slow.
This is the entire output when run lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 38, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 2: Dev 39, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 39, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 19, If 0, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 1: Dev 19, If 1, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 1: Dev 19, If 2, Class=Human Interface Device, Driver=usbfs, 12M
|__ Port 4: Dev 40, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 4: Dev 40, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 4: Dev 36, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 5: Dev 7, If 0, Class=, Driver=, 480M
Case 1:
Everything above (the first “lsusb -t” you listed) is sharing a USB2 port. The root_hub is itself only USB2 and it isn’t surprising that a camera would consume most of the available bandwidth. I don’t know about this particular camera, but if it has a USB3 capability, then it has been forced to run slower as USB2.
Case 2:
In this second case you have a single device (apparently a HUB) on the USB3 port running at USB3.1 gen. 1 speeds (a.k.a., USB3), and nothing else using it. Other than the HUB 100% of all content is running at USB2 speed or slower.
From what I can see for Intel Realsense T265 specs (which seems to be what you have) indications are this should operate at speed “5000M” since it is capable of USB3.1 gen. 1 (a.k.a., USB3).
Reasons why a USB3 gen. 1 camera might revert to USB2 speeds:
Note that anything reducing speed to USB2 on a USB3 root_hub would be automatically rerouted to a USB2 controller. This forces using most of the bandwidth of the USB2 port by the camera, and could conceivably result in lower responsiveness of other USB devices sharing the port.
If two devices share a port, and one device consumes most of the bandwidth, then it is conceivable that the mere timing of USB data for the mouse could change whether or not the camera interferes with the mouse (especially if the camera is in isochronous mode).
Can you put only your camera on the port for USB3 without a HUB, or else with no other devices sharing the HUB? You might want to log in via ssh or serial console in order to test with no connected devices other than the camera to see if “lsusb -t” speeds up to 5000M for the camera.
I want to emphasize that if this is a cheap HUB, then it might not have multiple transaction translators (multi-TT). The TT is what adapts a slower speed device to a faster bus without making the faster bus itself revert to slower speeds. Consider if everything on the HUB is USB3. In that case there is no need for a TT. If there is no TT, and one device is a mouse operating at USB1.1 speeds, then 100% of all devices would revert to USB1.1. I don’t know if the HUB you use is multi-TT or not.
I removed the hub and plugged only Realsense and the mouse to TX2. Realsense is plugged into type A usb port and the mouse to TX2 micro USB port. Here is the output of “lsusb -t”
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
The Realsense is still linked as a USB 2.0.
I think it is really related to wireless. Even the realsense is connect with USB 3.0 with 5000M, the mouse could still be slow. If I use wired mouse, no problem
Assuming the Realsense can run at USB3 speeds this tends to suggest signal quality was insufficient to run at USB3 speeds. If you plug in nothing but the HUB, and the HUB can run at USB3 without anything attached to it, then you’ve verified that the port itself can route to a USB3 controller
It would be unusual, but I could see the possibility that the R.F. of a WiFi could interfere with the signal and cause a marginal signal to revert from USB3 to USB2. This is rather unlikely, but if it is the case, then some sort of Faraday shielding at the right places (related to USB) might fix it.
Hi @linuxdev I think you pointed a good direction. Could you let me know what kind and where to buy Faraday shielding? Can I use grill foil to test?
Simple aluminum foil or copper foil works well. Just don’t short out the wrong thing, and make sure it is grounded (e.g., to the carrier board mounting screws which also serve as ground).