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

[Zheng R. <zhe...@gm...>]

Hi Tim,

Thanks very much for your reply firstly.

Tim Roberts wrote:
> zheng rong wrote:
>> On the device side, the image frame size = 360960=512*705, so in the
>> firmware the device will send 705 packets ended with a zero-length
>> packet (totally 706 pkts). The camera streams images frame at about 
>> 30fps.
>
> That's 10.8 MB/s.
>
>> But when running 2 cameras in the same computer from another terminal
>> (using the same executable binary file, but will request different
>> camera serial number), these two cameras will lost data. Some transfers
>> are completed, but the actual transfer length is less than the expected
>> length(e.g. 360852 < 360960). It seems that the 2nd camera interfere the
>> data transfer, which results in the incomplete data frame of 2 cameras.
>
> Right.  This is EXACTLY why isochronous pipes were invented, and 
> streaming video sources are the canonical example of the need for 
> isochronous.  Bulk pipes all compete for the leftover bandwidth, after 
> the scheduled and reserved services have been satisfied. The host 
> controller and its drivers make no guarantees about how they assign 
> transfers in the frame schedule.
>
> You have to understand how USB is implemented.  When the schedule says 
> camera 1 can send, the host controller will send a "GO" signal telling 
> it to send.  If it doesn't have anything right now, it responds with a 
> NAK, and the host controller will keep retrying that read until it 
> gets something.  Those retries are going to use up the bandwidth that 
> you want to use for camera 2.
>
> If you need guaranteed, real-time, scheduled bandwidth, then you 
> should be using isochronous pipes, not bulk pipes.  It's just that easy.
>
>
>> But in the result I got the same problem.
>
> Right.  It's not a usage problem, it's an architecture problem.
>
>
>> Another try is that, I defined the camera device class and declare 2
>> camera objects. For each camera, I start a new thread to configure,
>> submit transfer and run libusb_handle_events. But got the same problem.
>
> Right.  It's not a usage problem, it's an architecture problem.
>
>
>> 1. What may be the reason of this problem?
>
> You have chosen the wrong endpoint type.
>
>
>>    a. Bandwidth? I don't think so. I tested off-the-shelf USB2.0 camera
>> on the same PC, 2 cameras can works fluently at 60fps for each. (the
>> camera interface is USB2.0, and PC interface is USB3.0).
>
> You're not comparing apples to apples here.  That USB camera was using 
> a different frame format (MJPG, for example, would have frames even 
> smaller than your 10MB frames), and that USB camera was almost 
> certainly using isochronous pipes.  Plus, your problem is with TWO 
> cameras sharing the bus.  Did you try TWO off-the-shelf USB cameras 
> simultaneously?

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?

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?

>
> There is roughly 45-50MB/s of usable bandwidth on a typical USB 2.0 
> bus.  A single bulk device can sustain that rate over a bulk pipe, but 
> bulk pipes were simply not designed to share fairly. That's why they 
> are called "bulk" -- they were designed for bulk data transfers that 
> do not have real-time requirements.  When a pipe needs real-time 
> activity, it needs to use a scheduled service -- isochronous.
>
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? 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.


Thanks,

Zheng