home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.cell-relay
- Path: sparky!uunet!europa.asd.contel.com!emory!swrinde!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!sgigate!sgi!rigden.wpd.sgi.com!rpw3
- From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
- Subject: Re: The Low Cost Backbone
- Message-ID: <s9vokgk@sgi.sgi.com>
- Sender: rpw3@rigden.wpd.sgi.com
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Date: Fri, 13 Nov 1992 05:05:44 GMT
- Lines: 38
-
- nagle@netcom.com (John Nagle) writes:
- +---------------
- | myoung@force.ssd.lmsc.lockheed.com writes:
- | >More on the Lockheed switch, making it ATM comaptible:
- |
- | >The probability of buffer overflow is replaced by the probability that
- | >an out of sequence cell is still circulating in the backbone when
- | >its neighbors are forwarded to the access node.
- |
- | Cute. The transmission medium (fibre, etc.) IS the buffer.
- | It's like a railroad with no yards, just switches, and the trains
- | never stop until they reach their final destination.
- |
- | If nodes are too close together, does this create problems?
- +---------------
-
- No, because I think (based on a conversation with the Lockheed developer)
- you have a small but critical misunderstanding.
-
- The transmission medium is *not* the buffer, the host interfaces are! If no
- other outgoing trunk ports are free, the switch will route a cell back *into*
- any free host interface, where such misrouted cells then take priority over
- new traffic for transmission back out into the network fabric. Some thought
- will show that this is sufficient to keep from dropping any cells due to
- congestion.
-
- (There *is* a one cell buffer at the input to each switch port, but only to
- allow for non-synchrony of inputs due to links not all being the same length.)
-
-
- -Rob
-
- -----
- Rob Warnock, MS-9U/510 rpw3@sgi.com
- Silicon Graphics, Inc. (415)390-1673
- 2011 N. Shoreline Blvd.
- Mountain View, CA 94043
-
-