Oliver Rauch wrote:
> > Or Perhaps the
> > following happens: The Twain driver allocates a larger chunk of buffer
> > memory, and then calls the ASPI layer several times. Perhaps the broken
> > multitasking concept of Win95/98 is an advantage in this case: The SCSI
> > commands probably don't need to be queued in a complex way as with
> > Linux, so that it is easier to achieve a very short delay between the
> > end of a SCSI command and the start of the next command. (An example for
> > the downside of the Win95 concept: Copying larger files over a network
> > for example causes 100% CPU load...)
>
> Possible. But I hope that this is not the only way to get good scanning speeds
> with large images.
I hope it too :) But, considering the discussion in this thread, it
seems that very short delays between two SCSI commands or huge buffers
are for many scanners the only ways to avoid scan head stops.
> > With buffer sizes that large, the SG driver sometimes complained for me
> > that it could not allocate the buffer. And the SG driver reserves only
> > one buffer permanently (means, while the device file is open). If you
> > queue more than one command, the SG driver dynamically allocates another
> > buffer for each command. That can lead to swapping, or the queueing cail
> > fail with ENOMEM.
>
> Ugh, sounds ugly. Would it be possible to ioctl() the number of static buffers
> (add 1 or 2 static buffers at begin of scanning, reduce the number at the end),
> would that help?
That should help, but it would require a modified SG driver. Anyway, you
can easily see in the debug output, if the ENOMEM error happens: If your
get one of the sanei_scsi messages
DBG(1, "issue: ENOMEM - cannot queue SCSI command. "
"Trying again later.\n");
or
DBG(1, "issue: EAGAIN - cannot queue SCSI command. "
"Trying again later.\n");
a SCSI command could not be queued, because either the kernel could not
allocate buffer memory (ENOMEM), or, for EAGAIN, the "SCSI mid-level
[is] out of command blocks (rare), try again. This is more likely to
happen when queuing commands, so wait a bit (eg usleep(10000) ) before
trying again" (quoted from Douglas' documentation of the SG driver,
http://www.torque.net/sg/p/scsi-generic_long.txt).
>
> > in most cases I would recommend smaller buffers.
>
> Hm, may be the buffer size should be calculated by the free/available memory.
> If I scan a 200 MB image (I do not scan such images, but I know others do ;-) )
> I expect that it takes a long time if I have only 64MB memory or below, but
> with 128MB or better 256MB the scanning can work fast and that should also
> be possible with SANE. So we _need to_ find a way to do this.
I think that at least some choice of the buffer size should be left to
the user: You can never know what kind of programs and how many of them
somebody might run at the same time on her/his Linux box. and which
priority the scanner usage has: If the backend fights too hard for
memory, this might cause a serious slowdown of other, perhaps more
important, programs, because their memory content is written to the swap
disk.
But "memory policies" aside, you are right, we must find a way to avoid
scan head stops. But I don't see many options without messing in the
Linux kernel. At least, I don't see any way to speed things more up than
to use command queueing and more or less big buffers without asking for
faster kernel responses or new ioctls, like the idea to implement
something similar to piping for the handling of really large SCSI read
commands. (And the latter can be really dangerous: If we have a scanner
that is unable to do a SCSI disconnect, and a disk, to which the image
data should be written, connected to the same SCSI bus, there no way to
get access to the disk while the scan is running.)
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sun Jul 02 2000 - 10:01:27 PDT