Re: problems increasing SG_BIG_BUFF
Rainer Krienke (krienke@uni-koblenz.de)
Wed, 30 Jun 1999 08:46:58 +0200
Douglas Gilbert wrote:
>
> wrote:
> >
> > Hello Developers,
> >
> > my situation:
> > SuSE 6.1
> > new kernel 2.2.9
> > /usr/include/scsi is linked to /usr/src/linux/include/scsi
>
> Monty (cdparanoia author) has a nice way around the
> above directory problem:
>
> #include <linux/../scsi/sg.h>
> #include <linux/../scsi/scsi.h>
>
> [An elegant hack!]
>
> >
> > problem:
> > I tried to increase the generic-scsi buffer. The man-pages told me to change
> > SG_BIG_BUFF. the new kernel uses another define (SG_SCATTER_SZ), but there are
> > also these two lines:
> >
> > #define SG_BIG_BUFF SG_SCATTER_SZ /* for backward compatibility */
> > /* #define SG_BIG_BUFF (SG_SCATTER_SZ * 8) */ /* =256KB, if you want */
> >
> > So I increased SG_BIG_BUFF and compiled the kernel and sane again.
> > The result was: nothing. Some months ago when I used an older kernel (2.0.x),
> > there was an result: My scanner did not stop every 5mm to transfer the data (it
> > sounds horrible if it stops every 5mm).
> >
> > My question:
> > Can anybody help me? How to increase the buffer?
> >
> Andreas,
> You may like to try this ... go to
> http://www.torque.net/sg
> and download sg version 2.1.34 (you have version
> 2.1.32 in 2.2.9). In the new sg.h change the
> SG_DEF_RESERVED_SIZE to 262144 and try that.
> [This assumes that your SCSI adapter does scatter
> gather which even most ISA ones do.]
>
> While your at that web site you may be interested
> in the documentation's section on "SG_BIG_BUFF and
> friends".
>
> BTW 2.2.9-ac3 also contains the most recent sg
> driver.
>
> In the new sg driver SG_BIG_BUFF exists for backward
> compatibility (which doesn't extend to people
> changing it :-) ). Internally the sg driver takes
> no account of it. Some apps are fooled by it but not,
> it would seem, sane.
>
> Hopefully in the future the sane linux transport layer
> will use the SG_SET_RESERVED_BUFFER ioctl() and sane's
> documentation will stop recommending people hacking
> the sg.h header file. Under 2.2 with the original
> sg driver this is a very dangerous thing to do (ie
> greatly increases the probably of an ENOMEM induced
> oops, especially on modules).
>
> Doug Gilbert
>
> --
I have nearly the same situation (kernel 2.2.10) and the same problems
like Andreas Buesching.
I changed the definition of SG_DEF_RESERVED_SIZE to the value mentioned
above and basically it works but practically it is still unusable. I
tried to scan a DINA4 page with 300DPI in color mode. This is, at least
for me, a usual configuration for scanning pictures. The scan took about
3 minutes and the scanner sounded really ill doing the backtracking all
the time.
Before I used the old sg driver with a patch that uses a static buffer
of 1MBytes in size. This prevents the sg driver of beeing used as a
module but has a really great effect in scanning time. To scan a DINA4
page in 300 DPI color mode then takes only 45 seconds. Compared to the
new sg driver this is about 4 times faster and after all it probably
will be good for the scanner hardware itself as well (it needs do to
backtracking only about 5 times compared to >20 times using the new
driver).
Wouldn´t it be possible to include such a static buffer (optional) in
the new sg driver as well? The best new driver doesn't help, if you
actually cannot use it in real live and as you can see from the examples
avove this is true for the current situation.
Thanks
Rainer
--
---------------------------------------------------------------------
Rainer Krienke krienke@uni-koblenz.de
Universitaet Koblenz, http://www.uni-koblenz.de/~krienke
Rechenzentrum, Voice: +49 261 287 - 1312
Rheinau 1, 56075 Koblenz, Germany Fax: +49 261 287 - 1355
---------------------------------------------------------------------
--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com