Gigabit Switch

[Bogdan Costescu]

On Tue, 11 Nov 2003, Mark Hahn wrote:

> right, but irrelevant.  the topic is "is there any point to managable
> or otherwise fancy switches?"

Sorry, but I don't see the "irrelevant" part. You mentioned QOS/TOS and I 
replied that I don't see it as an advantage...

Anyway, another point is that unmanaged switches with large number of 
ports are not so common. Maybe your switch vendor can explain why ?

> TCP is good at dealing with out-of-order.  practically by by definition!

Sure. But at what cost ? Do you want to do some computation too on that 
node ? :-)
If you talk about multicast, you eliminate TCP from the discussion. Then 
how do you synchronize between data transmitted over TCP and some 
zero-payload (barrier) sent through other protocol ? The stack guarantees 
in-order delivery of data for the same socket, not for different sockets 
or even more for different protocols.

> the point is that the switch vendor claimed that full multicast was not
> lossy, contradicting Becker's claim.

Not only the switch has to be non-lossy but the stack as well. Packets can 
be dropped for example at network driver level (let's say Rx overrun) or 
simply transmission errors, so the forwarding logic in the switch is not 
involved. 

> this vendor specializes in large, big-backplane chassis switches, so
> they might be right.

I never thought of this but I can probably build a switch that never drops
a correctly received packet by putting insane amount of buffers on it. But
at what price (money as well as performance) ? And what do you do with 
transmission errors ?

> or do you want a single 30 us multicast?

Pardon me, but "reliable" and "single" do not match in my view. Reliable 
to me means that receiver acknowledges, which can be done by unicast or 
multicast again. And the problem (and latency) multiplies...

> I'd like to be able to let a user find out ...

You're too kind to your users :-)

I've never been given information related to communication problems on any
parallel computer I tried to make CHARMM run on for my group. Sure, I
often got CPU performance counters, but never communication parameters.

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu at IWR.Uni-Heidelberg.De




_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf