kopia lustrzana https://gitlab.com/sane-project/website
217 wiersze
8.4 KiB
HTML
217 wiersze
8.4 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="Thu Jun 29 10:15:27 2000" -->
|
|
<!-- isoreceived="20000629171527" -->
|
|
<!-- sent="Thu, 29 Jun 2000 19:28:54 +0200" -->
|
|
<!-- isosent="20000629172854" -->
|
|
<!-- name="Oliver Rauch" -->
|
|
<!-- email="oliver.rauch@Wolfsburg.DE" -->
|
|
<!-- subject="Re: scsi command queuing" -->
|
|
<!-- id="395B8756.BA86E297@wolfsburg.de" -->
|
|
<!-- inreplyto="395B3DA1.B771658E@satzbau-gmbh.de" -->
|
|
<STRONG>From:</STRONG> Oliver Rauch (<A HREF="mailto:oliver.rauch@Wolfsburg.DE?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395B8756.BA86E297@wolfsburg.de>"><EM>oliver.rauch@Wolfsburg.DE</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Thu Jun 29 2000 - 10:28:54 PDT
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0217.html">Wolfgang Rapp: "Re: scsi command queuing"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0215.html">Joachim Ansorg: "Problems with mustek scanner"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0212.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#216">[ date ]</A>
|
|
<A HREF="index.html#216">[ thread ]</A>
|
|
<A HREF="subject.html#216">[ subject ]</A>
|
|
<A HREF="author.html#216">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
abel deuring wrote:
|
|
<BR>
|
|
<P><EM>> As far as my experiences go, the scan speed (mainly the number of the
|
|
</EM><BR>
|
|
<EM>> scan head stops) depends on quite a number of factors:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> - more or less broken scanner firmware
|
|
</EM><BR>
|
|
<EM>> - too tiny memory for the scanner's controller
|
|
</EM><BR>
|
|
<EM>> - slow responses by the host machine (backend; sanei_scsi layer; speed
|
|
</EM><BR>
|
|
<EM>> of the low level drivers)
|
|
</EM><BR>
|
|
<P>Yes, but I compared it with th windows driver. That does scan some MB
|
|
<BR>
|
|
and then the scanhead stops for a longer time. If I scan with sane the
|
|
<BR>
|
|
scanhead stops after 256KB (size of the scanner internal image buffer)
|
|
<BR>
|
|
whe I scan large images (on images up to 30 MB there is no problem).
|
|
<BR>
|
|
<P>So the scanner is able to send lots of buffers without stopping the scanhead
|
|
<BR>
|
|
but not with SANE.
|
|
<BR>
|
|
<P>In both cases I use an NCR53c810 scsi adapter.
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> "If": Well, the JX250 shows that command queueing works and can have
|
|
</EM><BR>
|
|
<EM>> some influence :) Regarding "how": sanei_scsi_open checks, how many
|
|
</EM><BR>
|
|
<EM>> commands can be queued by the Linux SCSI subsystem (there is a DBG
|
|
</EM><BR>
|
|
<EM>> statement showing this number). sanei_scsi_req_enter checks, if this
|
|
</EM><BR>
|
|
<EM>> queue is full; if it isn't, it sends the command to the SG driver, else
|
|
</EM><BR>
|
|
<EM>> it queues the command internally. sanei_scsi_req_wait wait for the
|
|
</EM><BR>
|
|
<EM>> oldest queueing command to finish; if there are any commands in the
|
|
</EM><BR>
|
|
<EM>> "sanei_scsi-internel" queue which not yet sent to the SG driver, they
|
|
</EM><BR>
|
|
<EM>> are sent, until the low level queue is again full, or the internal queue
|
|
</EM><BR>
|
|
<EM>> is completely sent.
|
|
</EM><BR>
|
|
<P>Yes, waht I wanted to know is if the queueing is done in the scanner
|
|
<BR>
|
|
on in the scsi adapter driver and that can not be found out with the
|
|
<BR>
|
|
sanei_scsi debug messages.
|
|
<BR>
|
|
(Doug helped me: the scanner does not support queueing, it is done in the driver).
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> > If we talk about scanspeed we should think about extending the sg driver for
|
|
</EM><BR>
|
|
<EM>> > doublebuffering data pages in kernel memory space
|
|
</EM><BR>
|
|
<EM>> > and command block repeat count.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Well, I think that the sanei_scsi_req_enter / sanei_scsi_req_wait
|
|
</EM><BR>
|
|
<EM>> mechanism should give similar results as command repeating, but the
|
|
</EM><BR>
|
|
<EM>> former is more flexible, because you can also sent some status inquiries
|
|
</EM><BR>
|
|
<EM>> or whatever between to "read data" commands.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<P>Any ideas how we can test if sanei_scsI-req_enter is as fast as multiple reads in
|
|
<BR>
|
|
the kernel?
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Now for a different idea. (If I'm going to talk nonsense, let me know.)
|
|
</EM><BR>
|
|
<EM>> If my memory is right, it is for example possible even with the ISA card
|
|
</EM><BR>
|
|
<EM>> aha1542 to issue SCSI commands with data blocks larger than 64 kB. Since
|
|
</EM><BR>
|
|
<EM>> the DMA block size for ISA cards is limited to 64 kB, this means that
|
|
</EM><BR>
|
|
<EM>> the kernel must organize more than one DMA transfer for one SCSI
|
|
</EM><BR>
|
|
<EM>> command. At present, these data are collected in a large buffer (or with
|
|
</EM><BR>
|
|
<EM>> scatter-gather, in several buffers), and and when a SCSI fommand
|
|
</EM><BR>
|
|
<EM>> finishes, all bytes are at once tranferred to the user memory. In other
|
|
</EM><BR>
|
|
<EM>> words, the machine must have enough memory to buffer the entire data
|
|
</EM><BR>
|
|
<EM>> block (or another copies, if DMA to user space is not possible). This
|
|
</EM><BR>
|
|
<EM>> sets some limit for the reasonable data block size of a SCSI command:
|
|
</EM><BR>
|
|
<EM>> the size should of course not be larger than the phyical memory
|
|
</EM><BR>
|
|
<EM>> installed; and since Unix is a multitasking OS, one should leave enough
|
|
</EM><BR>
|
|
<EM>> memory for other processes. Using data block sizes of more than a few
|
|
</EM><BR>
|
|
<EM>> hundred kB for SCSI commands is in my opinion a bad idea even on a
|
|
</EM><BR>
|
|
<EM>> workstation with 128 MB RAM or more.
|
|
</EM><BR>
|
|
<P>Unbelievable, you are right: I just did a test with a scsi buffer that is greater
|
|
<BR>
|
|
than the scanner internal image buffer and in fact the number of backtracks
|
|
<BR>
|
|
is reduced (and the scanner does not stop after each buffer, it scans 4-5 buffers
|
|
<BR>
|
|
before it stops).
|
|
<BR>
|
|
<P>I will play around a bit with that.
|
|
<BR>
|
|
<P>At least we can give the user the selection how much mem sane may use to scan.
|
|
<BR>
|
|
And a 2MB Buffer should not too bad if it solves the backtracking problem.
|
|
<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=<395B8756.BA86E297@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=<395B8756.BA86E297@wolfsburg.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0217.html">Wolfgang Rapp: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0215.html">Joachim Ansorg: "Problems with mustek scanner"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0212.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0225.html">abel deuring: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#216">[ date ]</A>
|
|
<A HREF="index.html#216">[ thread ]</A>
|
|
<A HREF="subject.html#216">[ subject ]</A>
|
|
<A HREF="author.html#216">[ 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>Thu Jun 29 2000 - 10:16:52 PDT</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|