On Wed, Aug 22, 2001 at 04:06:31PM -0400, Dave Strauss wrote:
> There are a couple of interesting things about these results. First,
> most of the performance gain comes from turning on DMA support on the
> host and not from using ECP mode.
We don't do RLE. That's probably why. If we did RLE then the ECP
result would stand a chance of being faster than DMAing in 'printer
mode'.
> Second, cutting down on the number
> of negotiations into and out of ECP mode (going from config 1 to
> config 2) is worth an extra 50 KB/sec or so, at least in this mix of
> hosts and printers.
Up the LP_BUFFER_SIZE. It's that much slower because we're capping
the amount transferred per write to one page. (Duh!) I can't remember
exactly why we did that (maybe just arbitrary), but it's obviously
hurting here.
> This second result implies that if we want to get any benefit from ECP
> mode in the lp driver we need to cut down the number of negotiations
> into and out of ECP mode. The only real way to do this (that I can
> see) is to do what I did in config 2 -- put the port into ECP mode
> when lp is opened, and leave it there until lp is closed. However
> this can cause problems with other drivers which expect the port to be
> in kept in compatibility mode.
Going for this approach can work. If lp declares a 'kick' function at
registration time, it can get told to let go of the port.
> On a semi-related note, the "probe" code in the parport driver
> cannot read the IEEE1284 ID from Printer A, even though Windows
> boxes have no problem with it. Has any work been done on this code
> lately?
No, I don't think so. What does deviceid make of it?
(<URL:ftp://people.redhat.com/twaugh/parport/deviceid-0.3.tar.gz>).
Tim.
*/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Aug 22 2001 - 18:10:36 EDT