On Wed, 22 Aug 2001 23:09:07 +0100, Tim Waugh <twaugh@redhat.com> wrote:
>
> 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.=20
>
> 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'.
>
I don't know of any printers that have implemented ECP RLE mode, nor
any Windows printers drivers that try to use it. I was just surprised
that compatibility mode could go so fast.
> > 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 may or may not help, depending on how big the chunks are that get
passed into lp. If the application is sending things in small pieces,
increasing LP_BUFFER_SIZE isn't going to help much.
> > 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. =20
>
> 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.
>
Do you mean the "preempt" in the parport device structure? So, lp
would claim parport on lp_open(), put it into ecp mode, and leave it
both claimed and in ecp mode until lp_release(). Is that what you
mean? One problem -- can't the preempt function get called at any
time? What if it gets called in the middle of a data transfer (or in
the middle of any other lp entrypoint, for that matter)?
> > 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>).
>
Same results, which isn't surprising since it uses the same underlying
code to read the ID data.
> 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 : Thu Aug 23 2001 - 10:23:48 EDT