Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!BRL.ARPA!mike
From: mike@BRL.ARPA (Mike Muuss)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Ethernet Suffering
Message-ID: <8705050344.aa07643@SEM.BRL.ARPA>
Date: Tue, 5-May-87 03:44:51 EDT
Article-I.D.: SEM.8705050344.aa07643
Posted: Tue May  5 03:44:51 1987
Date-Received: Thu, 7-May-87 05:34:43 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20

I agree that the TTCP only measured memory-to-memory throughput. That
was the intent -- to see how much data could be shoveled. I did not
intend to suggest it was a generic benchmark. Note that TTCP was using
TCP, mind you, not NFS or ND.

In our environment, we do a lot of network-based 24-bit RGB graphics,
which means whacking .75Mbytes (lores) or 3 Mbytes (hires) for each
image.  Often they are computed and displayed without ever touching
a disk.  So the TTCP test was not uninteresting.

Our Gould 9000 fileserver, which serves the collection of Suns I
mentioned, can be seen at busy times handling 200 packets/second
in both the transmit and receive directions (peak).  Many of them
result in disk transactions, although the ratio can be deceptive.
Eg, 1 pkt arrives asking for 8kbytes of data, which is read with
one disk I/O, and returned in 8 packets.  1 disk I/O, 9 packets.

Hope you find these random statistics of interest.
	Best,
	 -M