Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) 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: Date: 29 Jul 90 21:57:08 GMT References: <19300@well.sf.ca.us> Distribution: comp Organization: Rutgers Univ., New Brunswick, N.J. Lines: 45 To: uunet!sonyusa!sfcsun!berger You've got to be real careful about this "guaranteed" stuff. I think it's mostly marketing propaganda. The behavior of both Ethernet and TR has statistical components. These include instantaneous load on the network and packets being dropped. TR propaganda talks about "guaranteeing" that the bandwidth is evenly split. But the problem is, generally there are enough hosts on the network that if they all decide to transmit at full speed at the same time, you've got an overload. So the fact that things work at all is due to the random nature of the traffic: all hosts don't transmit at once. Generally if you wanted to make a precise mathematical model of the thing, you'd have to take the probability distributions for the offered load of each source, and make sure that the combined load on the network is within acceptable bounds "almost all" of the time. Few of us can afford networks fast enough that the worst case will be within bounds. Maybe in your specific application you can. The point is that you've got to size the network so that you avoid an overload condition. The fact that TR and Ethernet handle overloads somewhat differently probably isn't going to affect you. There are also queueing issues in the hosts. Our experience with TR is that many of the IBM TR cards have fairly small buffers -- smaller than current Ethernet devices. So in fact the servers don't handle peak loads well at all. They start losing packets. Again, you may not be able to afford to get enough buffers on the cards to handle all slaves sending maximum size messages to the master at the same time. You're going to have to depend upon reasonable statistics. Finally, we have the issue of packets dropping. Lots of things can cause a packet to drop, including momentary noise somewhere. On the TR you have in addition the fact that when you boot an IBM PC (can't speak for your workstatinos), its relay clicks in and interrupts the network for a while. We think the token gets lost and has to be regenerated. At any rate, the delay -- although only a fraction of a second -- is still probably longer than the longest likely delay due to collisions. Ethernet is passive, so turning on and off a device does not cause any interruption. The net effect of all of this is that you probably want to set up a mockup or do a fairly detailed simulation. Or if the bandwidths involved are small enough, just rely on massive overkill. If the messages are small enough and don't happen that often, you've got enough extra bandwidth that it's unlikely you'll have any problems with either technology. But if you're at all close to the limits, what actually happens as you near overload is not the simple thing that TR propaganda implies.