Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.sysv386
Subject: Re: tcp/ip & fddi chips (was Re: binary Mach distribution for 386)
Message-ID: <106@calcite.UUCP>
Date: 22 Jan 91 06:38:45 GMT
References: <13963@uswat.UUCP> <1991Jan4.140341.11874@granite.cr.bull.com> <14325@uudell.dell.com>
Organization: Rhyolite Software, Mountain View, CA
Lines: 61

In article <14325@uudell.dell.com>, sblair@upurbmw.dell.com (Steve Blair) writes:
> 2) TCP/IP over FDDI was only successful in gaining a B/W of about
> 	45->60Mb's/sec in "normal" operation mode, and in "burst"
> 	mode, mabye about 65->72Mb's/sec.
> 3) TCP/IP is notoriously ineffecient as a statefull protocol on
> 	"any wire". Therefore, that's one of the reasons that on
> 	a fairly quiet network, you'll only see about 4->6.2Mb's/sec
> 	*due to the statefull overhead* of TCP/IP.

This is not consistent with my experience as an implementer.  I know of
about 5 commercial, released implemenations, including my own, that get
well over 10Mbit/sec thru TCP/IP/FDDI as measured by TTCP.  I know of more
than one >30Mb/s, tho not necessarily released.  There are good rumors of
higher FDDI numbers, but honesty becomes scarce above 50.  (If it can't do
close to 100Mbit/sec in a burst, say 100KBytes, I think it's broken.)

As long as T_NEG is reasonable (say >=8msec), and as long as the total
traffic on the ring is <100Mb/s, you don't need to worry about keeping the
network quiet.  I make my speed measurements on a ring also used for
operational NFS, SMTP, etc.  I get dozens of Mbit/sec continuously and
indefinitely (necessarily measured by counting packets with a 3rd machine).

The "TCP is slow because ineffecient" is a familiar statement.  It is no
longer popular since being disproven.  Perhaps the simplest academic
proof is Van Jacobson's count of the number instructions to handle a TCP/IP
packet on a Sun, from interrupt to delivery, excluding checksumming and
byte copying.  As I recall, his number (for his code?) was ~200/packet.
Less academic is that between some CRAYs and some workstations, ULTRA gets
 ~13MBytes/sec TCP/IP over their proprietary link layer.

> FDDI does/will add significantly to the networked performance of many
> systems, and applications that are written to take advantage of the
> increased bandwidth. ...

There is little a well written program can or should do for FDDI.  Big
buffers and big windows are smart, but that's true on all but the slowest
media.  This is good and bad news.  I doubt FDDI would do much for a PC,
from XT to 486, but make it slower.  However, fast machines with better
buses, which already saturate Ethernet with TCP/IP, can gain by using FDDI
to peers.

> 2)  FDDI has certain information that in restructuring the "ring":
> 	after a failure takes sometime to occur. Also there are
> 	other packets, like scrubber packets, that consume some
> 	network overhead, just like routing information does.

One vendor (whose performance numbers I do not recall, and so did not count
above) became unpopular at a recent trade show (unnamed to avoid being sued
by the show managment) because of their purger (sic) frames.  These are
controversial and in my view naively implemented, but their bad effects do
NOT include consuming usable bandwidth.  While the ring is stable (ie. all
of the time in normal circumstances), there are no overhead frames
consuming significant usable bandwidth.  I'll forebear chanting chapter and
verse of the several standards in public.  This follows the ANSI X3T9.5
party line that NIFs, PRFs, SIFs, and SRFs are not significant, which is
manifestly true in small rings, and where T_NOTIFY is at the standard 30
seconds.  It also assumes the human ring managers have not gone crazy with
T_NEG.


Vernon Schryver,   vjs@sgi.com