|
From: Brett S. <bre...@ae...> - 2006-02-18 23:09:41
|
Dan Ellis wrote: > Brett Swimley wrote: > >> Hi All, >> >> We have been using libusb-win32 with great success to communicate >> with a high speed USB device based on the Freescale MCF547x processor >> family. >> Now, we're to the point where we're trying to maximize the bandwidth >> between the PC-host and the device. >> >> I have a Bulk IN Endpoint with a packet size of 512 Bytes, which >> AFAIK is the maximum packet size allowed for High Speed USB. I have >> also tried configuring this endpoint as an Interrupt Endpoint with a >> packet size of 1024 Bytes. My device can handle either of these >> packet sizes with no problem. >> > > Bulk give you better performance, as interrupt endpoints are only polled > periodically, whereas bulk transactions will attempt to saturate the > bus. > That's what I understood as well. I would like to use bulk if possible. Is it true that max packet size is 512 bytes under USB 2.0? > > >> It *appears* that we can obtain about a 10MByte/sec transfer only. I >> get USB requests going out approximately every 100 (down from 125 >> usec). I have tried both the synchronous and asynchronous APIs and >> they both yield about the same result. Ideally, we would like to >> double the bandwidth to 20 MByte/Sec. >> > > We've achieved more than that on an OUT endpoint with our product using > async calls. Are you double buffering and providing enough space? > > Hmm. double buffering. Are you talking device or host here? Device has a 2K FIFO for usb outputs - We DMA directly from a FPGA Fifo to the Device FIFO. >> Is this possible with libusb-win32? Are there any configuration or >> endpoint settings that I could change to optimize the bandwidth (I >> have control over the device so can change things). Or, is it >> strictly a function of my hardware? I'm currently testing on a Dell >> Dimension 4600 with a 2.8 GHz Pentium4, and a fully patched version >> of Windows XP Professional. >> >> Would multiple IN endpoints help maximize the bandwidth? I can add >> another endpoint if this would help. >> > > Make sure your device is always sending maxpacket sized packets whenever > possible, the transfer will end on a partial one. Request more data than > the maxpacket size, e.g. request 16kB at a time. This allows the host > controller to back-to-back the transactions. If you get a partial or > empty transaction the transfer will be retired early, so your device can > signal immediate attention by doing this. > > You'll still get dips in transmission when the call returns and the next > one is being queued up. You can reduce this by queueing up more than one > buffer and using asynchronous calls. > > Dan. > > I've attempted with 4 buffers on the host. We have a test set up with a 3 MByte transaction to transfer from Device to host on an BULK (or INTERRUPT) IN endpoint. I'm not doing any processing with the data just, handling the transactions and then queueing up another request. I'm currently queueing up 4 separate asynch calls, each with a 64K buffer. Still haven't seen a performance change here. I've never seen a saturated bus as far as I can tell. Is there a magic number for packet size vs. request size that would optimize my throughput? I suppose I could still have a problem on my device end, but I think I can handle the 20MByte/sec bandwidth easily. Thanks for the response. Brett > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > |