Menu
▾
▴
Re: [Libusb-devel] Slow USB bulk transfer
|
From: Del M. <de...@al...> - 2007-03-01 15:19:30
|
mohammed abuhijle wrote:
> Alright then, thanks for the explanation. I was using 512 because I
> thought I had to abide by the maxPacketsize of the endpoint I am using.
>
> Now the second problem is that I get a zero as a return value from
> usb_bulk_write. It is still the same code but with changing the size
> value of usb_bulk_write to 1 MB instead of 512.
Well, in theory you can say, "here's 1MB; gopher it". But in practice
you probably don't want to do that. First, it's possible Linux has a
limit on the size of what it buffers. More likely the device won't like
something that big, since it too will have to deal with it. When I
write, I pick what I consider a "reasonable but still magic" number,
like 32KB or 64KB. This keeps the buffers manageable on my end and
minimizes the likelihood of blowing away some (un)documented buffer
limit on the device. If you are using USB 2.0 and know the device well,
you might want to pick a bigger chunk size, but 64KB (64*1024, not
64*1000) is probably big enough for many apps to get good throughput and
small enough to help you catch errors in a timely manner.
It's much like any other packet-driven system: the bigger the packet,
the better the possible throughput, but the worse the error recovery -
particularly if you can or have to retransmit the data.
There are other reasons you could be getting nowhere. Is "epi" the
input or output endpoint? What do you see in /var/log/messages? Do
you have access to a USB analyzer? It could be you are getting NAKed or
STALLed.
Finally, my read of linux.c's usb_urb_transfer() suggests that you
don't want a "0" timeout, since it will force a return before the urb is
reaped. I'd make the timeout at least several tens - if not a hundred
or so - milliseconds. That will give the kernel a chance to process the
urb. You may need to keep tinkering with the timeout and the buffer
size to get the "best" performance.
-Del
> Looking at linux.c, this means that zero bytesdone have been returned
> and I wrote nothing to the device..!!
>
> What could be going wrong. As you mentioned, bulk is synchronous, so
> it had to wait until something is written and then come back..I also
> have the timeout value as zero...which according to my understanding
> is ignored altogether if we doing bulk read/write...
>
>
>
> On 2/28/07, *Tim Roberts* <ti...@pr... <mailto:ti...@pr...>> wrote:
>
> mohammed abuhijle wrote:
> >
> > I have the following code that takes more than a min to finisg:
>
> That's right.
>
>
> > /*write 40 Mbytes worth of data to the bulk endpoint*/
> > /*i am calculating this by: 512 (packet size) * 2 = 1 KB, * 1000 =
> > 1MB, * 40 = 40 MB*/
> > for (i = 0; i < 2 * 1000 * 40 ; i++){
> > ret = usb_bulk_write(cypress_dev_handle, epi,bytes, 512, 0 /*the
> > timrout is ignored for bulk transfer*/);
> > //printf ("i is:%d\t ret is %d\t bytes is %s\n",i, ret,bytes);
> > }
>
> Remember that USB is a "scheduled" bus. The USB host controller
> has to
> have a frame all planned out before the frame begins. In your
> case, you
> are sending exactly one packet down, which then gets scheduled into a
> frame, and because usb_bulk_write is synchronous, you then wait until
> the transfer is complete, thereby wasting the rest of the frame. That
> means you cannot do any better than one packet per frame, 512k
> bytes per
> second, which would make 40MB take 80 seconds.
>
> The USB subsystem will happily chop up a large transfer into
> packet-sized pieces as needed, and when it does so, it will pack in as
> many packets as it can into a single frame. You can send
> megabytes to
> usb_bulk_write, and get your 40MB transferred in a second or two.
>
> --
> Tim Roberts, ti...@pr... <mailto:ti...@pr...>
> Providenza & Boekelheide, Inc.
>
>
> -------------------------------------------------------------------------
>
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> <mailto:Lib...@li...>
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
> <https://lists.sourceforge.net/lists/listinfo/libusb-devel>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
|
