Date: Fri, 20 Oct 1995 10:38:51 -0400 From: "Garrett A. Wollman" <wollman@lcs.mit.edu> To: jdl@chromatic.com Cc: questions@freebsd.org Subject: Slow throughput Message-ID: <9510201438.AA09104@halloran-eldar.lcs.mit.edu> In-Reply-To: <199510192205.RAA15051@chrome.jdl.com> References: <199510192007.NAA29801@corbin.Root.COM> <199510192205.RAA15051@chrome.jdl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 19 Oct 1995 17:05:19 -0500, Jon Loeliger <jdl@chrome.onramp.net> said: > OK, it's pretty clear now that I might have a mysteriously slow component > to my system's network (?) throughput. How do I find it? > At 64k ftp suggests a sustained rate of about: > 41539 bytes received in 23 seconds (1.8 Kbytes/s) > 1936621 bytes received in 8.9e+02 seconds (2.1 Kbytes/s) > It is somewhat slow, isn't it? FTP is not a very good way to measure raw throughput, particularly for such small data sizes where connection-setup and -teardown times can be significant. You should ftp to ftp.sgi.com and grab a program from there called `ttcp'. Now, pick two machines on opposite sides of your network connection, and run the following tests: one$ netstat -p tcp > one-tcp-before two$ netstat -p tcp > two-tcp-before one$ ttcp -r -s -v 2>&1 | tee one-recv.log two$ ttcp -t -s -v one 2>&1 | tee two-send.log [when this completes, both sides will exit] two$ ttcp -r -s -v 2>&1 | tee two-recv.log one$ ttcp -t -s -v two 2>&1 | tee one-send.log [again, both will exit] one$ netstat -p tcp > one-tcp-after two$ netstat -p tcp > two-tcp-after This will give you a large amount of data from which you can start analyzing your TCP performance. The output of the `ttcp' programs will tell you what your actual throughput was, and how much CPU time it took to achieve it. This will give you some idea of how much time was spent waiting for the other end. By comparing the two receiving sides, you may discover asymmetric behavior, which might result from routing anomalies or link congestion. By examining the TCP statistics, you can tell how much data had to be retransmitted, and to some extent why. The `route get DESTINATION' command will tell you what the measured round-trip time is from one end to the other, how stable it was, and (if you have MTUDISC enabled in your kernel) the MTU for the path to the other end. Hopefully this will give you a starting point for diagnosing your TCP performance. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510201438.AA09104>