Messages in this thread | | | From | René Rebe <> | Subject | Re: MAX_USBFS_BUFFER_SIZE | Date | Fri, 3 Mar 2006 08:27:45 +0100 |
| |
Hi,
On Thursday 02 March 2006 22:05, Pete Zaitcev wrote: > On Wed, 1 Mar 2006 22:42:35 +0100, René Rebe <rene@exactcode.de> wrote: > > > > > drivers/usb/core/devio.c:86 > > > > #define MAX_USBFS_BUFFER_SIZE 16384 > > > So, queing alot URBs is the recommended way to sustain the bus? Allowing > > way bigger buffers will not be realistic? > > Have you ever considered how many TDs have to be allocated to transfer > a data buffer this big? No, seriously. If your application cannot deliver > the tranfer speeds with 16KB URBs, we ought to consider if the combination > of our USB stack, usbfs, libusb and the application ought to get serious > performance enhancing surgery. The problem is obviously in the software > overhead.
As I already wrote, queing multiple URBs in parallel solved the problem for me. I'll post the libusb patch later. So the problem just was time of no pending URBs wasted a lot of time slots where no URB was exchanged with the scanner.
Queueing N = size / 16k URBs in parallel gets the maximal possible thruput with the scanner - a 2x speedup. The driver is now even slightly faster than the vendor Windows one by about 20%.
For even further improvements a _async interface would be needed in libusb (and sanei_usb) so I can queue the prologue and epilogue URBs of the protocol of communication into the kernel and thus elleminate some more wasted time slots. I estimate that the driver would then be over 30% faster compared with the Windows one.
Yours,
-- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |