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

From: rjh@world.std.com
Date: Thu Aug 16 2001 - 23:19:31 EDT

  • Next message: David Hollman: "Re: [PARPORT] Paride with Syquest EZ 230 causes "crash""

    On 16 Aug, Tim Waugh wrote:
    > On Thu, Aug 16, 2001 at 02:20:47PM -0400, Dave Strauss wrote:
    >
    >>> BTW, as far as I can tell Windows printer drivers effectively do this;
    >> they claim the parallel port for the duration of the data transfer and
    >> so are able to be somewhat more efficient in how and when they
    >> negotiate to ECP mode.
    >
    > Huh.
    >

    I've watched Windows ECP drivers rather extensively with logic
    analyzers. You find several things.

    First, there are much bigger differences than you would expect between
    the specialist replacement drivers and the original Microsoft Windows
    drivers. These are in part due to the substantial variations between
    different hardware implementations of parallel ports. Desktop systems
    are reasonably well behaved and complete. Laptops have some amazing
    gaps and deficiencies in their parallel implementations. The core of
    the difference is in the operating system overhead, not the wire
    manipulations.

    Second, many ECP devices are bi-directional and intolerant of peripheral
    sharing behavior. Most ECP devices do not tolerate a negotiation cycle
    during a block transfer. If they are expecting to send or receive a 1KB
    block, they do not tolerate any negotiation during the cycle. When they
    are bi-directional (e.g. use acknowledgement responses) they do not
    tolerate anything but ECP forward to ECP backward and vice versa.

    But negotiation is not all that big a timing issue once you have gone to
    efficient size block transfers. A Windows machine (and Linux too) will
    negotiate a mode in under 5 microseconds. I measured 2.2.18 ppdev and
    the wire time for negotiation was usually under 3 microseconds. This is
    not a significant overhead once your data transfers are reasonably
    large. The real overhead that you must watch is the internal OS system
    call and applications processing overhead. These will usually far
    exceed the 3 microseconds for negotiation on the wire. On the wire you
    see this as long delays between negotiations and the start of data
    transfers. That is one place where the replacement drivers outperformed
    Windows.

    R Horn

    -- 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 16 2001 - 23:32:42 EDT