Date: Mon, 11 Oct 2004 10:50:44 -0700 From: Sean McNeil <sean@mcneil.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: 20% packet loss with re0 in gigE mode vs. 0% in 100BT Message-ID: <1097517044.1795.12.camel@server> In-Reply-To: <Pine.NEB.3.96L.1041011043648.31040I-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1041011043648.31040I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-3kG2O1eplx3JS/Plv5Iw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-10-11 at 01:52, Robert Watson wrote: > On Sun, 10 Oct 2004, Sean McNeil wrote: >=20 > > I do not think this is a very acceptable performance, but I have little > > knowledge of ethernet drivers on FreeBSD to identify issues. I'd say > > any packet loss in the configuration I was testing would be > > unacceptable. Where to begin? I'll do what I can to help fix this.=20 > >=20 > > The tests were with udp packets of size 1316 on a quiet network. As > > explained in previous emails the only network combination that has loss > > is when the re0 is in gigE mode under FreeBSD.=20 >=20 > Whether or not you can send at 1gps on gigabit ethernet depends quite a > bit on traffic profile and hardware. For example, to accomplish high > packet rates for small packet sizes, you need to make sure you have a > 64-bit PCI ethernet card. The above is a pretty large packet size, so I > would guess that even with poor hardware, you should be able to readily > get 500mbps transmission rates. Forgot to mention this from previous emails, but the transmission is fixed at 15Mbps. This is a 20% loss of udp data sent at 15Mbps!! Your suggestions are highly appreciated, but moot in my situation. > I'm not sure how much control you have over the application you're > running, but it would be interesting to know if it's getting back ENOBUFS > from send() to the network interface or not. This would tell us if the > output buffer for the network interface is filling or not. If you're not > filling it at 100mbs, the chances are you're not filling it at 1gbps, but > it's worth checking. >=20 > Assuming you're not filling the send buffer, it would definitely suggest = a > driver, configuration, or hardware bug. There have recently been a numbe= r > of changes to the if_re driver to fix support for jumbo frames, etc. It > would be interesting to know whether backing out to earlier revisions of > the if_re driver affect the problem you're seeing. In particular, > ifre.c:1.35 was the jumbo frame change, so 1.34 would be interesting, and > 1.31 is before some other related changes. Likewise, you could try > backing out to before locking was introduced by setting debug.mpsafenet= =3D0 > in loader.conf and then backing out to if_re.c:1.29. I might be generall= y > useful to try setting debug.mpsafenet=3D0 with the current driver to > eliminate that as a possible concern. These are good suggestions as well, but I have heard from another user that has seen this kind of thing over all of these versions. It is less likely then that the jumbo or locking changes caused the issue. Sean --=-3kG2O1eplx3JS/Plv5Iw 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) iD8DBQBBasf0yQsGN30uGE4RAtjdAJ0ffBZgTf2PnH+szwwTg6gPe3DEHgCgrkoe rPxYE4GqI3Kz6IsNVi4/yAg= =ouXK -----END PGP SIGNATURE----- --=-3kG2O1eplx3JS/Plv5Iw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1097517044.1795.12.camel>