haas@cs.utah.edu (Walt Haas) (08/12/90)
I just finished reading an article in the August issue of Data Communications about a thing called an EtherSwitch, made by Kalpana Inc. in Campbell, CA. The article was written by the inventor of the device and President of Kalpana, so perhaps it wasn't totally objective about the pros and cons of this approach :-). The EtherSwitch functions like an Ethernet bridge with 6 ports. It is not a store-and-forward device, but instead looks at the address bits of the packet coming in from a port and decides which port to send it out. The article says (p 84) "...switched packets are delayed an average of only 40 microseconds; packets handled by a bridge are delayed an average of 800 microseconds, the time it takes to read and forward an entire packet." That's all fine if the destination Ethernet port does not have traffic at the time the packet appears. However, let's suppose that the destination port is busy at the time the packet arrives there. It seems to me as I think about this device, that a collision will be detected 40 microseconds into the packet. Assuming the EtherSwitch propagates a jam back into the source port, there remains only 6 microseconds for that jam to propagate all the way to the far end of the source Ethernet. According to my quackulations :-) that limits the Ethernet to less than the usual length... maybe a couple of 500 meter segments and one repeater. And he said that 40 microseconds was "average", implying that half the time the delay is greater... Does anybody in netland understand these things? I'd appreciate any enlightenment! -- Walt Haas haas@cs.utah.edu
morgan@jessica.stanford.edu (RL "Bob" Morgan) (08/14/90)
> The EtherSwitch functions like an Ethernet bridge with 6 ports. It is > not a store-and-forward device, but instead looks at the address bits > of the packet coming in from a port and decides which port to send it > out. The article says (p 84) "...switched packets are delayed an > average of only 40 microseconds; packets handled by a bridge are > delayed an average of 800 microseconds, the time it takes to read and > forward an entire packet." Walt mentions one problem with such a device, that the net to be forwarded to may be busy at the time a frame is to be forwarded. This is even more likely in the case of a multicast frame. I can only guess that such a beast would have to be able to buffer at least as many frames as an ordinary bridge to deal with this situation. In fact, since it has 6 ports, its buffer would have to be a lot bigger. The "no-delay" switching would really just be an optimization in the case of finding the destination network free. Another problem with this gizmo is collisions. Since an Ethernet frame is still vulnerable to collision up to its 42nd (or so) data byte, this switch would often propagate collision fragments from one net to another, which a proper bridge would not do. This would result in an over-busy net spewing collision fragments to others, which seems undesirable. Maybe the switch waits until after the minimum frame size time (ie, max round-trip time) to start forwarding? Of course, frames with bad CRCs get forwarded too. Again, this would spread the effects of a marginal net to others. I guess it's still true that you don't get sup'm fer nut'n. - RL "Bob" Morgan Networking Systems Stanford