kopia lustrzana https://gitlab.com/sane-project/website
206 wiersze
8.0 KiB
HTML
206 wiersze
8.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
||
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
||
<HTML>
|
||
<HEAD>
|
||
<TITLE>sane-devel: Re: scsi command queuing</TITLE>
|
||
<META NAME="Author" CONTENT="abel deuring (a.deuring@satzbau-gmbh.de)">
|
||
<META NAME="Subject" CONTENT="Re: scsi command queuing">
|
||
</HEAD>
|
||
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
||
<H1>Re: scsi command queuing</H1>
|
||
<!-- received="Sun Jul 2 09:58:18 2000" -->
|
||
<!-- isoreceived="20000702165818" -->
|
||
<!-- sent="Sun, 02 Jul 2000 19:10:11 +0200" -->
|
||
<!-- isosent="20000702171011" -->
|
||
<!-- name="abel deuring" -->
|
||
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
||
<!-- subject="Re: scsi command queuing" -->
|
||
<!-- id="395F7773.68AB4289@satzbau-gmbh.de" -->
|
||
<!-- inreplyto="395CB4A7.4494D24F@wolfsburg.de" -->
|
||
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395F7773.68AB4289@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
||
<STRONG>Date:</STRONG> Sun Jul 02 2000 - 10:10:11 PDT
|
||
<P>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0005.html">Oliver Neukum: "Re: can't recognize UMAX-VistaS6 on AHA1520b"</A>
|
||
<UL>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0003.html">Didier Galland: "can't recognize UMAX-VistaS6 on AHA1520b"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#4">[ date ]</A>
|
||
<A HREF="index.html#4">[ thread ]</A>
|
||
<A HREF="subject.html#4">[ subject ]</A>
|
||
<A HREF="author.html#4">[ author ]</A>
|
||
</UL>
|
||
<HR NOSHADE><P>
|
||
<!-- body="start" -->
|
||
<P>
|
||
Oliver Rauch wrote:
|
||
<BR>
|
||
<P><EM>> > Or Perhaps the
|
||
</EM><BR>
|
||
<EM>> > following happens: The Twain driver allocates a larger chunk of buffer
|
||
</EM><BR>
|
||
<EM>> > memory, and then calls the ASPI layer several times. Perhaps the broken
|
||
</EM><BR>
|
||
<EM>> > multitasking concept of Win95/98 is an advantage in this case: The SCSI
|
||
</EM><BR>
|
||
<EM>> > commands probably don't need to be queued in a complex way as with
|
||
</EM><BR>
|
||
<EM>> > Linux, so that it is easier to achieve a very short delay between the
|
||
</EM><BR>
|
||
<EM>> > end of a SCSI command and the start of the next command. (An example for
|
||
</EM><BR>
|
||
<EM>> > the downside of the Win95 concept: Copying larger files over a network
|
||
</EM><BR>
|
||
<EM>> > for example causes 100% CPU load...)
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Possible. But I hope that this is not the only way to get good scanning speeds
|
||
</EM><BR>
|
||
<EM>> with large images.
|
||
</EM><BR>
|
||
<P>I hope it too :) But, considering the discussion in this thread, it
|
||
<BR>
|
||
seems that very short delays between two SCSI commands or huge buffers
|
||
<BR>
|
||
are for many scanners the only ways to avoid scan head stops.
|
||
<BR>
|
||
<P><EM>> > With buffer sizes that large, the SG driver sometimes complained for me
|
||
</EM><BR>
|
||
<EM>> > that it could not allocate the buffer. And the SG driver reserves only
|
||
</EM><BR>
|
||
<EM>> > one buffer permanently (means, while the device file is open). If you
|
||
</EM><BR>
|
||
<EM>> > queue more than one command, the SG driver dynamically allocates another
|
||
</EM><BR>
|
||
<EM>> > buffer for each command. That can lead to swapping, or the queueing cail
|
||
</EM><BR>
|
||
<EM>> > fail with ENOMEM.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Ugh, sounds ugly. Would it be possible to ioctl() the number of static buffers
|
||
</EM><BR>
|
||
<EM>> (add 1 or 2 static buffers at begin of scanning, reduce the number at the end),
|
||
</EM><BR>
|
||
<EM>> would that help?
|
||
</EM><BR>
|
||
<P>That should help, but it would require a modified SG driver. Anyway, you
|
||
<BR>
|
||
can easily see in the debug output, if the ENOMEM error happens: If your
|
||
<BR>
|
||
get one of the sanei_scsi messages
|
||
<BR>
|
||
<P> DBG(1, "issue: ENOMEM - cannot queue SCSI command. "
|
||
<BR>
|
||
"Trying again later.\n");
|
||
<BR>
|
||
or
|
||
<BR>
|
||
DBG(1, "issue: EAGAIN - cannot queue SCSI command. "
|
||
<BR>
|
||
"Trying again later.\n");
|
||
<BR>
|
||
|
||
<BR>
|
||
a SCSI command could not be queued, because either the kernel could not
|
||
<BR>
|
||
allocate buffer memory (ENOMEM), or, for EAGAIN, the "SCSI mid-level
|
||
<BR>
|
||
[is] out of command blocks (rare), try again. This is more likely to
|
||
<BR>
|
||
happen when queuing commands, so wait a bit (eg usleep(10000) ) before
|
||
<BR>
|
||
trying again" (quoted from Douglas' documentation of the SG driver,
|
||
<BR>
|
||
<A HREF="http://www.torque.net/sg/p/scsi-generic_long.txt">http://www.torque.net/sg/p/scsi-generic_long.txt</A>).
|
||
<BR>
|
||
<P><P><EM>>
|
||
</EM><BR>
|
||
<EM>> > in most cases I would recommend smaller buffers.
|
||
</EM><BR>
|
||
<EM>>
|
||
</EM><BR>
|
||
<EM>> Hm, may be the buffer size should be calculated by the free/available memory.
|
||
</EM><BR>
|
||
<EM>> If I scan a 200 MB image (I do not scan such images, but I know others do ;-) )
|
||
</EM><BR>
|
||
<EM>> I expect that it takes a long time if I have only 64MB memory or below, but
|
||
</EM><BR>
|
||
<EM>> with 128MB or better 256MB the scanning can work fast and that should also
|
||
</EM><BR>
|
||
<EM>> be possible with SANE. So we _need to_ find a way to do this.
|
||
</EM><BR>
|
||
<P>I think that at least some choice of the buffer size should be left to
|
||
<BR>
|
||
the user: You can never know what kind of programs and how many of them
|
||
<BR>
|
||
somebody might run at the same time on her/his Linux box. and which
|
||
<BR>
|
||
priority the scanner usage has: If the backend fights too hard for
|
||
<BR>
|
||
memory, this might cause a serious slowdown of other, perhaps more
|
||
<BR>
|
||
important, programs, because their memory content is written to the swap
|
||
<BR>
|
||
disk.
|
||
<BR>
|
||
<P>But "memory policies" aside, you are right, we must find a way to avoid
|
||
<BR>
|
||
scan head stops. But I don't see many options without messing in the
|
||
<BR>
|
||
Linux kernel. At least, I don't see any way to speed things more up than
|
||
<BR>
|
||
to use command queueing and more or less big buffers without asking for
|
||
<BR>
|
||
faster kernel responses or new ioctls, like the idea to implement
|
||
<BR>
|
||
something similar to piping for the handling of really large SCSI read
|
||
<BR>
|
||
commands. (And the latter can be really dangerous: If we have a scanner
|
||
<BR>
|
||
that is unable to do a SCSI disconnect, and a disk, to which the image
|
||
<BR>
|
||
data should be written, connected to the same SCSI bus, there no way to
|
||
<BR>
|
||
get access to the disk while the scan is running.)
|
||
<BR>
|
||
<P>Abel
|
||
<BR>
|
||
<P><PRE>
|
||
--
|
||
Source code, list archive, and docs: <A HREF="http://www.mostang.com/sane/">http://www.mostang.com/sane/</A>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <A HREF="mailto:majordomo@mostang.com?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395F7773.68AB4289@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
||
</PRE>
|
||
<P><!-- body="end" -->
|
||
<HR NOSHADE>
|
||
<UL>
|
||
<!-- next="start" -->
|
||
<LI><STRONG>Next message:</STRONG> <A HREF="0005.html">Oliver Neukum: "Re: can't recognize UMAX-VistaS6 on AHA1520b"</A>
|
||
<LI><STRONG>Previous message:</STRONG> <A HREF="0003.html">Didier Galland: "can't recognize UMAX-VistaS6 on AHA1520b"</A>
|
||
<!-- nextthread="start" -->
|
||
<LI><STRONG>Next in thread:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
||
<LI><STRONG>Reply:</STRONG> <A HREF="0007.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
||
<!-- reply="end" -->
|
||
<LI><STRONG>Messages sorted by:</STRONG>
|
||
<A HREF="date.html#4">[ date ]</A>
|
||
<A HREF="index.html#4">[ thread ]</A>
|
||
<A HREF="subject.html#4">[ subject ]</A>
|
||
<A HREF="author.html#4">[ author ]</A>
|
||
</UL>
|
||
<!-- trailer="footer" -->
|
||
<HR NOSHADE>
|
||
<P>
|
||
<SMALL>
|
||
<EM>
|
||
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
||
: <EM>Sun Jul 02 2000 - 10:01:27 PDT</EM>
|
||
</EM>
|
||
</SMALL>
|
||
</BODY>
|
||
</HTML>
|