From owner-freebsd-hackers Thu Feb 26 15:41:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24173 for freebsd-hackers-outgoing; Thu, 26 Feb 1998 15:41:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA23936 for ; Thu, 26 Feb 1998 15:41:14 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 27884 invoked by uid 1001); 26 Feb 1998 23:41:04 +0000 (GMT) To: dlittell@onramp.net Cc: hackers@FreeBSD.ORG Subject: Re: Token Ring for FreeBSD yet? In-Reply-To: Your message of "Wed, 25 Feb 1998 19:27:09 -0600" References: <34F4C4ED.31DFF4F5@onramp.net> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 27 Feb 1998 00:41:04 +0100 Message-ID: <27882.888536464@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Sorry, it's not that simple. On a token ring network, tokens can get lost. > > Yes, this happens in real life. So any "guarantee" that you give for token > > ring networks is based on statistics. > > Yeah, it really is that simple. Token loss recovery time has an upper > bound Yes. So does the waiting time for Ethernet with maximum number of collisions (367 ms). Think about what happens: In *both* cases higher protocol layers will most likely see a timeout and perform a retransmit in software. Thus, either they are both deterministic (time to transmit has an upper bound), or neither of them are. > and token ring-based networks degrade gracefully, ensuring some > non-zero throughput even at 100% offered load. I believe there are > meltdown scenarios in Ethernet that guarantee you'll never get anything > out. The "meltdown scenarios" are as far as I know based on infinite number of stations, which is specifically disallowed by the Ethernet rules. There is a *reason* for the limit of maximum 1024 stations per collision domain - it is precisely to avoid such a meltdown. The "meltdown scenarios" have been debunked both by theory and practical measurements by now. There is no reason to drag them out again. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message