sanand@radha.UUCP (Sanand Patel) (02/05/88)
For the gentleman, and others who may be interested in published papers:
"User-Process Communication Performance in Networks of Computers",
Cabrera, Hunter, Karels, Mosher.
in: IEEE Transactions on Software Engineering, Jan 1988, pg 38.
--- sanand@HUB.TORONTO.EDU
--- {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100
--
---
--- sanand@hub.toronto.edu
--- UUCP: {uunet!mnetor, lsuc, dciem}!radha!sanand
--- 416-756-4100vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/16/89)
Some people have written me expressing surprise at my claim that 400KB/sec is slow for process-to-process TCP/IP, or asking about ttcp. The numbers one can obtain using port 7, "echo", or port 9, "discard", depend strongly on how the sink or echoer is implemented. For example, the Silicon Graphics IRIS numbers improved significantly after inetd was tuned up a bit. After that exercise, I discarded my implementation of a "blast" benchmark. Ttcp is a user-process-to-user-process TCP and UDP benchmark from BRL. Mike Muuss has given permission to distribute it. It differs from some other benchmarks such as at least some versions of "blast" by having both a sender and a receiver. A version of it is available via anonymous ftp from sgi.com in sgi/src/ttcp.c. For some reason, on this side of the Mountain View dump there are fewer Sun workstations than those of another maker. However, we have seen peak averages of above 400KB/sec and well over 800KB/sec for pairs of the two of Sun 4 models that were handy. The graph for the faster, Sun 4/260, had two valleys, but was otherwise flat for buffer sizes above 1KB. We don't have the latest Sun operating systems, but I not expect things to be slower. I do not know if Sun is using header prediction, but doubt it for several nontechnical reasons. Among technical reasons is that given a fast enough cpu, you can execute a lot of protocol code and copy a lot of bytes in the transmission time of an ethernet packet. Of course, as with any benchmark, one should try ttcp many times and vary its parameters to obtain a range of numbers. We usually run a script which take averages for each of about a dozen buffer sizes. As always, ttcp is a synthetic benchmark, less interesting than the target application itself. Given all of that, a factor of 2 above what some thought is the state of the art is significant. Please notice that at these speeds, little else is happening on the ethernet in general and so specifically in the network parts of the pair of hosts. That makes ttcp reasonably representative of real ethernet applications talking at maximum speed. If you are buying a bridge or router, you might want to consider the implications of >800KB/sec speeds between hosts upon the required speed of the bridge. To avoid being commercial, I won't mention the other workstation vendor's numbers. Vernon Schryver Silicon Graphics vjs@sgi.com
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/28/89)
Since there has been substantial traffic to the ttcp.c I offered for
anonymous ftp, here is a script for running ttcp. I'm told that one does
something like "script 1" on the receiver and "script 1 rcvr" on the
sender. One should first turn off all deamons, including YP, routed,
gated, etc. and shut off the window system--provided that you want to
measure pure, maximum TCP or UDP. The effect of these other things on the
numbers is very interesting, but not obviously relevant in this forum.
----------------
#!/bin/csh -f
set udp=""
#set udp="-u"
set lengths=(0005 0128 0256 0512 1024 1536 2048 3072 3584 4096 5120 5400 6144 7168 8192)
set numBufs=25000
if ("$2" == "") then
set op=r
# if (-e Count) then
# @ run=`cat Count`
# @ run++
# echo $run >! Count
# else
# echo 1 > Count
# @ run = 1
# endif
else
set op=t
# @ run = `cat Count`
endif
set run = $1
@ port = 4000 + $run * 100
echo "Starting $udp run $run"
set output=$op$run
cp /dev/null $output
foreach buflen ($lengths)
echo "$buflen, port = $port"
if ($op == t) then
echo "" >> $output
./ttcp -t $udp -p$port -n$numBufs -l$buflen $2 >> $output
sleep 2
else
echo "" >> $output
./ttcp -r $udp -p$port -n$numBufs -l8192 >> $output
sleep 1
endif
@ port++
end
----------------
Someone ambitious should enhance ttcp to take a list of buffer sizes and
numbers of passes for each size, and compute means. It would also be
better if it took a buffer size & a total transmission size, and divided
to compute the number of buffers to write.
It would be nice to find a public domain package to generate a postscript
plot of the results. The hills and valleys give insites into buffering
problems and successes. If the numbers are good, it also makes good sales
fodder. We use something internally, but it turns out to be private
property.
Vernon Schryver
Silicon Graphics
vjs@sgi.comgiamma@orc.olivetti.com (09/11/90)
I am interested to some tests for doing performance evaluation of TCP/IP, any suggestions ? Gianmaria Clerici giamma@orc.olivetti.com
artibee@noangel.wpd.sgi.com (Mary Artibee) (09/12/90)
> I am interested to some tests for doing performance > evaluation of TCP/IP, any suggestions ? You might consider "ttcp"... >From vjs@rhyolite.wpd.sgi.com Sat May 12 19:04:05 1990 (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Newsgroups: comp.protocols.tcp-ip Subject: Re: "ttcp" program Ttcp is handy for tuning a TCP or UDP implementation. Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently 192.48.153.1. ttcp.c.brl is the most recent BRL version I've seen. Ttcp.shar is from last August. Ttcp.c is our current understanding of what was acceptable to BRL. It includes controls for buffer alignment and other things. By default it is a file transfer program, needing '-s' to make it generate and sink data as a test program. I think there are also versions available from BRL, perhaps on brl.mil. They are probably newer than sgi:.../ttcp.c.brl. Ttcp has never appeared in comp.sources.unix, although I understood from the moderator that it would someday. If you buy a Silicon Graphics "IRIS", you'll find ttcp.c among other example and test programs in /usr/people/4Dgifts. There was some hassle with the port number. The original port 2000 conflicted with a certain solar window manager, currently the default window manager for SGI. BRL and SGI checked with the Net Gods about getting an official port number for ttcp, but failed. Be careful to understand the numbers people give you. Not long ago a vendor trying to sell stuff gave me what I thought were some good numbers. A few weeks later they happened to mention to some of my colleagues that the numbers were obtained by summing some simultaneous tests. It is as they say, "lies, damn lies, and benchmarks." Vernon Schryver Silicon Graphics vjs@sgi.com