[sane-devel] Re: HP SJ5300C
Hi, On Mon, Apr 07, 2003 at 08:07:36PM +0400, Sergey Vlasov wrote: > At least with Mustek BearPaw 2400TA, there is a difference between using > scanner.c or libusb: libusb is slower. Usually this does not matter - > but at some resolutions scanning becomes unusably slow with libusb (lots > of backtracking, even on Athlon XP 2000+), while the same settings with > /dev/usb/scanner0 gives at most 2-3 backtrackings. This is because the > GT68xx chips have a very small buffer - only 16KB. Enabling the fork code may also help (gt68xx.c, near the top). Bye, Henning
[sane-devel] Re: HP SJ5300C
On Mon, 07 Apr 2003 17:28:30 +0200 (CEST) Rene Rebe wrote: > I wouldn't like to mess with scanner.c. libusb just works fine and is > portable. You also mentioned that scanner.c might be deprecated for > kernel 2.6 or so ... At least with Mustek BearPaw 2400TA, there is a difference between using scanner.c or libusb: libusb is slower. Usually this does not matter - but at some resolutions scanning becomes unusably slow with libusb (lots of backtracking, even on Athlon XP 2000+), while the same settings with /dev/usb/scanner0 gives at most 2-3 backtrackings. This is because the GT68xx chips have a very small buffer - only 16KB. Looking at the code, I see that scanner.c uses 32KB buffer size for read, but devio.c (which is used by libusb) uses one-page buffers (4KB on x86). At least with Linux this can be improved - even beyond the scanner.c capabilities. usbdevfs has USBDEVFS_SUBMITURB, which allow asynchronous URB submitting, and even seems to allow queueing more than one URB for the same pipe. (The Windows kernel driver for GT68xx seems to use this: the usbsnoop logs shows that it submits 5 URBs at once and then receives the scanned data using them as a buffer ring.) However, this feature is not currently supported by libusb.
[sane-devel] Re: HP SJ5300C
> At least with Mustek BearPaw 2400TA, there is a difference between using > scanner.c or libusb: libusb is slower. Usually this does not matter - > but at some resolutions scanning becomes unusably slow with libusb (lots > of backtracking, even on Athlon XP 2000+), while the same settings with > /dev/usb/scanner0 gives at most 2-3 backtrackings. This is because the > GT68xx chips have a very small buffer - only 16KB. > > Looking at the code, I see that scanner.c uses 32KB buffer size for > read, but devio.c (which is used by libusb) uses one-page buffers (4KB > on x86). Given that USB 1.1 has a maximum payload of 64 bytes per bulk packet, I don't see a problem with 16kB or even 4kB buffers. Are you sure this is what causes the slowdown? > At least with Linux this can be improved - even beyond the scanner.c > capabilities. usbdevfs has USBDEVFS_SUBMITURB, which allow asynchronous > URB submitting, and even seems to allow queueing more than one URB for > the same pipe. (The Windows kernel driver for GT68xx seems to use this: > the usbsnoop logs shows that it submits 5 URBs at once and then receives > the scanned data using them as a buffer ring.) However, this feature is > not currently supported by libusb. Good that you mention this -- I'm using libusb for another project where throughput is really important. I'll have to look into the way libusb chains URBs. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
