Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!ames!sgi!vjs@rhyolite.wpd.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.dcom.lans Subject: Re: FDDI Performance Message-ID: <84864@sgi.sgi.com> Date: 11 Feb 91 18:12:28 GMT References: <1991Feb1.175751.13639@relay.nswc.navy.mil> <7200@titcce.cc.titech.ac.jp> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 61 In article <7200@titcce.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > > We just began to move toward FDDI, so the figure is at least menacing, > if not astonishing. Agreed. FDDI is only about 10x ethernet. There are commercially available multi-homed UNIX computers and file servers whose aggregate ethernet load would menance a single FDDI ring. I've long been whining about that. More recently, I've begun to realize that 100Mb is not so bad. 100Mb is too slow for backbones connecting many 10Mb or 100Mb LANs. However, there seem to be few applications for Gb networks, except to interconnect LAN's. At a recent meeting of high speed network developers, the gov. offered funding for non-backbone applications, but had no takers. Just as there is an upper bound on the useful speed of graphics, there may be an upper bound on the useful speed of a LAN, at least for the next few years. > >I know of more than one independent implementation that gets several times > >the ttcp TCP value. > Would you post more detailed information about them? I try to overcome the tempation to brag about my numbers in public, non-commercial forums like this; the SGI sales organization has them. I've been told first hand of simple ttcp TCP values >=30Mb. To my knowledge, those other numbers have not been published, so I can't provide attributions. A long time ago I've heard rumors of >=40Mb from a respected developer, but the hardware he was probably using has been conspicuously absent from the market. A workstation company and a FDDI board maker are advertising 25Mb, but each gets that by somehow running two simultaneous ttcp's on one machine to two other machines. Those values are hard to evaluate without knowing how the multiple ttcp's were synchronized, but neither vendor says. A mainframe maker and its customers have a version of ttcp that does several simultaneous TCP transfers. The numbers from that benchmark are believable, but give different information than the familiar ttcp number. > >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? It seems respectable. How does the same benchmark run locally on the server? That would help determine where the 40Mb/16Mb=2.5x difference is. > >I'll guess that the low 10Mbit TCP value, esp. compared to the > >40Mbit UDP value, > >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. Current versions of ttcp allow changing the window with -b. If the TCP implementation has the 4.3+ fixes, then a multiple of 4096 >= 48K might be much higher. Vernon Schryver, vjs@sgi.com