Ben you didn't read my latter email, which I conceded that I was talking something different than what was being presented. You have probably gotten that far now so.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Benjamin J. Weiss > Sent: Tuesday, September 30, 2003 2:44 PM > To: [EMAIL PROTECTED] > Subject: RE: Network Setup Opinion Needed > > > > This is not quite always the case. Ethernet's CSMA/CD (Carrier Sense > > > Multiple Access with Collision Detection) was invented during a time > when > > > a hub or bus were the primary method of connection. Collision was > indeed > > > a problem then, and keeping the LAN small was a way to ensure network > > > performance. > > > > > > However, these days, switches are much cheaper and are easily within > the > > > reach of most organizations. > > > > > > If your users are hooked up to a switch instead of a hub, you can > ignore > > > the "collisions problem", as it no longer exists. At that point, the > > > limiting factors are the speed/RAM of the gateway and the speed/RAM of > the > > > switch. > > > > > > A good, short explanation can be found at > > > http://www.duxcw.com/faq/network/hubsw.htm > > > > > > > > > Ben > > > > > Actually CSMA/CD is the problem on a large single area network. I read > the > > article and see the point. Here is the problem. When a node transmits > it > > first listen for no traffic then it tries to transmit, if a collision > occurs > > then it goes into an algorithm to make a attempt again after it selects > it's > > new time slot, well the larger the number of nodes the greater the > > probability that they will select the same time slot and cause a > collision > > again. Etc. etc .... Therefore large networks always bottle neck under > > Ethernet and that is why no company will place a large number of > computers > > in the same area no matter what the transport medium is. There is > always a > > optimum number that should be in an area before it is broken down. > That's > > the theory. > > Otto, > > I'm sorry, but you have absolutely no idea as to how ethernet works in a > *switched* environment. You are describing a LAN that is on a hub. In > that case, you are correct with all of your above comment. > > On the other hand, in a situation where all of the hosts are connected to > a *switch*, instead of a hub, then each "segment" consists of exactly two > devices: the host and the switch port. In that case, the chance for > collision is greatly reduced. The reason for this is simple: > > If host-a transmits a packet while connected to a hub, then all other > hosts connected to that hub will see the packet, whether or not it is > intended for them. > > If host-a transmits a packet while connected to a switch, then something > entirely different happens. The switch looks at the packet and decides > where it is to go. If it is a multicast or broadcast packet, then most or > all of the other hosts on the switch will see it (I won't go into those > rules, it's beyond the scope of this particular discussion.) > > If, on the other hand, it is a *unicast* packet, and the destination host > is on the switch, then the switch will only transmit it on the port to > which that destination host is connected. If the host is not connected to > the switch, then it will send it on it's "uplink" port, depending upon > configuration. > > Now, what this means is that any host that is connected to a switch will > only see broadcast traffic, multicast traffic to which it is subscribed, > or unicast traffic that is addressed to it. This sharply decreases the > number of packets that the host's ethernet card will see as inbound, which > will thereby reduce the number of collisions during transmission and > subsequently increase the perceived bandwidth. > > At that point the bottleneck becomes the switch's backplane capabilities, > not collisions. > > Switched ethernet is vastly superior to ethernet on a hub, and has become > very cheap. It is now easily in reach for most organizations, including > the home office. > > Ben > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
