kopia lustrzana https://gitlab.com/sane-project/website
201 wiersze
7.6 KiB
HTML
201 wiersze
7.6 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="Oliver Rauch (oliver.rauch@Wolfsburg.DE)">
|
|
<META NAME="Subject" CONTENT="Re: scsi command queuing">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: scsi command queuing</H1>
|
|
<!-- received="Fri Jun 30 07:49:38 2000" -->
|
|
<!-- isoreceived="20000630144938" -->
|
|
<!-- sent="Fri, 30 Jun 2000 16:54:31 +0200" -->
|
|
<!-- isosent="20000630145431" -->
|
|
<!-- name="Oliver Rauch" -->
|
|
<!-- email="oliver.rauch@Wolfsburg.DE" -->
|
|
<!-- subject="Re: scsi command queuing" -->
|
|
<!-- id="395CB4A7.4494D24F@wolfsburg.de" -->
|
|
<!-- inreplyto="395C94CB.2E156E92@satzbau-gmbh.de" -->
|
|
<STRONG>From:</STRONG> Oliver Rauch (<A HREF="mailto:oliver.rauch@Wolfsburg.DE?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395CB4A7.4494D24F@wolfsburg.de>"><EM>oliver.rauch@Wolfsburg.DE</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Fri Jun 30 2000 - 07:54:31 PDT
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0229.html">Henning Meier-Geinitz: "Re: Mustek SE12000SP Plus"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0227.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0240.html">Douglas Gilbert: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0233.html">Henning Meier-Geinitz: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#228">[ date ]</A>
|
|
<A HREF="index.html#228">[ thread ]</A>
|
|
<A HREF="subject.html#228">[ subject ]</A>
|
|
<A HREF="author.html#228">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
abel deuring wrote:
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> Perhaps the Windows driver simply allocates 10 MB or so as buffer
|
|
</EM><BR>
|
|
<EM>> memory, and issues just one read read command for it...
|
|
</EM><BR>
|
|
<P>That is what I think,
|
|
<BR>
|
|
but while it looks that for the UMAX PowerLookIII this sometimes works
|
|
<BR>
|
|
under sane, for the UMAX Supervista S12 I get (with SANE 600dpi A4) a
|
|
<BR>
|
|
backtrack each time the scanner internal image buffer is transfered, on windows
|
|
<BR>
|
|
not.
|
|
<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>
|
|
<P>Possible. But I hope that this is not the only way to get good scanning speeds
|
|
<BR>
|
|
with large images.
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> > So the scanner is able to send lots of buffers without stopping the scanhead
|
|
</EM><BR>
|
|
<EM>> > but not with SANE.
|
|
</EM><BR>
|
|
<EM>> >
|
|
</EM><BR>
|
|
<EM>> > In both cases I use an NCR53c810 scsi adapter.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> That's probably not the worst choice.
|
|
</EM><BR>
|
|
<P>I know :-)
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> >
|
|
</EM><BR>
|
|
<EM>> > Any ideas how we can test if sanei_scsI-req_enter is as fast as multiple reads in
|
|
</EM><BR>
|
|
<EM>> > the kernel?
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Difficult question; I don't know, if or how it is possible to issue
|
|
</EM><BR>
|
|
<EM>> multiple reads for the Linux kernel. But my guess is, that those
|
|
</EM><BR>
|
|
<EM>> multiple reads would have to be queued just like several SCSI commands
|
|
</EM><BR>
|
|
<EM>> being sent via sanei_scsi_req_enter and a write to the SG device file.
|
|
</EM><BR>
|
|
<EM>> (Douglas, any comments?)
|
|
</EM><BR>
|
|
<EM>> [larger block sizes]
|
|
</EM><BR>
|
|
<P>What happens when a backend starts a read command with a buffer
|
|
<BR>
|
|
larger than the scanner internal image buffer. Can someone (Douglas?)
|
|
<BR>
|
|
explain how this is done on the scsi bus and with DMA?
|
|
<BR>
|
|
<P><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>
|
|
<P>Ugh, sounds ugly. Would it be possible to ioctl() the number of static buffers
|
|
<BR>
|
|
(add 1 or 2 static buffers at begin of scanning, reduce the number at the end),
|
|
<BR>
|
|
would that help?
|
|
<BR>
|
|
<P><EM>> in most cases I would recommend smaller buffers.
|
|
</EM><BR>
|
|
<P>Hm, may be the buffer size should be calculated by the free/available memory.
|
|
<BR>
|
|
If I scan a 200 MB image (I do not scan such images, but I know others do ;-) )
|
|
<BR>
|
|
I expect that it takes a long time if I have only 64MB memory or below, but
|
|
<BR>
|
|
with 128MB or better 256MB the scanning can work fast and that should also
|
|
<BR>
|
|
be possible with SANE. So we _need to_ find a way to do this.
|
|
<BR>
|
|
<P>That could explain why I did not see any improvements when I made some tests
|
|
<BR>
|
|
afterwards. Looks like it is not a safe way to icnrease scanning speed.
|
|
<BR>
|
|
<P>Bye
|
|
<BR>
|
|
Oliver
|
|
<BR>
|
|
<P><P><PRE>
|
|
--
|
|
Homepage: <A HREF="http://www.wolfsburg.de/~rauch">http://www.wolfsburg.de/~rauch</A>
|
|
sane-umax: <A HREF="http://www.wolfsburg.de/~rauch/sane/sane-umax.html">http://www.wolfsburg.de/~rauch/sane/sane-umax.html</A>
|
|
xsane: <A HREF="http://www.wolfsburg.de/~rauch/sane/sane-xsane.html">http://www.wolfsburg.de/~rauch/sane/sane-xsane.html</A>
|
|
E-Mail: mailto:<A HREF="mailto:Oliver.Rauch@Wolfsburg.DE?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395CB4A7.4494D24F@wolfsburg.de>">Oliver.Rauch@Wolfsburg.DE</A>
|
|
<P><P><P>--
|
|
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=<395CB4A7.4494D24F@wolfsburg.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0229.html">Henning Meier-Geinitz: "Re: Mustek SE12000SP Plus"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0227.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0240.html">Douglas Gilbert: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0233.html">Henning Meier-Geinitz: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#228">[ date ]</A>
|
|
<A HREF="index.html#228">[ thread ]</A>
|
|
<A HREF="subject.html#228">[ subject ]</A>
|
|
<A HREF="author.html#228">[ 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>Fri Jun 30 2000 - 07:51:56 PDT</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|