Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!uakari.primate.wisc.edu!sdd.hp.com!decwrl!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.dcom.lans Subject: Re: "real-time" over a lan: token ring vs ethernet vs ? Keywords: real-time, token ring, 802.5, ethernet Message-ID: <66116@sgi.sgi.com> Date: 4 Aug 90 09:26:19 GMT References: <19300@well.sf.ca.us> <61624@bu.edu.bu.edu> Sender: rpw3@rigden.wpd.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Distribution: comp Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 58 In article <61624@bu.edu.bu.edu> kwe@bu-it.bu.edu (Kent England) writes: +--------------- | hedrick@athos.rutgers.edu (Charles Hedrick) writes: | > You've got to be real careful about this "guaranteed" stuff. | ... I recall a discussion about FDDI that started with figuring | out effective throughput and ended up talking about the effect on | throughput of setting certain token rotation timers. I believe | that discussion was right here on comp.dcom.lans two or three months | ago. I can't recall exactly the other principals in the discussion or | I would give credit for info. +--------------- I was one of them. ;-} It was in late May, as I recall. +--------------- | One thing I came away with from that discussion was that | some of the worst case maximum token rotation times, for given | congestion and timer settings, were positively geologic timeframes. +--------------- *Seconds*! Like, 82 of them! Max config ring, 500 dual-attach single-MAC stations in a 100 km circumference circle, that is, 200 Km of fiber. [My previous number of 164 seconds was for 1000 single-attach stations with no concentrators, which isn't really a legal configuration.] And, quoting further from myself in that discussion: "Get real!", you say? O.k., let's say that since we really don't want any given file server to be able to bang out more than 90% of the net (even if we ask him to), we can run with T_Opr as small as 16ms (or, max_bytes/rotation == 200K). That still means 16 *seconds* before you get to send, if everybody else suddenly wants to send 200K, and you happened to have just missed capturing the token. (That is, the "storm" started with the guy immediately downstream of you.) [Oops! "Only" 8 seconds if you have 500 dual-attach single-MAC stations.] "That's still ridiculous!", you say? O.k., so we don't have 1000 nodes in the ring, we have 200. And we don't have 200km of fiber, we have 20km. Now we're down to something that you could easily see in a single department, if all the fiber happens to be "starred" out from a central wiring closet. (Dual-attach, so the average station is 25 meters from the closet. Real enough?) Idle TRT is down to 320usec, so we set T_Opr to 5.66ms (so our expensive file server can at least send a 64K window per token, with 4096 bytes of user data per packet, and thus get about 93% of FDDI), and it *still* can be as much as 1.1 seconds before you get to send if everybody else suddenly wants to send only 64K. I'll still stand by those numbers [as modifed above]... -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