[sane-devel] Gt-30000 and epkowa - Was Fwd: sanner still jogs - more buffering ?

Wed Jun 8 04:40:34 UTC 2011

with the change made below, and setting the SANE_SG_BUFFER_SIZE to 1 Meg
the scanner jogs 2 times and takes 15.21 (avg of 3 passes) seconds,
the max I can
set it to is 1,347,071 one more byte and it crashes with

sanei_scsi.issue: 0x17a6130
sanei_scsi.issue: bad write (errno=12) Cannot allocate memory -1
sanei_scsi.issue: SG_BIG_BUF inconsistency? Check file PROBLEMS.

sane_read: Out of memory

I'm going to hit up the sg maintainer about why /proc/scsi/sg/def_reserved_size
keeps getting put back to 32K

other tidbits

with speed=no scan time is consistently just over 17 seconds

with resolution=300 and speed=no the scanner jogs once with speed=yes
(and not a typo) it is
much faster and does NOT jog. That one has me really confused.

going to download the kernel sources etc .. for future fun.

I may also for grins build this server as a Ubuntu setup and see what happens.

-pete

On Tue, Jun 7, 2011 at 6:11 PM, Olaf Meeuwissen
<olaf.meeuwissen at avasys.jp> wrote:
> Please keep this on the mailing list.  That way it will get archived and
> be searchable for everyone.
>
> Pete Lancashire <pete at petelancashire.com> writes:
>
>> Here's the logs and some more information
>
> Your logs indicate that the epkowa backend is not limiting the size of
> its internal buffer to 32kb, so that shouldn't be the issue.
>
> If you want to make real, real sure, modify the epkowa backend source
> code at the end of backend/channel-scsi.c to read
>
>  static size_t
>  channel_scsi_max_request_size (const channel *self)
>  {
>    size_t max_request_size = sanei_scsi_max_request_size;
>    if (getenv ("SANE_SG_BUFFERSIZE"))
>      {
>        max_request_size = atoi (getenv ("SANE_SG_BUFFERSIZE"));
>      }
>    return max_request_size;
>  }
>
> and set the SANE_SG_BUFFERSIZE to, say, 1MB.
>
>> I only got a chance to test a few things last night
>>
>> the log you requested is attached as scsi-debug.log, the other log
>> file called just log is debug set at 4 and with SANE_SG_BUFFERSIZE set
>> to 1048576 ( 1 meg), the size changed in the log file, but not to 1
>> MB. I did not try making the SANE_SG_BUFFERSIZE bigger, ran out of
>> time.
>>
>> Another non sane/epokwa issue is when I set
>> /proc/scsi/sg/def_reserved_size to 1048576 anytime i run scanimage it
>> resets back to 32768. Not sure what is going on there. I did not have
>> time to try a smaller size.
>
> No clues on that here either.
>
>> On a side note I've got a ticket open with Epson, basically all the
>> literature on the GT-30000 says that its SCSI interface supports
>> SCSI-2 and SCSI-3.
>
> The specs on www.epson.com say that "SCSI: Requires ASPI-compliant
> compatible SCSI 2 or SCSI 3 PCI card and cable (not included)".  My
> interpretation of that is that you can connect it to a SCSI-3 card and
> it'll work, not that it'll necessarily work at SCSI-3 specifications,
> let alone at the (theoretical) maximum band width.
>
>> Going by the response from support, it is now confirmed the interface
>> is SCSI-2 ONLY and that using the wide connector the maximum (raw my
>> word) data rate is 20 MBytes per second, and thats a Megabyte being
>> 1,000,000 bytes. SCSI-2 is based on a 10 Megahertz clock so the real
>> raw rate for a wide port is 20,000,000 bytes per second. The scanner
>> in color mode is suppose to do 0.79 milliseconds per line or 9.079
>> seconds per page.
>
> I only get to 8.058 seconds per page (and you did too, earlier).
> 17 inches at 600 dpi with 0.79ms per line.
>
>> A full page at 600 dpi, color is 214,812,000 bytes, which is
>> 23,662.921 bytes per seconds, the interface is a maximum of 20,000,000
>> bytes per seconds.
>
> For the record, you are referring to an 8-bit RGB scan of the maximum
> available scan area (11.7x17 in^2), right.
>
> I get 26,658,227 bytes per second (at 8.058 seconds per page and
> 23,660,315 at 9.079).  Assuming that . is a typo ;-) Seeing that the max
> SCSI-3 throughput is 20MB/s, you can't do any better than 214,812,000
> bytes at 20MB/s is 10.740 seconds per page in getting images to your
> computer.  Since you observe jogging several times per page (what
> size?), obviously, transfers are going a fair bit slower than the max.
>
> In private mail you mentioned that total scan times at 600dpi was
> between 16 and 20 seconds, with and without speed=yes and that the
> scanner jogs three or four times with speed=yes.  That clearly indicates
> that the scan is speed-limited by the image data transfer.  Based on
> your timings you're getting between 10.7 and 13.4 MB/s, which is above
> the maximum band width for Fast SCSI interfaces but well below that for
> Fast-Wide SCSI and Ultra SCSI[1].
>
>  [1] http://en.wikipedia.org/wiki/SCSI#Parallel_SCSI
>
>> Not good, both from a technical standpoint but if this is the issue,
>> well .. i really hope this is not an issue, since I recommended quite
>> a few GT-30000's and well may have those that were bought returned.
>>
>> thanks for all the help so far !!
>
> Sorry that this is of not much help.
> --
> Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
> FSF Associate Member #1962               Help support software freedom
>                 http://www.fsf.org/jf?referrer=1962
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>             to sane-devel-request at lists.alioth.debian.org
>