kopia lustrzana https://gitlab.com/sane-project/website
198 wiersze
6.9 KiB
HTML
198 wiersze
6.9 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="Douglas Gilbert (dgilbert@interlog.com)">
|
|
<META NAME="Subject" CONTENT="Re: scsi command queuing">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: scsi command queuing</H1>
|
|
<!-- received="Thu Jun 29 18:50:35 2000" -->
|
|
<!-- isoreceived="20000630015035" -->
|
|
<!-- sent="Thu, 29 Jun 2000 22:05:52 -0400" -->
|
|
<!-- isosent="20000630020552" -->
|
|
<!-- name="Douglas Gilbert" -->
|
|
<!-- email="dgilbert@interlog.com" -->
|
|
<!-- subject="Re: scsi command queuing" -->
|
|
<!-- id="395C0080.1A82F22A@interlog.com" -->
|
|
<!-- inreplyto="395B9C72.12C0D2D7@rapp-informatik.de" -->
|
|
<STRONG>From:</STRONG> Douglas Gilbert (<A HREF="mailto:dgilbert@interlog.com?Subject=Re:%20scsi%20command%20queuing&In-Reply-To=<395C0080.1A82F22A@interlog.com>"><EM>dgilbert@interlog.com</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Thu Jun 29 2000 - 19:05:52 PDT
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0222.html">Petter Reinholdtsen: "SANE developers with write access to CVS"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0220.html">Francesco Anselmo: "Re[2]: Mustek A3SP (SCSI)"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0217.html">Wolfgang Rapp: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0227.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0205.html">Henning Meier-Geinitz: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#221">[ date ]</A>
|
|
<A HREF="index.html#221">[ thread ]</A>
|
|
<A HREF="subject.html#221">[ subject ]</A>
|
|
<A HREF="author.html#221">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Wolfgang Rapp wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Oliver Rauch schrieb:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> > if I do not send the image data from the reader_process to the main process
|
|
</EM><BR>
|
|
<EM>> > (only send read commands to the scsi bus) the scanning speed is not increased.
|
|
</EM><BR>
|
|
<EM>> > So I also think it is a problem between sanei_scsi, the sg driver and the kernel
|
|
</EM><BR>
|
|
<EM>> > lowlevel scsi driver. In sanei_scsi there also is a not really necessary memcpy
|
|
</EM><BR>
|
|
<EM>> > command but I do not think that this command does make the problem.
|
|
</EM><BR>
|
|
<EM>> >
|
|
</EM><BR>
|
|
<EM>> > A bit strange is that it does not make any differences if I use 32 KB or 256KB
|
|
</EM><BR>
|
|
<EM>> > for the read command buffer (The scanner has 256KB internal image data).
|
|
</EM><BR>
|
|
<EM>> >
|
|
</EM><BR>
|
|
<EM>> >
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Moin Oliver
|
|
</EM><BR>
|
|
<EM>> Yes this shows that the scan commands must be send very fast to have no
|
|
</EM><BR>
|
|
<EM>> stops - because the firmare of the scanners have the same quality as the
|
|
</EM><BR>
|
|
<EM>> system this hardware is designed to work with ->GatesWare.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> On my old UW driver I use maximum 16K data blocks and no stops with Scanmaker II
|
|
</EM><BR>
|
|
<EM>> on a 60 Mz Pentium up to 300 dpi 24 bit A4 scans.
|
|
</EM><BR>
|
|
<EM>> BTW it seems to make problems in DMA transfer if the buffer goes over DMA
|
|
</EM><BR>
|
|
<EM>> bounderies
|
|
</EM><BR>
|
|
<EM>> depending on the ugly PC hardware design. So what do the low level drivers with a
|
|
</EM><BR>
|
|
<EM>> 256KB buffer.
|
|
</EM><BR>
|
|
<P>Wolfgang,
|
|
<BR>
|
|
What is happening when you specify a reserve buffer of 256 KB
|
|
<BR>
|
|
in Linux (or just ask to read that much data in one command)
|
|
<BR>
|
|
is that the sg driver fetches 8 chunks of 32 KB
|
|
<BR>
|
|
continuous memory (physical) and sets up a scatter gather
|
|
<BR>
|
|
list. These are kernel buffers which are managed by the sg
|
|
<BR>
|
|
driver. Now if the adapter driver
|
|
<BR>
|
|
is really doing DMA then that means the DMA logic has to
|
|
<BR>
|
|
be reconfigured up to 8 times during a "single" large
|
|
<BR>
|
|
transfer. The overhead that this introduces will vary between
|
|
<BR>
|
|
adapters but should be less than sending 8 commands each
|
|
<BR>
|
|
of 32 KB.
|
|
<BR>
|
|
<P>Next the data has to be transferred from the kernel buffers
|
|
<BR>
|
|
to the user space. Now the overhead of this "redundant"
|
|
<BR>
|
|
move is not as much as I thought. I have made some measurements
|
|
<BR>
|
|
and the results are in a web page:
|
|
<BR>
|
|
<A HREF="http://www.torque.net/sg/rbuf_tbl.html">http://www.torque.net/sg/rbuf_tbl.html</A>
|
|
<BR>
|
|
The sg driver in lk 2.4 has direct IO support but it is not
|
|
<BR>
|
|
what I would consider production quality so it is commented
|
|
<BR>
|
|
out pending some other work deeper down in the kernel.
|
|
<BR>
|
|
<P>None of this explains why a Windows configuration can do
|
|
<BR>
|
|
a scan up to twice as fast as one on a free OS such as Linux.
|
|
<BR>
|
|
As an example I found it strange that a Umax 1220S reports
|
|
<BR>
|
|
that it can do synchronous transfers in its INQUIRY (max
|
|
<BR>
|
|
10 MB/sec) but declines to negotiate synchronous transfers
|
|
<BR>
|
|
with my Advansys adapter limiting max transfer speeds
|
|
<BR>
|
|
to 3 MB/sec (perhaps its 5 MB/sec)). Perhaps the proprietary
|
|
<BR>
|
|
drivers for the supplied SCSI card know this, side step the
|
|
<BR>
|
|
standard, and configure for the higher transfer speed. [This
|
|
<BR>
|
|
is pure speculation on my part.]
|
|
<BR>
|
|
<P>As Abel Duering found time to scan is not a linear function
|
|
<BR>
|
|
of the amount of data coming back. Once the scanner mechanism
|
|
<BR>
|
|
has to stop, back track and restart several times during a
|
|
<BR>
|
|
scan, overall scan time can easily double.
|
|
<BR>
|
|
<P>Enough of my ramblings ...
|
|
<BR>
|
|
<P>Doug Gilbert
|
|
<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=<395C0080.1A82F22A@interlog.com>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0222.html">Petter Reinholdtsen: "SANE developers with write access to CVS"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0220.html">Francesco Anselmo: "Re[2]: Mustek A3SP (SCSI)"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0217.html">Wolfgang Rapp: "Re: scsi command queuing"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0227.html">Oliver Rauch: "Re: scsi command queuing"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0205.html">Henning Meier-Geinitz: "Re: scsi command queuing"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#221">[ date ]</A>
|
|
<A HREF="index.html#221">[ thread ]</A>
|
|
<A HREF="subject.html#221">[ subject ]</A>
|
|
<A HREF="author.html#221">[ 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 - 18:52:24 PDT</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|