Date: 15 Jul 1998 17:31:11 +0200 From: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: hackers@FreeBSD.ORG Subject: Re: Losing clock interrupts Message-ID: <rx4n2abuo5c.fsf@oslo.geco-prakla.slb.com> In-Reply-To: Peter Jeremy's message of Wed, 15 Jul 1998 22:12:20 %2B1000 (EST) References: <199807151212.WAA23486@gsms01.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peter.jeremy@alcatel.com.au> writes: > I'm running parallel IP between a 486 DX2-50 and a 386SX-25. Both > systems have IDE disks. I find that network-intensive activities are > causing clock interrupts to be lost. Dropping the MTU helps, but has > adverse effects on the throughput (admittedly the system's own > calculated throughput looks very good when the clock is basically > stopped). We know. You will find links to previous PRs about this problem, as well as patches which almost (but not quite, according to Bruce Evans) fix the bug at <URL:http://www.stud.ifi.uio.no/~dag-erli/?software>; The audit trail for one of the PRs listed there includes an article by Bruce explaining what's wrong with the current patches. If you think you can fix them, go ahead; I'm not familiar enough with the kernel's interrupt handling mechanisms to do it myself. BTW, Dropping the MTU doesn't really help, because although you get inter-packet breaks more often, which allows you to catch up on interrupts a little, you're transmitting more data, which leads to higher CPU usage. > 3) Soup up LPIP so it doesn't hog as much CPU. Unfortunately, that's not possible unless you can live with having the parallell port issuing two interrupts for every byte transferred over the link. As I understand it, the current implementation generates one interrupt per packet, then polls the parallell port to actually read the data. The busy-looping in the polling code is what hogs the CPU. > On the latter point, has anyone looked at making LPIP transmit bytes > instead of nybbles? This would require a collision detection mechanism, or a slave/master scheme in which one of the hosts never talks unless asked by the other. DES -- Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rx4n2abuo5c.fsf>