Wolfgang Rapp wrote:
>
> Oliver Rauch schrieb:
>
> > if I do not send the image data from the reader_process to the main process
> > (only send read commands to the scsi bus) the scanning speed is not increased.
> > So I also think it is a problem between sanei_scsi, the sg driver and the kernel
> > lowlevel scsi driver. In sanei_scsi there also is a not really necessary memcpy
> > command but I do not think that this command does make the problem.
> >
> > A bit strange is that it does not make any differences if I use 32 KB or 256KB
> > for the read command buffer (The scanner has 256KB internal image data).
> >
> >
>
> Moin Oliver
> Yes this shows that the scan commands must be send very fast to have no
> stops - because the firmare of the scanners have the same quality as the
> system this hardware is designed to work with ->GatesWare.
>
> On my old UW driver I use maximum 16K data blocks and no stops with Scanmaker II
> on a 60 Mz Pentium up to 300 dpi 24 bit A4 scans.
> BTW it seems to make problems in DMA transfer if the buffer goes over DMA
> bounderies
> depending on the ugly PC hardware design. So what do the low level drivers with a
> 256KB buffer.
Wolfgang,
What is happening when you specify a reserve buffer of 256 KB
in Linux (or just ask to read that much data in one command)
is that the sg driver fetches 8 chunks of 32 KB
continuous memory (physical) and sets up a scatter gather
list. These are kernel buffers which are managed by the sg
driver. Now if the adapter driver
is really doing DMA then that means the DMA logic has to
be reconfigured up to 8 times during a "single" large
transfer. The overhead that this introduces will vary between
adapters but should be less than sending 8 commands each
of 32 KB.
Next the data has to be transferred from the kernel buffers
to the user space. Now the overhead of this "redundant"
move is not as much as I thought. I have made some measurements
and the results are in a web page:
http://www.torque.net/sg/rbuf_tbl.html
The sg driver in lk 2.4 has direct IO support but it is not
what I would consider production quality so it is commented
out pending some other work deeper down in the kernel.
None of this explains why a Windows configuration can do
a scan up to twice as fast as one on a free OS such as Linux.
As an example I found it strange that a Umax 1220S reports
that it can do synchronous transfers in its INQUIRY (max
10 MB/sec) but declines to negotiate synchronous transfers
with my Advansys adapter limiting max transfer speeds
to 3 MB/sec (perhaps its 5 MB/sec)). Perhaps the proprietary
drivers for the supplied SCSI card know this, side step the
standard, and configure for the higher transfer speed. [This
is pure speculation on my part.]
As Abel Duering found time to scan is not a linear function
of the amount of data coming back. Once the scanner mechanism
has to stop, back track and restart several times during a
scan, overall scan time can easily double.
Enough of my ramblings ...
Doug Gilbert
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Thu Jun 29 2000 - 18:52:24 PDT