Date: Fri, 19 Mar 1999 20:13:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: Bill Paul <wpaul@skynet.ctr.columbia.edu>, hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet revisited Message-ID: <199903200413.UAA16399@apollo.backplane.com> References: <199903200132.UAA04463@skynet.ctr.columbia.edu> <36F2FE8E.7566F4CF@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Bill Paul wrote:
:>
:> The receiving host is under heavy interrupt load. Andrew Gallatin has
:> said to me that this is a classic case of livelock, where the system
:> is so busy processing interrupts that nothing else is getting done.
:> In this case, the NIC is dutifully DMAing all the packets to the host
:> and the driver is queing them all to ether_input(), but this is happening
:...
:
:I think Andrew might be right..
:it could well be livelock.
:
:Matt Thomas implemented a solution for the 100mb dec cards
:when 100 was fast. I think that the de drivers responded to the
:interrupt and immediatly did SCHEDNETISR() to schedule the rest of
Hey cool, at least the hardware problem has been solved!
On the livelock thingy -- well, one way to find out is to use ipfw
to throw away the packets, and then do a 'systat -vm 1' to see where
the cpu's time is being sent and how much cpu is being used.
I'm guessing between 50% and 70% of the cpu is being eaten with the
packets going into an ipfw bitbucket.
Each memory read or write represents around 85 MBytes/sec. The DMA counts
as one. The read() system call counts as two ( because it must read from
one memory location and write to another ) -- this puts us perilously
close to the memory bandwidth limit of the cpu when you count all the
other garbage going on that's breaking up the L1 cache.
:julian
-Matt
Matthew Dillon
<dillon@backplane.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?199903200413.UAA16399>