Re: [Libusb-devel] Bulk transfers and packet size

[Peter S. <pe...@st...>]

Jef Driesen wrote:
> >> And which block size should I use? wMaxPacketSize?
> >
> > the block size should be several times wMaxPacketSize
> 
> If I understand you correctly, I should send multiple blocks in
> parallel? How does that work? I mean assume I have a total amount
> of let's say 16K and I want to send that in blocks of 1K. If I
> submit the second block before the first one is finished, does the
> usb stack (or libusb) makes sure the blocks are received in the
> correct order?

If you queue multiple transfers using the libusb async API then that
queue will go all the way to the wire, and that way you get both
frequent updates, and maximum bus utilization. USB always guarantees
ordered delivery.

If you do one really large transfer you'll also get max bus use, but
no progress updates.

If you do many small transfers without queueing you get updates but
lose performance.


> I assume this requires the async libusb api?

Yes.


> Since performance isn't critical for my application I was planning
> to use the sync api for simplicity (my api sitting on top of libusb
> doesn't have an async api). I'm willing to trade in some
> performance for an enhanced user experience (e.g. a smooth progress
> bar), but I just want to make sure the speed doesn't suffer too
> much.

With sync you will do a whole lot of context switching after a
finished frame, probably it will take 5-10 ms before you have the
next frame going out.

If this is the *only* thing happening on the bus, you effectively get
only 1/5 - 1/10 the performance.


> >> similar to normal I/O
> >> Or is it more similar to serial or socket I/O
> >
> > Some devices will continue sending data until they have no more,
> > and then send a short packet (i.e., less than wMaxPacketSize
> > bytes) to signal the end of a bulk transfer.  Others will simply
> > stop sending until they have more data available.
> 
> I'll check with the hardware vendor.

You could also just try it out and see what happens. If you ever get
a short transfer back from libusb you know that's what the device
does. If you get a timeout, then the device is sending back NAK to
transfers, when it has no data. (IMO this is more correct, since
retries can stay in the lower layers that way.)


//Peter