Wolfgang Rapp wrote:
>
> But I think the most bottlenek is the interaktion between backends and kernel
> after every scsi-command. This interaction time by
> system calls , kernel scheduling etc. at this time is to long to keep the
> scanner running, the next scan command block should be send
> by the driver if it receives the completion interrupt from the last.
Hi Wolfgang,
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).
>
> 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. Filling one buffer by dma from scsi hardware
> and coping in parallel the other out to the user
> space instead of waiting for interrupts. My somebody have looked more to the
> linux sg driver source code then I and knows more
> about how it works.
Hi Dough,
any comments?!
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 : Wed Jun 28 2000 - 15:11:02 PDT