Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!BRL.ARPA!mike
From: mike@BRL.ARPA.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP echo
Message-ID: <8704300509.aa18764@SEM.BRL.ARPA>
Date: Thu, 30-Apr-87 05:09:10 EDT
Article-I.D.: SEM.8704300509.aa18764
Posted: Thu Apr 30 05:09:10 1987
Date-Received: Fri, 1-May-87 05:08:20 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 31

I have a routine called TTCP which is useful for testing both TCP and
UDP (inspired by a program of the same name that Excelan once sent a
friend to test *his* TCP).  By default, it acts much like a UNIX pipe,
extended to the network on one side;  optionally, it can source/sink a
given quantity of patterns.  Only occasionally useful as a
communications tool, it's great for tests and debugging. For your fatnet
tests, I'd use it in UDP mode with the source/sink option. While it will
tell you about packet loss, CPU and clock time used, it does not assume
the clocks are synchronized, so it does not try to make one-way timing
assessments.  That could be very easily added if times can be believed.

TTCP is my standard tool for conducting performance measurements;  on
various occasions I have used it to test TCP performance, effects of
window sizes, performance/overhead differences between various Ethernet
interfaces on the same machine, gateway performance, and end-to-end
InterNet performance.

The most interesting communications use of this tool is for sending
huge quantities of data painlessly between UNIX systems.  On rcvr,
run
	ttcp -r | tar xvf -
on sender run
	tar cvf - . | ttcp -t destinationhost

It has also been very useful for setting up "TCP relays" to avoid the
GGP extra-hop problem, and/or the EGP packet-fragmentation-induced
routing problem, when having to move > O(10 Mbytes) of data on our
troubled InterNet.

	Best,
	 -Mike