I recently write a program that is mainly used for processing streams from a usb camera, and next I want to transfer the processed streams to my windows pc. Since usb has more bandwith than Ethernet, I want to transfer streams from jetson to windows pc using usb rather than Ethernet.
What I have tried:
using usbncm. This will have 2.0Gbits/s bandwith, but can’t reach the maxmun bandwith of usb3.0 (5Gbits/s)
using libusb. This library will only work on host side, so I don’t known what to do with jetson as device side.
In addtion, my program is written in c++. Is threre anyone can give me some suggestions?
Hi,
This would need other users to share experience. We have the README file for connecting to host PC in Linux Ubuntu. If you connect Jetson platform to a Linux host, the README pops up. For connecting to Windows OS, would see if other users can check and suggest next.
Although, README pops up as well when connecting to Windows OS, the contents only show instructions about how to configure USB Gadget Api, and this storage is readable only, so it is not helpful to me.
I’d want to known:
What’s the maximum bandwith that usbncm can reach? From what I have tested on my Jetson Orin Nx 16GB, the rndis can only reach 670Mbits/s, the usbncm can reach 2.2Gbits/s, and the test is based on iperf3.
How to configure Jetson so that I can receive and send data through usb protocol, and whether the throughput can exceed 2.2Gbits/s.
I will wait and see if anyone else can give me some recomendations.
I don’t have a solution for you, but do understand that there is overhead in any type of communications. USB in particular is less predictable since it has several modes. The only mode which will reserve bandwidth and act in a true realtime manner is isochronous, but the device mode of a Jetson does not support isochronous. Furthermore, you would have to write your own custom drivers for that case (and for many cases), whereas with networking no special driver is needed. For the virtual ethernet over USB you are getting the overhead of both ethernet and USB. You could probably with some tuning get more throughput, if you have some knowledge on the topics, but I don’t think it would be a lot. Going to something like USB3.1 gen. 2 (USB3.2, 10 Gb/s) would instantly help, but the existing hardware does not support above USB2 for device mode, and does not support isochronous at all.
Although the cost is not trivial, nor the power consumption or physical size change, a 10 Gb/s NIC over PCIe would do what you want without much work and without custom drivers (though you would have to spend some time properly setting up the NIC).
Where are you seeing usbncm? I have a limited understanding on that, but from what I can tell this is just a protocol which occurs over USB. USB itself is just a “pipe” for data, but it can operate in different modes. Examples of USB modes:
Isochronous mode. This is as close as possible to hard realtime, and typically is used with low latency special cases of real time. Audio and video would use this for something like a studio recording.
Cheaper audio, e.g., a gaming headset, probably uses a bulk/batch style mode. Hard drives only use the batch/bulk style mode. This adds buffering, and average throughput goes up, but timing becomes less predictable.
Mice and keyboards, and many human interface devices, use an interrupt mode. This means that as the device produces output, it triggers a driver interrupt. For example, moving a mouse or typing on the key of a keyboard triggers an service interrupt.
Note that something like an ethernet card can use either a bulk/batch type mode, or it can use an isochronous mode. The default would be a bulk/batch mode. You would only see isochronous mode in special cases. Typically one would write a custom driver for the device for isochronous mode, but “standard” devices might also work with “generic” drivers in the higher latency modes.
I don’t know much about usbncm, but I believe that it could use any of the modes if the driver is set up for that mode. The usbncm itself would not care, nor be aware of, whether this is USB2 or USB3. If usbncm has a custom driver, then it is possible that it is more efficient than the generic drivers, but I don’t know for certain.
Do note that when a USB device is plugged into a USB host, that a kind of “BIOS” (it isn’t really a BIOS, but it is a standardized report of capabilities) is played to the host from the device. There is one set of specs for a USB2 or older device (USB2 and older are handled by a single controller which can shift between modes), but if and only if the device is capable of USB3+, will a second “BIOS” be reported. That’s the plug-n-play information, and for USB3+, there is a dedicated controller. If one device can run both USB2 and earlier, or USB3+, then it reports the USB2 capabilities over the USB2 wiring; the USB3+ information only shows up if the wiring for USB3+ is present. Some devices are USB3 only, and do not support USB2, and in that case, if plugged into a USB2 or slower port, then the device will remain invisible and not be found.
Different drivers are offered a chance to service the plug-n-play information via hot plug announcing that information, and if drivers are present for both USB2 and USB3+, then the fastest driver will take precedence and take ownership of the device. I don’t think usbncm cares about USB2 or USB3, but if custom drivers are available, then the drivers responding to it will care. It is up to the drivers to choose to take ownership or not.
One would need static IP address setup, but in theory that would work well. Ethernet itself, especially at higher speeds, can depend on frame size for efficiency. The nature of the data will change efficiency drastically depending on how well it matches frame size (I’m thinking of jumbo frames). Different NICs support different frame sizes, but I suspect that all of the NICs which are faster than 1 Gb/s support most of the jumbo sizes if the drivers also support it. They wouldn’t care about USB modes per se, although a larger buffer size in USB might help.