Path: utzoo!attcan!uunet!decwrl!ads.com!sparkyfs!levin
From: levin@sparkyfs.istc.sri.com (Larry Levin)
Newsgroups: comp.protocols.misc
Subject: Re: Realtime Protocols
Message-ID: <32704@sparkyfs.istc.sri.com>
Date: 8 Oct 90 16:45:23 GMT
References: <24594@uflorida.cis.ufl.EDU> <32683@sparkyfs.istc.sri.com> <59769@bbn.BBN.COM> <71126@sgi.sgi.com> <59793@bbn.BBN.COM>
Reply-To: levin@beijing.erg.sri.com.UUCP (Larry Levin)
Organization: SRI International, Menlo Park, CA 94025
Lines: 22

In article <59793@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) writes:
>
>He computes the max delay and average efficiency for 500 stations with
>TTRT at 8ms as 8 secs and 75%.  But if, as he suggests, you keep
>yourself to a max of about 100 stations, max access delay is about
>0.8 seconds and 86%.  (If you are willing to get smaller, down to
>around 10 stations, its 0.15 and 99.5%).
>
If you are a vendor like Silcon Graphics, you have to take the worst case 
scenario (i.e. 500 stations) into account.  If you are an architect and
systems integrator of turn key real-time control systems like myself, you
focus on your clients actual requirements.  These are typicaly 15 to
60 stations of which 2 to 10 exchange real-time data (i.e. access
delay must be less then some Tmax where Tmax is application dependant but 
typicaly under .5 sec) and the rest require interactive response times
with a max delay under 1 sec.  In this scenario TTR protocols appear to
be a viable alternative.

Larry Levin
Information Systems-Engineering Center
SRI International,  Menlo Park CA.
levin@istd.sri.com