From: johnb@kalpana.com (John Bartas)
Subject: Re: Please explain....
Organization: Kalpana Inc
Date: Fri, 13 Nov 92 23:48:06 GMT

In article <ruq5gcg@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Oct31.223152.27162@kalpana.com>, johnb@kalpana.com (John Bartas) writes:
>> ...
>> 	Another disadvantage of Routers is that they need to receive
>> and store the entire frame, run it through their routing algorithm,
>> and then retransmit it on the destination segment....
>
>This is false.  You can do "cut through routing" with a router with
>almost as little buffering as with a raw MAC bridge.  There is
>absolutely no more reason for a router to wait for the entire packet
>before forwarding than for a bridge.

Now that you point it out, I should have said "usually" rather than
"need to". I'm not aware of any routers that don't work as I described
above, but my experience is limited to Modified PC's and BSD based
systems. Are there comercially available "cut through" routers? How much
do they cost?

>> 	The key point here is that the "switching" of segments [by a Kalpana]
>> is done
>> (in real time by an ASIC) based on the first 6 bytes of the frame, so
>> the frame's first bits have already been propagated on segment 2
>> while the last bits are still being sent by host A on segment 1. This
>> avoids the overhead of the "receive, store, process, & retransmit",
>> methodology of routers. 
>
>This is at least partly false.  If the output ethernet is busy, the
>Kalpana cannot start transmitting, and must "receive, store, process,
>and retransmit" the packet when the output ethernet is available.
>

It is true that a busy segment will force our asic to buffer a packet and
wait, but our customers usually try to arrange things so that this doesn't
happen too much. The ideal case would be to give every user his own
segment - on a protocol such as IPX, there would never be a "busy"
wait. 

>> 	Also, since packet forwarding latency is only a tiny fraction
>> of what it is on even the most high end routers, protocol performance
>> will tend to be better.
>
>Fooey.
>Please name a single application on any standard protocol that you please
>that runs measurably faster by reducing the switching delay from that
>seen in, for example, a DEC bridge to that seen in a Kalpana.
>

I've never used a DEC Bridge. I keep mentioning routers since that's
what I have personal experience with.

In a previous job I spent hours Telneting from a PC, over a PC-based 
router, across another busy ethernet, over another router, to a BSD based
host. Keystroke response was noticably more sluggish than working directly
on the host. This may be hard to relate to if you're using SGI machines
and FDDI, but a lot of people still have PC based ethernets. If I could
have broken up my three segments into, say, 30 segments with a couple of
Ether Switches, my telnet performance would have been a lot crisper.

>The marketing froth and distortions in this "description" of the
>Kalpana product has reduced my respect for the product.
>

marketing froth? I guess I should be flattered - I'm a full time
software engineer. It's nice to know if SNMP skills ever become
unemployable I can get a job writing add copy :-)

>The absolute silence on the cases where the Kalpana switch reduces
>ethernet performance is not admirable either.
>
>The silence on the difference between building a list of MAC source
>addresses and running spanning tree is reprehensible.
>

Is it reprehensible That after working 80 hours a week on coding
and testing that I don't have time to read and reply to the news 
as much as I'd like? Are you asking us to hire a full-time suit 
to write *REAL* marketing froth? I do this as a hobby when I get 
a few minutes between compiles. I just happen to work for Kalpana
and know a bit about the switch. Please cut me a little slack.

More to the point, A lot of the comments about Kalpana Switches
have been answered by netters with more bridging backround and
objectivity than myself. I answered the question "What is a 
Kalpana Etherswitch?" because I had some time that day and no 
one else gave it more than a sentence or two. 

>Vernon Schryver,  vjs@sgi.com
>
>Disclaimer:  I'm not of the bridging religion.


======================================================================
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
Newsgroups: comp.dcom.lans.ethernet