Douglas Gilbert wrote:
>
> Most scsi scanners do not support disconnect or tagged queuing
> so you are not going to get much benefit from async io. Abel
> Deuring has done some work in this area and did get some
> timing improvements on Linux. I think scsi commands were
> probably queued up at the HBA and thus got out to the
> scanner quicker after it finished the previous command
> (compared with having to go up through the scsi layers,
> out to the app and back down again). Abel used non blocking
> techniques rather than POSIX threads, I think. [I have used
> POSIX threads to do async IO on high end disks with good
> results (compared with the standard dd command).]
>
> There seems to be a non-linear effect with scanners. You have
> a time window to get the next "read" out to the device after
> the previous one has finished. If the window is missed the
> scan stops, the mechanism backs up a little and recommences.
> A small change in the speed the next command gets out to the
> scanner can mean the difference between a slow, jerky scan
> and one continuous pass.
>
Douglas,
I agree, that the small time window for sending a "read" command after
finishing the previous read and not having the scan head stop is indeed
the main cause for scan heads stops -- at least for the Sharp JX250. And
using SG level queueing together with larger buffers avoids nearly all
scan head stops. That was the main reason for me to modify sanei_scsi.c
so that the features of the newer version of the Linux SG driver can be
used.
But the Sharp backend also forks a reader process. This was one of my
first attempts to avoid scan head stops, and it was, combined with
queueing on the level of the sanei_scsi.c layer, also to some extent
successful. I am not sure, what would happen, if I would throw away the
reader process and implement queueing inside the main process. With the
recent versions of the Linux SG driver, scan head stops would probably
no longer occur, but since command queueing is implemented in
sanei_scsi.c only for Linux, I kept the reader process.
I do not know Ingo's reasons to consider to use either fork() or Posix
threads in his backend. But if scan head stops occur for his scanner,
using either of these techniques might be reasonable, simply because
they work not only for Linux.
Abel
-- 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 Feb 03 2000 - 10:56:21 PST