abel deuring wrote:
>
>
> I hope it too :) But, considering the discussion in this thread, it
> seems that very short delays between two SCSI commands or huge buffers
> are for many scanners the only ways to avoid scan head stops.
>
The problem is that with large buffers and driver (not adapter) queue commands
the scanhead does stop when the size of the scanner internal buffer is transmitted.
So it looks like a response time problem of the low level scsi driver.
>
> DBG(1, "issue: EAGAIN - cannot queue SCSI command. "
> "Trying again later.\n");
>
No such mesages.
>
>
> I think that at least some choice of the buffer size should be left to
> the user: You can never know what kind of programs and how many of them
> somebody might run at the same time on her/his Linux box. and which
> priority the scanner usage has: If the backend fights too hard for
> memory, this might cause a serious slowdown of other, perhaps more
> important, programs, because their memory content is written to the swap
> disk.
Yes.
>
>
> But "memory policies" aside, you are right, we must find a way to avoid
> scan head stops. But I don't see many options without messing in the
> Linux kernel. At least, I don't see any way to speed things more up than
> to use command queueing and more or less big buffers without asking for
> faster kernel responses or new ioctls, like the idea to implement
> something similar to piping for the handling of really large SCSI read
> commands. (And the latter can be really dangerous: If we have a scanner
> that is unable to do a SCSI disconnect, and a disk, to which the image
> data should be written, connected to the same SCSI bus, there no way to
> get access to the disk while the scan is running.)
>
I already played a bit with some kernel options/changes.
So I tested forced sync and forced command queueing
(the scanner says both are not possible but some devices
that the can not do this although the really can), but this
did not change anything as far as I tested yet.
So the next thing will be to play around with the sg or the low level scsi driver.
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 : Sun Jul 02 2000 - 14:32:17 PDT