Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans
Subject: Re: FDDI Performance
Message-ID: <83979@sgi.sgi.com>
Date: 4 Feb 91 23:12:18 GMT
References: <1991Feb1.175751.13639@relay.nswc.navy.mil> <7178@titcce.cc.titech.ac.jp>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 41

In article <7178@titcce.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
> 
> >2.  The size of the file and the average throughput (in bytes/sec) for the
> >    file transfer.
> 
> ttcp (default setting) showed 10Mbps TCP and 40Mbps UDP speed.
> 
> NFS speed is about 1MB/sec for writing and 2MB/sec for reading.

How was NFS speed measured?  Nfsstone or one of the other benchmarks?
What, if any, compensation for client and server cache policies and mechanisms
was there?

Is the UDP speed quoted above the value reported by the transimitter or by
the receiver?  The natures of ttcp and UDP are such it is easy to have the
transmitter produce very high values and the receiver as close to 0 as you
wish.  The value reported by the receiving UDP ttcp is often much lower
than the value reported by the transmitter.


Standard UNIX BSD-style drivers (which I suspect are being reported above)
discard output packets when the output queue gets too far full.  In other
words, the ttcp user-process may think and report that its data has been
transmitted but in reality much of the data never made it as far as fiber.
This point is often missed or ignored; I continue to repeat the story of
the Ethernet board vendor who tried to sell me his boards by saying his Sun
"blast" driver could transmit 12Mbits/sec UDP/IP/Ethernet.

To make the receive side of ttcp as close to zero as you want, use a very
fast transmitter (say something that transmitts >30Mbit/sec), and a
receiver that is very much slower.  For example, use a very old, slow Sun 3
and a new, fast Sun 4 transmitter.  If the speed difference is high enough,
you may be able to keep the receiver so busy handling input interrupts and
DMA that the receiving ttcp process never has an opportunity to run, until
after th transmitter stops.  The result can be that receiver reports
receiving one socket-buffer-size worth of data out of many MByte
transmitted.



Vernon Schryver,   vjs@sgi.com