Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!mips!sgi!rpw3@rigden.wpd.sgi.com
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.protocols.misc
Subject: Re: Realtime Protocols
Message-ID: <72630@sgi.sgi.com>
Date: 19 Oct 90 05:10:32 GMT
References: <24594@uflorida.cis.ufl.EDU> <32683@sparkyfs.istc.sri.com> <59769@bbn.BBN.COM> <71126@sgi.sgi.com> <59793@bbn.BBN.COM>
Sender: guest@sgi.sgi.com
Reply-To: rpw3@sgi.com (Rob Warnock)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 48

A number of people said a lot of fine stuff about FDDI & TTRT, etc. I'd just
like to point out another thing I dislike about small TTRTs is that it makes
the ring "brittle". That is, instead of seeing a pretty good approximation
of an M/D/1 server (where D = 100 Mb/s) in which you experience a smooth
queuing delay versus load curve, as is shown in all the venerable old texts,
the ring presents a very sharp load-limit to each station. That is, as a given
station's load builds up, for a while you track the default delay/load curve,
then *suddenly* the ring bandwidth will appear to limit, and the perceived
delays will skyrocket.

This may be "good" --in *some* environments-- if you have a mix of light-load
stations and heavy-load stations. When the heavy-load stations "hit the wall"
of the small TTRT, the light-load stations will get better perceived response.
(Even here, the downside is that is you experience a temporary ring-wide
overload, it's *worse* with a small TTRT than a large one, since the ring's
overall carrying capacity is limited by he small TTRT.)

But in the general-purpose computing environment, where we all just want the
data to move, like it does (eventually) on Ethernet, small TTRTs are *bad*!
They take away the "soft edge" of the natural 100 Mb/s M/D/1 queuing curve.

And if your "small" users are trying to share a few big common file servers,
you're going to get worse-than-expected performance out of your FDDI, since
the big fast file servers will saturate at the TTRT limit long before the ring
is really loaded.

And *that's* what's wrong with vendors putting small default TTRT's in their
gear (as noted by Vernon Schryver). It *prevents* the user (local net admin)
from tuning their ring for best local performance, by *preempting* the most
significant FDDI tuning parameter! ONLY ONE (OBSCURE) STATION need set a small
TTRT to preempt the net manager's options. *ALL* vendors should [dare I say
*must*?] leave the TTRT at the default (169ms?) in shipped product, or risk
being labled a "polluter" in some markets... [E.g., general-purpose computing!]

Let me be explicit: If I have bought FDDI and a mongo fast NFS file server
that can pump out 85 or 90 Mb/s to 200-300 diskless workstations, I am going
to be *very* unhappy if some random workstation or router or monitor box that
I add to the ring [or one of my users adds without telling me!] suddenly causes
my expensive file server to clamp at 10 or 20 Mb/s (or less) of throughput!


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311