abel deuring wrote:
>
> Perhaps the Windows driver simply allocates 10 MB or so as buffer
> memory, and issues just one read read command for it...
That is what I think,
but while it looks that for the UMAX PowerLookIII this sometimes works
under sane, for the UMAX Supervista S12 I get (with SANE 600dpi A4) a
backtrack each time the scanner internal image buffer is transfered, on windows
not.
> 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.
>
> > 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.
I know :-)
>
> >
> > 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]
What happens when a backend starts a read command with a buffer
larger than the scanner internal image buffer. Can someone (Douglas?)
explain how this is done on the scsi bus and with DMA?
> 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?
> 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.
That could explain why I did not see any improvements when I made some tests
afterwards. Looks like it is not a safe way to icnrease scanning speed.
Bye
Oliver
-- Homepage: http://www.wolfsburg.de/~rauch sane-umax: http://www.wolfsburg.de/~rauch/sane/sane-umax.html xsane: http://www.wolfsburg.de/~rauch/sane/sane-xsane.html E-Mail: mailto:Oliver.Rauch@Wolfsburg.DE-- 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 - 07:51:56 PDT