abel deuring wrote:
> As far as my experiences go, the scan speed (mainly the number of the
> scan head stops) depends on quite a number of factors:
>
> - more or less broken scanner firmware
> - too tiny memory for the scanner's controller
> - slow responses by the host machine (backend; sanei_scsi layer; speed
> of the low level drivers)
Yes, but I compared it with th windows driver. That does scan some MB
and then the scanhead stops for a longer time. If I scan with sane the
scanhead stops after 256KB (size of the scanner internal image buffer)
whe I scan large images (on images up to 30 MB there is no problem).
So the scanner is able to send lots of buffers without stopping the scanhead
but not with SANE.
In both cases I use an NCR53c810 scsi adapter.
>
> "If": Well, the JX250 shows that command queueing works and can have
> some influence :) Regarding "how": sanei_scsi_open checks, how many
> commands can be queued by the Linux SCSI subsystem (there is a DBG
> statement showing this number). sanei_scsi_req_enter checks, if this
> queue is full; if it isn't, it sends the command to the SG driver, else
> it queues the command internally. sanei_scsi_req_wait wait for the
> oldest queueing command to finish; if there are any commands in the
> "sanei_scsi-internel" queue which not yet sent to the SG driver, they
> are sent, until the low level queue is again full, or the internal queue
> is completely sent.
Yes, waht I wanted to know is if the queueing is done in the scanner
on in the scsi adapter driver and that can not be found out with the
sanei_scsi debug messages.
(Doug helped me: the scanner does not support queueing, it is done in the driver).
>
> > If we talk about scanspeed we should think about extending the sg driver for
> > doublebuffering data pages in kernel memory space
> > and command block repeat count.
>
> Well, I think that the sanei_scsi_req_enter / sanei_scsi_req_wait
> mechanism should give similar results as command repeating, but the
> former is more flexible, because you can also sent some status inquiries
> or whatever between to "read data" commands.
>
Any ideas how we can test if sanei_scsI-req_enter is as fast as multiple reads in
the kernel?
>
>
> Now for a different idea. (If I'm going to talk nonsense, let me know.)
> If my memory is right, it is for example possible even with the ISA card
> aha1542 to issue SCSI commands with data blocks larger than 64 kB. Since
> the DMA block size for ISA cards is limited to 64 kB, this means that
> the kernel must organize more than one DMA transfer for one SCSI
> command. At present, these data are collected in a large buffer (or with
> scatter-gather, in several buffers), and and when a SCSI fommand
> finishes, all bytes are at once tranferred to the user memory. In other
> words, the machine must have enough memory to buffer the entire data
> block (or another copies, if DMA to user space is not possible). This
> sets some limit for the reasonable data block size of a SCSI command:
> the size should of course not be larger than the phyical memory
> installed; and since Unix is a multitasking OS, one should leave enough
> memory for other processes. Using data block sizes of more than a few
> hundred kB for SCSI commands is in my opinion a bad idea even on a
> workstation with 128 MB RAM or more.
Unbelievable, you are right: I just did a test with a scsi buffer that is greater
than the scanner internal image buffer and in fact the number of backtracks
is reduced (and the scanner does not stop after each buffer, it scans 4-5 buffers
before it stops).
I will play around a bit with that.
At least we can give the user the selection how much mem sane may use to scan.
And a 2MB Buffer should not too bad if it solves the backtracking problem.
Bye
Oliver
-- Homepage: http://www.wolfsburg.de/~rauch sane-umax: http://www.wolfsburg.de/~rauch/sane/sane-umax.html xsane: http://www.wolfsburg.de/~rauch/sane/sane-xsane.html E-Mail: mailto:Oliver.Rauch@Wolfsburg.DE-- 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 - 10:16:52 PDT