Oliver Rauch wrote:
> Yes, but I compared it with th windows driver. That does scan some MB
> and then the scanhead stops for a longer time. If I scan with sane the
> scanhead stops after 256KB (size of the scanner internal image buffer)
> whe I scan large images (on images up to 30 MB there is no problem).
Perhaps the Windows driver simply allocates 10 MB or so as buffer
memory, and issues just one read read command for it... 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...)
> So the scanner is able to send lots of buffers without stopping the scanhead
> but not with SANE.
>
> In both cases I use an NCR53c810 scsi adapter.
That's probably not the worst choice.
> > Well, I think that the sanei_scsi_req_enter / sanei_scsi_req_wait
> > mechanism should give similar results as command repeating, but the
> > former is more flexible, because you can also sent some status inquiries
> > or whatever between to "read data" commands.
> >
>
> Any ideas how we can test if sanei_scsI-req_enter is as fast as multiple reads in
> the kernel?
Difficult question; I don't know, if or how it is possible to issue
multiple reads for the Linux kernel. But my guess is, that those
multiple reads would have to be queued just like several SCSI commands
being sent via sanei_scsi_req_enter and a write to the SG device file.
(Douglas, any comments?)
[larger block sizes]
> Unbelievable, you are right: I just did a test with a scsi buffer that is greater
> than the scanner internal image buffer and in fact the number of backtracks
> is reduced (and the scanner does not stop after each buffer, it scans 4-5 buffers
> before it stops).
>
> I will play around a bit with that.
>
> At least we can give the user the selection how much mem sane may use to scan.
> And a 2MB Buffer should not too bad if it solves the backtracking problem.
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. sanei_scsi.c handles this case, but then the low level
queueing is not used, and you end up again with longer delays between
two commands. Therefore I think that buffers of that size are fine for
testing and probably also on an only lightly loaded machine with enough
memory installed, but in most cases I would recommend smaller buffers.
Abel
-- 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 : Fri Jun 30 2000 - 05:30:22 PDT