From owner-freebsd-current@FreeBSD.ORG Mon Oct 18 10:24:17 2004 Return-Path: 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 C13C316A4CE for ; Mon, 18 Oct 2004 10:24:17 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C39543D2D for ; Mon, 18 Oct 2004 10:24:17 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 15235F1D71; Mon, 18 Oct 2004 03:24:15 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07442-10; Mon, 18 Oct 2004 03:24:13 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id D5CE1F1D47; Mon, 18 Oct 2004 03:24:13 -0700 (PDT) From: Sean McNeil To: John-Mark Gurney In-Reply-To: <20041018011235.GB22681@funkthat.com> References: <1097896460.1123.2.camel@server.mcneil.com> <20041018011235.GB22681@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-U08BKTFU0dTvkWhAPsqC" Message-Id: <1098095053.8310.35.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 18 Oct 2004 03:24:13 -0700 X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-current@freebsd.org Subject: Re: re0 fix that works with polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 10:24:18 -0000 --=-U08BKTFU0dTvkWhAPsqC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-10-17 at 18:12, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Sun, Oct 17, 2004 at 16:28 -0700: > > I'll do some tests shortly to see about these issues... >=20 > Ok, I played around w/ rwatson's netsend program, and I was able to > send 1316 byte payload udp packets at about 28kpps w/o problems.. I > was not able to confirm that no packets were loss, BUT, netstat did > show very close to 28kpps received... At 28kpps, it's far exceeds > your problem of 15Mbps, it is about 38megbytes/sec.. I looked at netsend a little and it looks like a nice little tool. I assume there is a program for the other side as well? I just glanced at it, so apologies if it work on either end. My testing was slightly different in that I am sending udp _multicast_ packets. I've been using vls to push the data out and I do not know how it behaves with sockets (Perhaps it is writing with no delay as opposed to waiting for the lower layer to push the data out). I honestly do not know. I also assume that you have been testing with the nic set to 1000BT (gigE)? Seems like it from the xfer rate. There are no issues when it is going out 100BT. > What does your dmesg say about your re0? >=20 > Mine is: > re0: port 0xe000-0xe0ff mem = 0xe8002000-0xe80020ff irq 11 at device 11.0 on pci0 > re0: Ethernet address: 00:50:fc:f7:5b:d0 And mine says: re0: port 0xcc00-0xccff mem 0x= cfffb300-0xcfffb3ff irq 16 at device 11.0 on pci0 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto re0: Ethernet address: 00:0c:76:e9:2c:58 It is running on its own irq. > and it's more specificly a 32-bit ConnectGear G30TX-32. Mine is on my amd64 mobo. I'm running native amd64 freebsd. To answer a previous email (quoted here...) > Ok, interesting... now are you sure that adding re_txeof in > re_start is better than properly fixing it so that we can make use > of the extra tx descriptors that the 8169 supports? Right now it is > hardcoded to 64 because that is all that the 8110 supports iirc, but > the 8164 supports upto 1024 tx descriptors... I really didn't need to add the re_txeof in re_send I don't think. My main issue with polling appears to be that HZ=3D1000 doesn't seem to cause draining of the tx buffers fast enough. I had to keep the tx timer to ensure that. On the receive side I have no idea either. I've only tested xmit. > Also, do you know of the tx timer changes fire rate dependant upon > the speed of the link.. the 8169 data sheet gives no specifics on > what the rate of the time is and approrpriate values.. Not a clue. Sorry. It would explain the failure to work with 1000BT vs. 100BT. Except it doesn't make sense. The timer running slower at the higher rate interface? Thanks for looking into this, John-Mark. Sean --=-U08BKTFU0dTvkWhAPsqC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBc5nNyQsGN30uGE4RArHAAJ9GitIBs9KQBfmV3PwjRCpfyOBJLQCdH/tr vKcAA98MFHE1tYYff+H6aIU= =eT+G -----END PGP SIGNATURE----- --=-U08BKTFU0dTvkWhAPsqC--