# Re: scsi command queuing

From: abel deuring (a.deuring@satzbau-gmbh.de)
Date: Sun Jul 02 2000 - 10:10:11 PDT

- Next message: Oliver Neukum: "Re: can't recognize UMAX-VistaS6 on AHA1520b"
  - Previous message: Didier Galland: "can't recognize UMAX-VistaS6 on AHA1520b"
  - Next in thread: Oliver Rauch: "Re: scsi command queuing"
  - Reply: Oliver Rauch: "Re: scsi command queuing"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Oliver Rauch wrote:

  > > Or Perhaps the
  > > following happens: The Twain driver allocates a larger chunk of buffer
  > > memory, and then calls the ASPI layer several times. Perhaps the broken
  > > multitasking concept of Win95/98 is an advantage in this case: The SCSI
  > > commands probably don't need to be queued in a complex way as with
  > > Linux, so that it is easier to achieve a very short delay between the
  > > end of a SCSI command and the start of the next command. (An example for
  > > the downside of the Win95 concept: Copying larger files over a network
  > > for example causes 100% CPU load...)
  >
  > Possible. But I hope that this is not the only way to get good scanning speeds
  > with large images.

  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.

  > > With buffer sizes that large, the SG driver sometimes complained for me
  > > that it could not allocate the buffer. And the SG driver reserves only
  > > one buffer permanently (means, while the device file is open). If you
  > > queue more than one command, the SG driver dynamically allocates another
  > > buffer for each command. That can lead to swapping, or the queueing cail
  > > fail with ENOMEM.
  >
  > Ugh, sounds ugly. Would it be possible to ioctl() the number of static buffers
  > (add 1 or 2 static buffers at begin of scanning, reduce the number at the end),
  > would that help?

  That should help, but it would require a modified SG driver. Anyway, you
  can easily see in the debug output, if the ENOMEM error happens: If your
  get one of the sanei_scsi messages

  DBG(1, "issue: ENOMEM - cannot queue SCSI command. "
  "Trying again later.\n");
  or
  DBG(1, "issue: EAGAIN - cannot queue SCSI command. "
  "Trying again later.\n");
  a SCSI command could not be queued, because either the kernel could not
  allocate buffer memory (ENOMEM), or, for EAGAIN, the "SCSI mid-level
  [is] out of command blocks (rare), try again. This is more likely to
  happen when queuing commands, so wait a bit (eg usleep(10000) ) before
  trying again" (quoted from Douglas' documentation of the SG driver,
  http://www.torque.net/sg/p/scsi-generic_long.txt).

  >
  > > in most cases I would recommend smaller buffers.
  >
  > Hm, may be the buffer size should be calculated by the free/available memory.
  > If I scan a 200 MB image (I do not scan such images, but I know others do ;-) )
  > I expect that it takes a long time if I have only 64MB memory or below, but
  > with 128MB or better 256MB the scanning can work fast and that should also
  > be possible with SANE. So we _need to_ find a way to do this.

  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.

  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.)

  Abel

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Oliver Neukum: "Re: can't recognize UMAX-VistaS6 on AHA1520b"
  - Previous message: Didier Galland: "can't recognize UMAX-VistaS6 on AHA1520b"
  - Next in thread: Oliver Rauch: "Re: scsi command queuing"
  - Reply: Oliver Rauch: "Re: scsi command queuing"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sun Jul 02 2000 - 10:01:27 PDT