Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.dcom.lans
Subject: Re: FDDI Performance
Message-ID: <7200@titcce.cc.titech.ac.jp>
Date: 8 Feb 91 07:27:43 GMT
References: <1991Feb1.175751.13639@relay.nswc.navy.mil> <7185@titcce.cc.titech.ac.jp> <84440@sgi.sgi.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 44

In article <84440@sgi.sgi.com>
	vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>At least two system vendors and at
>least one add-in-hardware vendor offer optional server cache mechanisms.

Sorry, I forgot to mention them, obviously because we are not using them. :-)

>> Of course, 40Mbps is observed on both side.

>The reported numbers are respectable, but far from "astonishing."

Maybe. But, FDDI is only 100Mbps. With the early versions of software,
it is difficult to fully extract the interface speed. So, 40Mbps today
may mean that FDDI will soon be saturated if the device driver is a
little more tuned.

We just began to move toward FDDI, so the figure is at least menacing, 
if not astonishing.

>I know of more than one independent implementation that gets several times
>the ttcp TCP value.

Would you post more detailed information about them?

>The NFS value of 1-2 MByte or 8-16 Mbit sounds like the
>systems are disk limited.

As for read performance of 2MB/sec, the read file is fully buffer cached
(I assume you know what is buffer cache). So, there can be no disk limit.
With 40Mbps UDP speed, 16Mbps NFS read seems to be fairly reasonable
figure, dosen't it?

>I'll guess that the low 10Mbit TCP value, esp. compared to the
>40Mbit UDP value,

Surely.

>is caused by using a small window or MSS.

May be or may not be. The only thing I know is the default buffer
size of ttcp is 8KB.

						Masataka Ohta