From: johnb@kalpana.com (John Bartas)
Subject: Re: Please explain....
Organization: Kalpana Inc
Date: Thu, 19 Nov 92 04:59:54 GMT

In article <1992Nov16.235124.1097@netcom.com> seifert@netcom.com (Rich Seifert) writes:
>In article <1992Nov14.015208.17875@kalpana.com>, johnb@kalpana.com (John Bartas) writes:
>> In article <1992Nov4.221611.21276@megatek.com> randy@megatek.com writes:
>> >In article <1992Oct31.223152.27162@kalpana.com> johnb@kalpana.com (John Bartas) writes:
>> >[...]
>> Another point is lantency. We measure our latency forwarding a 1514 byte
>> frame at less than 40 microseconds. Bridges we have measured run between
>> 200-400 Microseconds. We get this speed via the method I described
>> previously. I *think* many bridges wait until they have received the
>> entire frame before they resend.
>>
>
>Hmm. The TRANSMISSION time of a 1514 byte frame is 1.2 ms (1221 us),
>including CRC and preamble. How could anyone measure its latency
>(first bit in-to-first bit out) at 200-400 us on a traditional
>(store and forward) bridge? Are you saying that it is 200-400 us
>PLUS the transmission time? This is far worse than most bridges
>(any bridge which can't get the packet out before the next one comes
>in can't run at wire speed, and there are many products which DO run
>at wire speed. I don't believe your numbers.
>

	I just get these numbers from hardware guys in our test group,
who (I hope) know more about bridges than I do. I think I'll try to get 
them to start reading this group so that I can stop posting vague numbers
from them which I have to go back and defend later. Why doesn't
someone ask a software question? :-}

Anyway... We were measuring first bit in-to-first bit out. 
The 200 us. number turns out to be from
a product that advertises itself as a switch, not a bridge. I'm not
sure what sort of bus (or matrix) it uses internally, but clearly it
can start transmission on the target segment before the whole frame
has been received on the source segment. The 400 us. number was
from a "Bridge" but this may have been an average latency time rather
than a worst case (1514 byte) time. Our 40 us time stays pretty 
constant for all packet sizes (so I'm told). Anyway I should have said
"competing products" rather than bridges, and it seems I may be wrong 
on the idea that most bridges "store & forward". Am I correct in assuming,
then, that most bridges start retramsmission before the whole frame is 
received? If so, how do they avoid internal bus contention? Or am I 
mistaken in thinking they are bus based?

>> I would be very interested if someone who knows more about conventional
>> bridges than I do could try to define exacltly what makes a given
>> device a hub|bridge|switch. I'm aware of other companies building
>> switches; I'd like to hear what they think.
>> 
>>
>
>Fromn a "black box" perspective, there is really no difference between
>a switch and a fast bridge. Except that some switches don't implement
>the Spanning Tree protocol and can cause sever network disruption in
>certain configurations.
> 

As I learn more about bridges, I must conclude that you are right.
My understanding is that A Hub differs from these two (bridge & switch)
in that it forwards all frames onto all segments and thus limits the 
aggregate bandwidth of all attached segments to 10 Mbits (at least until the
100 Mbit products start shipping). A Bridge(I think) or Switch can deliver 
an aggregate bandwidth of more than 10 Mbits. 

Perhaps what we should be measuring is how much usable bandwidth the various 
switch/bridge products provide. If two comparably priced products 
provide bandwidths that are significantly different, say a factor of 
two apart, the faster product clearly has applications that the slower
one does not. We do some testing of that sort here, Our current top of 
the line box claims 70 Mbits/sec under ideal conditions. (The hardware
guys tell me :-}. I'll let our competitors speak for themselves.

>
>
>-- 
>Rich Seifert                    Networks and Communications Consulting
>seifert@netcom.com              (408) 996-0922
>                                (408) 996-2860 FAX
>"... specialists in Local Area Networks and Data Communications systems"

======================================================================
John Bartas                     | Disclaimer - I don't speak for Kalpana
Pricipal Software Engineer      | in any official capacity. I'm just
Kalpana, Inc. (408)988-1600x141 | an employee who reads the net.

"We have met the enemy, and he is us." -Pogo