# Re: mustek aha1520B problems

Douglas Gilbert (dgilbert@interlog.com)
Mon, 05 Jul 1999 22:13:30 -0400

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Brian B.: "once more on the aha152x problem"
- Previous message: Juergen Scherer: "Microtek V600"
- Maybe in reply to: aanderson =: "mustek aha1520B problems"

"aanderson = (A.N. Anderson - Idaho Research Software)" wrote:
>
> >Douglas Gilbert <dgilbert@interlog.com> responded:
> >
> >Did the bigger buffers improve performance and lessen
> >the following problems?
> >
>
> To be honest I didn't see any difference, which is why I think
> think there are problems with the driver. The performance wasnt
> bad in either case, tho, except for the hangups and crashes, the
> latter of which typically occurred on large scans where improvement
> might have been more apparent. I was careful to get the buffer logistics
> right, altho I am suspicious that it seemed to crash more often with
> the large buffers..

Yes with the old driver bigger buffers
increased the probability of not being able to
find memory which led to an oops.

[snip]
> >
> >Time taken to DMA/block_move data to and from the SCSI device
> >and any polling that the aha152x driver does will _not_
> >show on a command prefixed with "time ".
> >
> I assumed the polling should show up under 'sys', but that there
> should still be lots of idle time between scsi commands.
> What concerned me more was that it seemed to keep on polling even after
> the scan stopped.

I should explain this a little more in reference to
the Linux sg driver. If data is being read from
the scanner it is first transferred to "dma"
kernel buffers then it is transferred from there to
the user buffer. This double handling is why this
approach is sometimes called indirect IO. The time
to do the first transfer is not registered against
the user (and is often done under interrupt
privilege). The second transfer (into the user space)
will show up as 'sys' time as you predicted.

Before people jump on me about the double handling,
it is not easy to implement direct IO under Linux
and only one driver that I am aware of does it: bttv.
The memory that you allocate for the direct DMA
transfer needs to be locked down while the transfer
is pending, this means not swapping out that part
of the app and not allowing it to be killed
amongst other things. Besides, Linus doesn't like
direct IO.

[snip]

Doug Gilbert

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Brian B.: "once more on the aha152x problem"
- Previous message: Juergen Scherer: "Microtek V600"
- Maybe in reply to: aanderson =: "mustek aha1520B problems"