Which USB approach is best for sending video in one direction...

[st2000]

Hi,

There are more USB options than expected and I am looking for suggestions.

Our USB data flow needs are very specific and only in one direction for this application.  That is, we have several dedicated fixed USB 2.0 and 3.0 connections which will move video and data at nearly a constant flow rate in one direction.  Probably from PERIPHERAL(DEVICE) to HOST.  All connections are between embedded Linux computers.  I have been exploring using GADGET on the Linux computers which will be acting as the PERIPHERAL(DEVICE).  I think this fixes the "USB mode" into one of the preexisting GADGET protocols (i.e. serial, mass-storage, ect).

Question: Which would be best for sending large amounts of data in one direction such as video?

Question: How much of the theoretical band width of 480Mb for USB 2.0 and 5Gb for USB 3.0 can I expect to be available for this data?

If I can not get all my data through.  What about using libusb instead of a kernel-mode USB driver?

Question: Would libusb be able to more efficiently send large amount of data over the USB link?

It is assumed writing libusb on the host side of a USB connection to be an easy to moderately hard task.  There are many examples on the web (CUPS, SANE, ect).  But what about the PERIPHERAL(DEVICE) side?

Question: Is it difficult to create a PERIPHERAL(DEVICE) only using libusb?  Would a feature in GADGET be needed to switch an OTG USB port on an embedded Linux computer from HOST TO PERIPHERAL(DEVICE)?

-thanks

[st2000]

Question: Is it difficult to create a PERIPHERAL(DEVICE) only using libusb?  Would a feature in GADGET be needed to switch an OTG USB port on an embedded Linux computer from HOST TO PERIPHERAL(DEVICE)?

http://www.libusb.org/wiki/FAQ:

Can libusb be used inside a USB device that runs Linux?

No, libusb provides a API for writing software on the host. Of course, if the device also acts as a USB host then libusb could still be useful, but only for the host part of the device.

I guess that answer that.

Question: So if I need to use GADGET on the PERIPHERAL(DEVICE) embedded Linux computer, there is probably no need to use libusb on the HOST embedded Linux computer.  As GADGET is (probably) designed to support (all / most of) the existing set of the readily available USB kernel drivers.  Is this line of reasoning correct?

[Jan Axelson]

See Gadget Drivers here for what is supported:

http://www.linux-usb.org/gadget/

[st2000]

I setup 2 embedded Linux board computers.  One as a gadget and the other as a host.  The gadget (PERIPHERAL(DEVICE)) has the g_serial module loaded in.  The HOST has the usbserial and cdc_acm loaded in.  The throughput tests are no where near what I need.  They are not even breaking the 1MegByte/second threshold.  That's really really short of the 480MB/s speed of a USB 2.0 data line.

What can be done about it?

Am I using the wrong USB setup?

Maybe I need to check the hardware?

Can I configure something differently to get some more speed?

I'll be honest - I need at lest 3/4 of the USB 2.0 bandwidth to finish this project.

Is that just not possible?

-thanks

[Tsuneo]

They are not even breaking the 1MegByte/second threshold.

What is the size of data block exchanged?
Bulk transfer speed is proportional to the transfer size, until saturated (bandwidth/process).

I need at lest 3/4 of the USB 2.0 bandwidth

Theoretical max transfer speed of bulk on high-speed bus is 52000 Kbytes/s
512 (bytes/transaction) x 13 (transactions/microframe) x 8000 (microframes/s) = 52000 Kbytes/s

Do you mean 39 Mbytes/s, at least?

Tsuneo

[st2000]

What is the size of data block exchanged?

I assume these are set in the g_serial driver for the DEVICE and the usbserial and cdc_acm drivers for the HOST.  Perhaps picking different USB drivers may yield better results?

Do you mean 39 Mbytes/s, at least?

No, I mean 3/4 of the USB high speed theoretical limit of 480MB/s. 

Looking around, I see this throughput is not as common as I had hoped.  It appears to get there you need to use USB Interrupt Transfers and use both USB End Points.  Is this supported by any USB driver already in the Linux kernel (i.e. like g_serial & usbserial)??

If not, what is the fastest USB driver already in a modern Linux kernel and how fast is that driver?

Or, where can I find USB drivers that can handle this type of speed??  I need both a DEVICE (OTG) and a HOST driver.

-thanks

[st2000]

Followup,

Wow - according to this "theoretical USB transfer rates" chart I found at evaluationengineering.com, none of the USB combination of features results in anything close to the advertised USB 2.0 speed of 480,000,000 b/s:



Hum, I'm not sure - but maybe the values in other than the left most column are in B/s, not b/s???  That makes more sense.  Still, I'm concerned that I may not get the throughput I need.

-thanks

[Barry Twycross]

Those numbers are indeed bytes per second. They look about right. Its easy to derive them yourself. The periodic transfers (Isoc, Int) are hard numbers, the async transfers (control bulk) depend on the controller. High speed Bulk can do 420Mb/s, which doesn't sound too bad to me, I have actually seen this happen.

Low speed can have a maximum 8 byte packet, only control and int. Int can manage one packet per frame. Control not many.

Full speed can use all four types, max packet is 64 bytes control/bulk and 1023 bytes int/isoc. Int/isoc can do 1 packet per 1ms frame, bulk can do 19 or less packets per frame, depending on the controller. I've seen some controllers which could only do 11.

High speed can do all four types. Max packet is 64 bytes for control, 512 bytes for bulk and 1024 bytes for int/isoc. Int/isoc can do 3 packets per 125µs micro-frame. Bulk tops out at 13 packets per frame, but again depends on controller.

SuperSpeed can do all four types. Max packet is 1024 bytes. I'm not sure of the exact limits, but Isoc can do 48 packets (3 bursts of 16) per 125µs transfer opportunity. I've never calculated the theoretical max for bulk, but I've seen an actual 480MB/s (about 60 packets per 125µs).