Re: scsi command queuing

From: Wolfgang Rapp (wolfgang@rapp-informatik.de)
Date: Wed Jun 28 2000 - 11:48:30 PDT

  • Next message: Gerald Teschl: "Mustek SE12000SP Plus"

    Oliver Rauch schrieb:

    > Hi,
    >
    > has someone experience with a sane backend and scsi command queueing?
    >
    > I am just working on it for the umax backend.
    >
    > At first I created some routines that replace the pipe to transfer the
    > data from the reader_process to the main process, it uses shared memory
    > instead (on systems where shared memory is available, otherwise the pipe is
    > used).
    >
    > Unfortunetly it does not speed up scanning large images. It really looks like
    > the comunication via the scsi bus is not fast enough.
    >
    > So I added scsi command queueing into the umax backend. But I am not
    > sure how I can see
    > 1) how/if it works (sanei_scsi debug output is not good enough)
    > 2) what I can do to speed up the comunication (it also does not help a lot).
    >
    > Any help is appreciated
    >

    I have done the UnixWare2 port of sane. Bofore this work I wrote a scanner
    driver for Microtek scanners for Unixware.
    I compared the scanning speed for A4 600x600 dpi full color scans with both
    sane and my Microtek solution.
    The sane scanning speed is much more slow then my singular solution . So whats
    the difference - I send a scsi command
    block along with a repeat faktor to a special kernel driver. The driver
    handles the whole scan internally without returning
    to the user programm. Original Unixes have a physio kernel funktion to lock
    user process in memory and the low level
    scsi drivers can send data direct to the user space even with dma mode . So a
    driver copy to user like in the linux kernel is also
    not necessary.
    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.
    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. But so all backends must be changed because not all could
    be done ins sane_scsi.

    Bye Wolfgang

    --
    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 - 10:38:46 PDT