Date: Sun, 01 Dec 1996 22:19:37 -0800 From: David Greenman <dg@root.com> To: Stephen Hocking <sysseh@devetir.qld.gov.au> Cc: hackers@FreeBSD.ORG Subject: Re: TCP/IP bandwidth bragging Message-ID: <199612020619.WAA05208@root.com> In-Reply-To: Your message of "Mon, 02 Dec 1996 13:15:57 %2B1000." <199612020315.DAA13781@netfl15a.devetir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>A Linux zealot has the following in his sig - what's our current ability? > >---------------------------------------------//// >Yow! 11.26 MB/s remote host TCP bandwidth & //// >199 usec remote TCP latency over 100Mb/s //// >ethernet. Beat that! //// Tests over fast ethernet are subjective without knowing which ethernet cards were involved, whether they are connected to a switch and have negotiated a full duplex connection, and whether the ethernet is completely idle. Of course, it's also very necessary to know the speed and type of the machines involved. However, to the loopback interface (both the client and server running on the same machine), I get: [corbin:bsd] lat_tcp localhost $Id: lat_tcp.c,v 1.1 1994/11/18 08:49:48 lm Exp $ TCP latency using localhost: 85 microseconds [corbin:bsd] bw_tcp localhost $Id: bw_tcp.c,v 1.1 1994/11/18 08:49:48 lm Exp $ Socket bandwidth using localhost: 54.46 MB/sec ...on a 240MHz Pentium Pro. In my current arrangement here I'm only able to do half duplex on my 100Mbps network and the collisions that are caused by the TCP acks can have a significant effect on the numbers. However, if I do a unidirectional test using UDP I get: [corbin:dg] ttcp -p9 -n8192 -u -t core ... ttcp-t: 67108864 bytes in 5.61 real seconds = 11682.55 KB/sec +++ I'd say "beat that", except that I know that you can't since that is the theoretical maximum for fast ethernet. The ethernet card in this case is a Intel Pro/100B. For TCP on this net, the numbers are less interesting: [corbin:dg] ttcp -p9 -n8192 -t implode ttcp-t: buflen=8192, nbuf=8192, align=16384/+0, port=9 tcp -> implode ttcp-t: socket ttcp-t: nopush ttcp-t: connect ttcp-t: 67108864 bytes in 6.40 real seconds = 10239.26 KB/sec +++ ttcp-t: 8192 I/O calls, msec/call = 0.80, calls/sec = 1279.91 ttcp-t: 0.0user 1.3sys 0:06real 20% 133i+282d 86maxrss 0+2pf 7570+9csw The result is highly dependant on when the receiving machine acks. I actually get _lower_ numbers when talking to a much faster machine (same type of ethernet card in all cases: Pro/100B): [corbin:dg] ttcp -p9 -n8192 -t core ttcp-t: buflen=8192, nbuf=8192, align=16384/+0, port=9 tcp -> core ttcp-t: socket ttcp-t: nopush ttcp-t: connect ttcp-t: 67108864 bytes in 7.27 real seconds = 9008.72 KB/sec +++ ttcp-t: 8192 I/O calls, msec/call = 0.91, calls/sec = 1126.09 ttcp-t: 0.0user 1.4sys 0:07real 20% 136i+289d 268maxrss 0+2pf 7671+10csw "implode" is a 90MHz Pentium; "core" is a 133MHz Pentium; "corbin" is a 240MHz PPro. The lower numbers can be understood when looking at the number of collisions - they are much higher when talking to "core" compared to "implode". This wouldn't be an issue and we'd be seeing about 1130MB/s numbers if this was full duplex. The "11.26 MB/s" number quoted above can't be exceeded (by much) since that is about the theoretical maximum for full duplex ethernet (assuming 1460 byte data packets). Unfortunately, FreeBSD doesn't current have any drivers that work in full duplex mode. I hope to change this at some point. :-) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612020619.WAA05208>