From owner-freebsd-hackers Fri Mar 19 20:13:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F06BD14E9F for ; Fri, 19 Mar 1999 20:13:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA16399; Fri, 19 Mar 1999 20:13:07 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Mar 1999 20:13:07 -0800 (PST) From: Matthew Dillon Message-Id: <199903200413.UAA16399@apollo.backplane.com> To: Julian Elischer Cc: Bill Paul , hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet revisited References: <199903200132.UAA04463@skynet.ctr.columbia.edu> <36F2FE8E.7566F4CF@whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message