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

Wed Jun 8 06:55:06 UTC 2011

Pete Lancashire <pete at petelancashire.com> writes:

> 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,

That's 214,812,000 bytes / 15.21 seconds = 14,123,076 bytes/sec, or
about 14.1MB/s.  How much closer to 20MB/s are you trying to get?

> 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

You may also want to bug the sanei_scsi.c maintainer, but note that the
epkowa backend uses an old version of that file (from 1.0.12 IIRC).  If
there's anything in that file that got fixed in a later sane-backends
version, the epkowa did not get that fix.

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

The speed option basically determines whether you want to do a draft
mode can yes or no.  Now I have no idea what's going on in the device
and what's different between the two but I could come up with one or two
plausible scenarios for that.  One involves less bits per pixel in the
raw data acquired, hence room for more pixels in device memory, in draft
mode.  Another involves bypassing of post-processing options that 
delays pixels becoming ready for transfer to the PC or eating up device
memory so that less data can be buffered.

Just speculating though.

BTW, top posting is like putting the cart before the horse ;-P

> 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