bogdan.costescu at iwr.uni-heidelberg.de
Wed Nov 12 07:54:07 EST 2003
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
> 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.
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
More information about the Beowulf