Re: MAX_USBFS_BUFFER_SIZE

[René Rebe <rene@exactcode.de>]

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/