Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!inferno.mpx.com.au!nsw1.news.telstra.net!wa.news.telstra.net!news.telstra.net!news-out.internetmci.com!newsfeed.internetmci.com!swrinde!howland.erols.net!feed1.news.erols.com!dispatch.news.demon.net!demon!arg1.demon.co.uk!arg-home1.net-tel.co.uk!nobody From: Andrew Gordon <andrew.gordon@net-tel.co.uk> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Query: PLIP connection. Date: Tue, 25 Mar 1997 19:22:54 +0000 Message-ID: <3338260E.2781E494@net-tel.co.uk> References: <33369B7E.41C67EA6@sees.bangor.ac.uk> <5h75qb$ta@uriah.heep.sax.de> <5h8lu2$mpm@hecate.umd.edu> NNTP-Posting-Host: arg1.demon.co.uk X-NNTP-Posting-Host: arg1.demon.co.uk X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 27 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37884 Marat Fayzullin wrote: > Now, to the more important question: when will it be possible to limit > amount of CPU time taken by PLIP driver? Doing direct transfer between the > gateway and the PLIPped host now takes 100% of CPU time, meaning > everything else hangs on both these machines. It becomes a little bit > easier when you run some high-CPU-consumption program (GCC or an > interpreting emulator of another computer do just fine) concurrently with > the transfer, but is there a decent way to control that? No, this is a fundamental limitation of the hardware/protocol. You could in principle take an interrupt on each byte, which would reduce the CPU overhead on fast machines talking to slow ones, but would make the throughput much slower in all cases and probably use more CPU with two similar speed machines talking to each other. One potential way forward is to re-write the driver to take advantage of bidirectional/EPP/ECP ports (ECP in particular has the potential to be quite efficient), but this would be quite a lot of work and the cables/protocols would not be compatible with what we have today. Since one of the main advantages of the existing PLIP stuff is that it can be used on almost any PC for emergency/low volume use, and that Ethernet cards are so cheap for any permanent connection, it hardly seems worth the trouble of implementing a more efficient mode that works only between pairs of ECP-equipped machines.