From owner-freebsd-hackers  Tue Jul  9 08:50:13 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA17260
          for hackers-outgoing; Tue, 9 Jul 1996 08:50:13 -0700 (PDT)
Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA17223
          for <hackers@freebsd.org>; Tue, 9 Jul 1996 08:49:53 -0700 (PDT)
From: Andrew.Gordon@net-tel.co.uk
Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id QAA19827 for hackers@freebsd.org; Tue, 9 Jul 1996 16:49:12 +0100
Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk
        (Route400-RFCGate); Tue,  9 Jul 96 16:44:45 +0100
X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; 
        Relayed; Tue,  9 Jul 96 16:44:45 +0100
X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";
         Relayed; Tue,  9 Jul 96 15:44:44 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; 
        Tue,  9 Jul 96 15:44:44 +0000
X400-MTS-Identifier: 
        ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:4758-960709154444-076B]
X400-Content-Type: P2-1984 (2)
X400-Originator: Andrew.Gordon@net-tel.co.uk
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: hackers@freebsd.org
Date: Tue,  9 Jul 96 15:44:44 +0000
X400-Content-Identifier: Re: Fwd: Paralle
Message-Id: <"11605-960709154831-76DC*/G=Andrew/S=Gordon/O=NET-TEL
 Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>
To: hackers@freebsd.org
In-Reply-To: <31E1DB6C.167EB0E7@FreeBSD.org>
Subject: Re: [Fwd: Parallel laplink abuse leads to death of kernel
        secondary timer]
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Yow, this one's pretty cool! :-)  I guess we always knew that PLIP was a
> high-overhead proposition, but it's interesting to see that it only
> croaks on the Pentium.

However, most Pentium systems are new enough to have ECP-capable parallel ports, which could in principle give a much lower overhead if someone had the time to work on the driver....

Note that with the current driver, the overhead will be maximised with two systems of very different performance talking to each other, since the fast system will spend lots of time in a busy loop waiting for the other to respond.