Re: [PARPORT] ECP mode transfers in 2.4.x kernels

From: Dave Strauss (
Date: Wed Aug 22 2001 - 16:06:31 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] ECP mode transfers in 2.4.x kernels"

    I've been playing with my newly-speeded up parallel port (with
    CONFIG_PARPORT_PC_FIFO enabled) and I'm getting some interesting
    performance results. I've downloaded and timed a 3 MByte test file to
    two different printers with the results shown in the table below.


    Printer A has a faster CPU than Printer B.

    "Stock installation" is the Redhat 7.1 distribution. Note that this
    distributions does *not* have parallel port DMA support turned on.

    "Stock lp.c, DMA enabled" means that the parport module (parport.o)
    was built with DMA support turned on.

    "ECP w/DMA config 1" was built with parport DMA support on, and has
    the lp.c patches discussed earlier in this thread. These patches
    cause ECP mode transfers to be used if the IEEE1284 ID from the
    printer indicates that the printer can support it. The port is
    switched into and out of ECP mode on every "write" (each call to

    "ECP w/DMA config 2" was built with parport DMA support on, and has a
    set of lp.c patches which cause the parallel port to be switched into
    ECP mode when the lp driver is opened (during the call to lp_open())
    and left in ECP mode until the lp driver is closed (during the call to
    lp_release()) [do not try this at home!]

                 Stock Stock lp.c, ECP w/DMA, ECP w/DMA,
                 installation DMA enabled config 1 config 2
    Printer A | ~66 KB/sec | ~330 KB/sec | ~280 KB/sec | ~330 KB/sec |
    Printer B | ~48 KB/sec | ~280 KB/sec | ~280 KB/sec | ~330 KB/sec |

    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. 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.

    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.

    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?

    -- Dave Strauss

    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Wed Aug 22 2001 - 16:09:48 EDT