Date: Wed, 20 Jun 2001 11:11:35 -0700 From: "Kevin Oberman" <oberman@es.net> To: "David W. Chapman Jr." <dwcjr@inethouston.net> Cc: "Sam C. Zamarripa" <scz73@yahoo.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Weird Traceroute/Ping Message-ID: <200106201811.f5KIBZc11576@ptavv.es.net> In-Reply-To: Your message of "Tue, 19 Jun 2001 22:30:45 CDT." <20010619223045.J6448@leviathan.inethouston.net>
next in thread | previous in thread | raw e-mail | index | archive | help
You are confusing the size of the pipe with it's length. Traceroute (or ping) tell you nothing about how "fast" you line is. By "fast" I mean bandwidth.) You are sending a very small number of very small packets. What they do measure is the length of the pipe as RTT which is a function of the propagation time across links, router delay (near zero with modern backbone routers) and congestion. cvsup7.freebsd.org is located in Seattle. The traceroute would indicate that the source of these packets is in Seattle and VERY close to the facility in Seattle where cvsup7 is located. But there is nothing there to provide any indication of bandwidth of the connection. To determine the effective bandwidth of a connection you need to know the lowest bandwidth of any link between you and the other end. pchar (in ports) is a pretty good way to look at this, although it can be misleading in some conditions. The other issue is the round trip time as determined by a ping using large packets. If you connection is Ethernet you probably want 1460 byte packets. For slow serial links you probably want 512 bytes. Another factor in performance IF the minimum bandwidth is large (> 3 Mbps) is window size. FreeBSD defaults to a rather small window size for wide area connections on fast links. I routinely up my window size to 64 KB. If you are on a dial-up, you probably don't want to do this! The maximum possible speed of a link is the smaller of the minimum bandwidth or window size in bits divided by the round trip time in seconds. Being very close to cvsup7 makes it a very good candidate for your purposes. The final issue is packet loss. A lossy line is very bad for performance as TCP will try to tune itself to the speed of the link and losses tend to upset this calculation. Send a lot of 500 byte pings to test this. DON'T USE FLOOD MODE! Writing a tool to study this is certainly possible, but non-trivial. And congestion that causes long delays or losses at one time may be transient, so the best server my change frequently. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106201811.f5KIBZc11576>