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

Pete Lancashire pete at petelancashire.com
Wed Jun 8 16:53:32 UTC 2011


Let me add to what I said

> Will 15 to 17 seconds work, yes. but 85% to 120% slower then advertised
> really hurts when ones ability to win contracts is based on ones reputation.

I was asked to come up with a solution to scanning documents. I 'sold' the
idea of using Linux and the GT-30000. I selected the GT-30000 based on two
things, the first from talking to users for their opinion of
reliability, my personal
experience with Epson scanners and finally on the published specifications for
performance  I'll toss in that Epson (at least the scanner group) supports
Linux via Sane.

10 vs 17 seconds may not sound like much, but when one is looking at over
100,000 documents it adds up pretty fast.

On Wed, Jun 8, 2011 at 8:16 AM, Pete Lancashire <pete at petelancashire.com> wrote:
> My goal is something close to the advertised speed (8.058 seconds per page).
> I would be happy with say 10 seconds which is 24% slower. Would be OK at
> say 12 seconds which is almost 50% slower.
>
> Will 15 to 17 seconds work, yes. but 85% to 120% slower then advertised
> really hurts when ones ability to win contracts is based on ones reputation.
>
> It is a pity the electronics in the GT-30000 are a bit 'old'. What
> would make this
> pretty much the perfect scanner would be a new board with 1-2 GB of RAM and
> a 1,000 MB/s Ethernet interface. Today building a dedicated controller costs no
> more to have 1 GB then 128 MB. The last design I did using a single
> commodity DDR-2 (or 3) memory module  plus its connector cost less then
> 512 MB of non commodity memory. 1,000 MB/s Ethernet today is basically free.
> The only thing I would change in the scanner deck is from a CFL to LEDs.
>
> Call it the GT-3E5 (GT-300000) and Epson would have a winner.
>
> -pete
>
> PS Many years ago I worked for a company under Seikosha and the mechanical
> part of our product was made by Epson.
>
>
>
>
>
> 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



More information about the sane-devel mailing list