kopia lustrzana https://gitlab.com/sane-project/website
248 wiersze
9.5 KiB
HTML
248 wiersze
9.5 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: backend fork/reader-process <-> sane_read</TITLE>
|
|
<META NAME="Author" CONTENT="abel deuring (a.deuring@satzbau-gmbh.de)">
|
|
<META NAME="Subject" CONTENT="Re: backend fork/reader-process <-> sane_read">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: backend fork/reader-process <-> sane_read</H1>
|
|
<!-- received="Mon Feb 21 06:00:23 2000" -->
|
|
<!-- isoreceived="20000221140023" -->
|
|
<!-- sent="Mon, 21 Feb 2000 14:31:05 +0100" -->
|
|
<!-- isosent="20000221133105" -->
|
|
<!-- name="abel deuring" -->
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|
<!-- subject="Re: backend fork/reader-process <-> sane_read" -->
|
|
<!-- id="38B13E19.66BA4C74@satzbau-gmbh.de" -->
|
|
<!-- inreplyto="38AED3DE.7A67A25D@wolfsburg.de" -->
|
|
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20backend%20fork/reader-process%20<->%20sane_read&In-Reply-To=<38B13E19.66BA4C74@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Mon Feb 21 2000 - 05:31:05 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0259.html">Lars Burgstahler: "Re: Epson Backend - The Millenium Release"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0257.html">Jens Scheithauer: "Re: New CVS snapshot 20000213"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0223.html">Oliver Rauch: "backend fork/reader-process <-> sane_read"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0262.html">Matto Marjanovic: "Re: backend fork/reader-process <-> sane_read"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0262.html">Matto Marjanovic: "Re: backend fork/reader-process <-> sane_read"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#258">[ date ]</A>
|
|
<A HREF="index.html#258">[ thread ]</A>
|
|
<A HREF="subject.html#258">[ subject ]</A>
|
|
<A HREF="author.html#258">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Oliver Rauch wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Hi,
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I though a bit about the way the most (all?) backends shift the data
|
|
</EM><BR>
|
|
<EM>> from the scsi buffer to the sane frontend:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> a fork creates a reader_process that gets the data from the scsi buffer
|
|
</EM><BR>
|
|
<EM>> and shall prepare it for sane_read. For that it writes it into a pipe.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> The main idea behind that is that sane_read() can be called with
|
|
</EM><BR>
|
|
<EM>> any request-size independent from the size of one scanline.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> But for the scanner we do it totally wrong here:
|
|
</EM><BR>
|
|
<EM>> we write the data into a pipe that's size is on most systems about 4KB.
|
|
</EM><BR>
|
|
<EM>> When the pipe buffer is full the write command does not return until
|
|
</EM><BR>
|
|
<EM>> it was able to write the data into the pipe buffer.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> So we try to press the scsi buffer data (32-128 KB) into a 4KB buffer
|
|
</EM><BR>
|
|
<EM>> what slows down scanning (creates a lot of pauses) and for that we create
|
|
</EM><BR>
|
|
<EM>> a second process that also needs lots of memory.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I think the pipe is the only reason why scanning large images with sane
|
|
</EM><BR>
|
|
<EM>> produces the backtracing of the scanhead and makes scanning very slow.
|
|
</EM><BR>
|
|
<P>That the write() to the pipe blocks, can indeed be an important reason
|
|
<BR>
|
|
for scanhead stops. But some scanners are even more "sensitive": The
|
|
<BR>
|
|
Sharp JX250 for example needs a "read data" command be sent as fast as
|
|
<BR>
|
|
possible to the device after the previous command has been finished in
|
|
<BR>
|
|
order to avoid scan head stops. For that reason, the Sharp backend uses
|
|
<BR>
|
|
the functions sanei_scsi_req_enter and sanei_scsi_req_wait. While the
|
|
<BR>
|
|
implementation of these functions in Sane 1.0.1 helped to avoid scan
|
|
<BR>
|
|
head stop in many situations, it was not fast enough under certain
|
|
<BR>
|
|
conditions (slower host processors and/or higher scan resolutions).
|
|
<BR>
|
|
Speeding up the implementation of these functions by using the queueing
|
|
<BR>
|
|
capabilities of the newer version of the Linux SG driver avoided scan
|
|
<BR>
|
|
head stop under most circumstances.
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> What can we do?
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I see two possibilities.
|
|
</EM><BR>
|
|
<EM>> 1) We do not write the data into a pipe. Instead we write it into a file.
|
|
</EM><BR>
|
|
<EM>> The disadvantage is that we have to store the image twice while scanning.
|
|
</EM><BR>
|
|
<EM>> The advantage is that a slow frontend (e.g. network scanning) does not
|
|
</EM><BR>
|
|
<EM>> slow down the scan speed (Backtracking is very slow).
|
|
</EM><BR>
|
|
<P>Using a file for buffering, is indeed kind of "last resort". But we can
|
|
<BR>
|
|
leave this for example to Brian's patch to saned. I tried it with the
|
|
<BR>
|
|
Sharp backend, and it works very good.
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> 2) We work with two buffers that have the same size as the scsi buffer
|
|
</EM><BR>
|
|
<EM>> (in the moment we use one of these buffers). sane_read reads the data from
|
|
</EM><BR>
|
|
<EM>> the one buffer while the other buffer is filled with the scsi/scanner data.
|
|
</EM><BR>
|
|
<EM>> As far as I can see the memory usage is not greater than in the moment
|
|
</EM><BR>
|
|
<EM>> because the existing fork already produces a second buffer of 32-128KB,
|
|
</EM><BR>
|
|
<EM>> but only one of the two buffers is needed/used at a time.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> There are 2 ways to do this
|
|
</EM><BR>
|
|
<EM>> a) a forked reader_process writes the data into shared memory
|
|
</EM><BR>
|
|
<EM>> (this does not work on all systems, on other systems where no shared memory
|
|
</EM><BR>
|
|
<EM>> is available we could keep the pipe or b:).
|
|
</EM><BR>
|
|
<EM>> b) there is no own reader process, the backend itself calls sanei_scsi_read()
|
|
</EM><BR>
|
|
<EM>> when one buffer is empty. This is a bit slower but does not need shared memory.
|
|
</EM><BR>
|
|
<EM>> I am not sure if the scanning really slows down when we do not use an own reader process.
|
|
</EM><BR>
|
|
<EM>> All we need is a sanei_scsi_read routine that is able to do non-blocking (returns if no data is available).
|
|
</EM><BR>
|
|
<EM>> The coping the scsi buffer in the backend buffer does not take much time if the routine does not
|
|
</EM><BR>
|
|
<EM>> wait until data is available.
|
|
</EM><BR>
|
|
<EM>> If this works like I expect we do not need any fork or thread.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> All this could be hidden in a sanei_ routine so the backend does not see anything about that.
|
|
</EM><BR>
|
|
<EM>> So a backend would not call sanei_scsi_read(), instead it would call sanei_scsi_read_buffered().
|
|
</EM><BR>
|
|
<P>I think, sanei_scsi_read_buffered() should also allow command queueing.
|
|
<BR>
|
|
In fact, the command queueing has even without a function like
|
|
<BR>
|
|
sanei_scsi_read_buffered() similar capabilities. I suspect that the
|
|
<BR>
|
|
Sharp backend is a little bit "over-tuned" for Linux: It forks a reader
|
|
<BR>
|
|
process, uses command queueing _and_ shared memory. I left it in this
|
|
<BR>
|
|
state mainly, because real command queueing with the Sane SCSI API is at
|
|
<BR>
|
|
present only available for Linux, so that other OS can least profit for
|
|
<BR>
|
|
the fact, that reader process does not need much time to forward the
|
|
<BR>
|
|
data to the parent process. But it would be worth to try to remove the
|
|
<BR>
|
|
reader process, but to keep command queueing. I was simply too lazy to
|
|
<BR>
|
|
try that, but could do it -- but that might take some time (quite much
|
|
<BR>
|
|
other work to do during the next weeks...).
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> May be it would be a good idea to implement both (or all three with the exisiting) routines
|
|
</EM><BR>
|
|
<EM>> and let the user select the routine that works best for him.
|
|
</EM><BR>
|
|
<P>That could result in a quite complicated configuration -- your proposals
|
|
<BR>
|
|
are not mutually exclusive :)
|
|
<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:%20backend%20fork/reader-process%20<->%20sane_read&In-Reply-To=<38B13E19.66BA4C74@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0259.html">Lars Burgstahler: "Re: Epson Backend - The Millenium Release"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0257.html">Jens Scheithauer: "Re: New CVS snapshot 20000213"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0223.html">Oliver Rauch: "backend fork/reader-process <-> sane_read"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0262.html">Matto Marjanovic: "Re: backend fork/reader-process <-> sane_read"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0262.html">Matto Marjanovic: "Re: backend fork/reader-process <-> sane_read"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#258">[ date ]</A>
|
|
<A HREF="index.html#258">[ thread ]</A>
|
|
<A HREF="subject.html#258">[ subject ]</A>
|
|
<A HREF="author.html#258">[ 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>Mon Feb 21 2000 - 06:01:11 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|