Re: scsi command queuing

From: Oliver Rauch (oliver.rauch@Wolfsburg.DE)
Date: Fri Jun 30 2000 - 08:03:33 PDT

  • Next message: Oliver Rauch: "Re: scsi command queuing"

    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.

    I had two different ideas:
    1) do read commands with the half size of the scanner image buffer.
    That way the scanner can/could use the other half of the buffer to store
    just scanned image data. The program only needs to be fast enough that
    the read command is finished before the second half of the scanner internal
    image buffer is filled.
    does not improve anything. May be the scanners are too stupid to use their image buffer
    as ring buffer.

    2) do read commands with multiple size of the scanner image buffer.
    As described abouve I do not know how this works on the scsi bus.
    But may be the scanner is able to send the data in small blocks and keep
    the internal buffer as free as possible.
    also does not improve scanning speed in most cases. In the first time
    I tested it it looked much faster, may be it was a psycological effect, may
    be it really was faster ... don't know.

    So after all it really looks like a problem in the linux kernel that possibly may not
    be solved in a multi tasking environment like linux. But we should find out if it is possible
    to improve it.

    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 : Fri Jun 30 2000 - 07:51:26 PDT