From owner-freebsd-current Mon Dec 2 1:30:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 524BB37B401 for ; Mon, 2 Dec 2002 01:30:40 -0800 (PST) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id E449343ECF for ; Mon, 2 Dec 2002 01:30:39 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0097.cvx22-bradley.dialup.earthlink.net ([209.179.198.97] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ImuS-0004vp-00; Mon, 02 Dec 2002 01:30:36 -0800 Message-ID: <3DEB2786.6EDA2C1@mindspring.com> Date: Mon, 02 Dec 2002 01:27:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: freebsd-current@freebsd.org Subject: Re: Any ideas at all about network problem? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ ... bad throughput on bad NICs ... ] Nate Lawson wrote: > > FWIW, the root cause is likely a result of something in the > > last 8 months, which means log2(240)+1 = 8 compiles to find > > the problem on your hardware; if, in the last 2.5 years, > > which we know to be the case, it's log2(2.5*365)+1 = 10 > > compiles. > > My guess is mii_tick() latency. Off the top of my head, I would blame one of: 1.79 don't strip the Ethernet header for input packets 1.72 If we get 0xffff back when reading the status register, assume the card has gone away instead of spinning in the interrupt handler. This stops my machine from hanging when I eject a rl(4)-based cardbus card. 1.71 Fix if_timer logic to make sure that there is always a timeout pending if there are packets queued for transmission. 1.69 Add DEVICE_POLLING support to the "rl" driver. The diffs are very similar to the ones for the "sis" driver. If I had to place a bet, I would bet it was 1.69, even though he said it happens with/without polling, he didn't say whether he disabled it as a compilation option or just by using the sysctl. If he used the sysctl method, that means an extra registration function call in rl_intr(), each time an interrupt happens, which is nothing (but it does affect the benchmarks, making polling look betther than it really is, in a side-by-side comparison), and the rl_poll code gets called on all the clock ticks, potentially skewing the hardware state: the ether_poll code should probably also check that IFF_POLLING is set. If it's not that, then my next favorite to blame would be 1.79, which seems to me is a *massive* change. I pick both of those because they are relatively driver-agnostic changes, and he said they happened on both drivers. My third choice, is "something else in the system was changed", which makes it better to do the binary search. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message