Re: [libusb] Asynchronous transfer using libusb-1.0 on ubuntu

[Anand N. <and...@gm...>]

Thanks a lot for such a quick reply and the clarification.



Why?  Not trying to be snotty, but if you're reading large blocks, the gain
from asynchronous processing is not that large.

   - I was wondering, if I have multiple asynchronous transfers lined up,
   it would utilize the bandwidth all the time (may be 2 or more transfers
   overlap) and not wait for the next transfer to be initiated. I just wanted
   to make sure that there is no idle periods in between 2 consecutive
   transfers. Right now I have multiple threads transferring data
   synchronously to different devices but this still doesn't guarantee no idle
   period.



"can I submit a second CBW before the first transfer is complete?

   - I have actually tried this. I submit multiple CBW’s and read the data
   in their callback functions. It doesn’t seem to work and I understand why
   that doesn’t work. I was curious on whether there is some other approach to
   this.


Thanks & Regards
Anand Nahar

On Wed, Aug 16, 2017 at 11:20 AM, Tim Roberts <ti...@pr...> wrote:

> Anand Nahar wrote:
> >
> > I am trying to transfer a chunk of raw data (say 1 GB) to/from a USB
> > stick using libusb-1.0 on Ubuntu. After reading the documentation, I
> > understand that the sequence to transfer data is: *command, data and
> > status*.
> >
> > I am able to read/write raw data to different blocks *synchronously*.
> > The code is:
> >
> >  ...
> >
> > Now, I need to do the same thing *asynchronously*.
>
> Why?  Not trying to be snotty, but if you're reading large blocks, the
> gain from asynchronous processing is not that large.
>
>
> > I understand it has 5 elements:
> >
> >  1. Allocate transfer
> >  2. Fill transfer
> >  3. Submit transfer
> >  4. Callback function
> >  5. Event handler.
> >
> > I am unable to figure out on how should the asynchronous calls be
> > designed so that the command and data calls are made back to back in a
> > loop.
> >
> > Do I need to submit 2 separate transfers: 1 for command and 1 for
> > data. If not, how do I design it?
> >
>
> Yes, exactly like you do now.  For a read, it should be obvious, because
> you're accessing two different endpoints.
>
>
> > If we do have to submit 2 transfers, do I need to wait for command
> > call to be completed before I can actually read the data? If so, would
> > I be achieving significant improvement in the speed?
> >
>
> No, you can send data read immediately after you send the command
> write.  The spec requires that device NAK your read until it actually
> has data to send, which leaves the request pending.
>
> You can figure out the performance improvement, and it is very small.
> If you're transferring 15MB from a USB 2 mass storage device, that's
> going to take between 250ms and 500ms.  The savings in moving from
> synchronous to asynchronous processing is about 1ms.
>
> The more interesting question is "can I submit a second CBW before the
> first transfer is complete?", and I don't know the answer to that.  The
> spec doesn't seem to say whether the device has to NAK the second CBW
> until it sends a CSW for the first one, or if it has to interrupt the
> first command.
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>