Date: Mon, 02 Dec 2002 01:27:34 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Lawson <nate@root.org> Cc: freebsd-current@freebsd.org Subject: Re: Any ideas at all about network problem? Message-ID: <3DEB2786.6EDA2C1@mindspring.com> References: <Pine.BSF.4.21.0212020006350.1744-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEB2786.6EDA2C1>