Re: [libusb] less data length in async bulk transfer with 2 cameras

[zheng r. <zhe...@gm...>]

Tim Roberts wrote：

> Zheng Rong wrote:
> >
> > Yes, I tried two off-the-shelf USB cameras simultaneously and get
> > 60fps+60fps performance. And, these cameras use non-compressed image
> > format and have the same size as my design. They also use BULK
> > endpoint for data transfer. Actually this is the reason why I chose to
> > use bulk xfer type in my design, I thought I could be able to get the
> > similar performance. But at the current  point I can not get that. Any
> > clue to explain this?
>
> How much buffering do you have in your design?


On the device side, I set a 512*4=2K buffer for the data streaming.
On the host app side, I have a 16*360960 (space for 16 image frames) buffer
for transfer queue(length=16).
I tried larger host app buffer, but got the similar result. Much larger
queue length (e.g. 64) even cause xfer failure.
Is this buffer large enough?



> If you were delayed for a millisecond, would you lose data?
>

What do you mean? Do you mean the buffer is not enough for the data
streaming, in the case of xfer delayed?

Another thing that makes me confused is only a part of data lose, e.g. 80
bytes. This is not the size of packet (512 Bytes) or the xfer size (360960
Bytes).
It seems the xfer didn't lose the entire packet.



> > I will try isochronous xfer mode in my design as you suggested. You
> > said the isochronous xfer can guarantee the bandwidth for 2 cameras.
> > Why? Is it because isochronous xfer won't do retry when it get NACK?
>
> No.  When you select an alternate setting for an isochronous endpoint,
> the system reserves a piece of each frame specifically for that
> endpoint, whether it uses it or not.  You are guaranteed that your
> device will have a time slot when your turn comes around.  With two
> isoch devices, assuming there is room for both, each gets its own
> guaranteed time slot.  There is no competition.  With a bulk pipe, there
> is no such reservation.  You are competing with all the other bulk
> devices for whatever bandwidth is left over.
>

OK, understood. I will try this.

> One more question: My computer's USB is version 3.0, and cameras are
> > USB2.0. If I connect multiple USB2.0 cameras to the computer, the
> > bandwidth for upstream is 480Mbps or 5Gbps? For a USB2.0 hub, the
> > upstream bandwidth is certainly 480Mbps. What is the total upstream
> > bandwidth for a USB3.0 hub connected with USB2.0 devices?
>
> The USB 2.0 devices are all sharing 480Mbps.  The USB 3 host controller
> ends up exposing an xHCI controller that runs at USB 3 speeds, and an
> EHCI controller that runs at USB 2 speeds.
>

Do you mean that, even for a USB3.0 hub, if several USB2.0 devices is
connected with it, the upstream (interfacing with a USB3.0 host computer)
bandwidth for the hub is only 480Mbps?
But for the host computer with xHCI controller, if directly connected with
USB2.0 devices, the upstream can run at USB3.0 speed.
Is my understanding right?

In the USB physical interface, USB high speed signal and super speed signal
use different signal path. I am just wondering if the USB 3.0 hub chip can
transit the data from downstream USB2.0 device to upstream USB3.0.
For example, can a USB3.0 hub handle data transfer from 4 USB2.0 cameras
(each has 20MB/s datarate) to a USB3.0 host computer, as the following
connection structure?

hostPC  <==USB3==>  USB3-hub  <== 4 x USB2==>  4 x USB2 cameras with total
datarate larger than 480Mbps

> I ask this question because I found: if 2 off-the-shelf cameras are
> > connected to PC through a USB2.0 hub, the frame rate can only get
> > about 45fps+45fps; But if I connect the cameras directly to PC, the
> > frame rate can be 60fps+60fps even more.
>
> The frame rate is not important.  What's important is bytes per second.
> Adding a hub always affects the timing by introducing delays.  It's
> possible that the hub's communication is causing your retries to fall
> across some threshhold so that you lose a packet time.
>
>
Thanks a lot,
Zheng