Skip site navigation (1)Skip section navigation (2)
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>