Andrew,<br><br><div><span class="gmail_quote">On 7/19/07, <b class="gmail_sendername">Andrew Friedley</b> <<a href="mailto:afriedle@open-mpi.org">afriedle@open-mpi.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hal Rosenstock wrote:<br>> I'm not quite parsing what is the same with what is different in the<br>> results<br>> (and I presume the only variable is SM).<br><br>Yes; this is confusing, I'll try to summarize the various behaviors I'm

<br>getting.<br><br>First, there are two machines.  One has 8 nodes and runs a Topspin<br>switch with the Cisco SM on it.  The other is 128 nodes and runs a<br>Mellanox switch with Open SM on a compute node.  OFED v1.2 is used on

<br>both.  Below is how many groups I can join using my test program<br>(described elsewhere in the thread)<br><br>On the 8 node machine:<br>8 procs (one per node) -- 14 groups.<br>16 procs (two per node) -- 4 groups.<br>

<br>On the 128 node machine:<br>8 procs (one per node, 8 nodes used) -- 14 groups.<br>16 procs (two per node, 8 nodes used) -- unlimited? I stopped past 750.<br><br>Some peculiarities complicate this.  On either machine, I've noticed

<br>that if I haven't been doing anything using IB multicast in say a day<br>(haven't tried to figure out exactly how long), in any run scenario<br>listed above, I can join 4 groups.  I do a couple runs where I hit

<br>errors after 4 groups, and then I consistently get the group counts<br>above for the rest of the work day.<br><br>Second, in the cases in which I am able to join 14 groups, if I run my<br>test program twice simultaneously on the same nodes, I am able to join a

<br>maximum of 14 groups total between the two running tests (as opposed to<br>14 per test run).  Running the test twice simultaneously using a<br>disjoint set of nodes is not an issue.</blockquote><div><br>

Thanks. I can only comment on the OpenSM configuration and in general

on SMs so I'm still not sure what limits you are hitting; it may be

multiple but not sure. Some seemed to be end node (HCA) related based

on a previous email.<br>

</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>> This makes me think the switch is involved, is this correct?<br>><br>

><br>> I doubt it. It is either end station, SM, or a combination of the two.<br><br>OK.<br><br>>> OK this makes sense, but I still don't see where all the time is going.<br>>>   Should the fact that the switches haven't been reprogrammed since

<br>>> leaving the groups really effect how long it takes to do a subsequent<br>>> join?  I'm not convinced.<br>><br>><br>> It takes time for the SM to recalculate the multicast tree. While leaves

<br>> can<br>> be lazy, I forget whether joins are synchronous or not.<br><br>Is the algorithm for recalculating the tree documented at all?  Or,<br>where is the code for it (assuming I have access)?  I feel like I'm

<br>missing something here that explains why it's so costly.</blockquote><div><br>

I'm afraid it is just the code AFAIK :-(<br>

<br>

-- Hal<br>

</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andrew<br><br>><br>> Is this time being consumed by the switches when the are asked to

>> reprogram their tables (I assume some sort of routing table is used >> internally)? > > > This is relatively quick compared to the policy for the SM rerouting of > multicast based on joins/leaves/group creation/deletion.

<br><br>OK.  Thanks for the insight.<br><br>Andrew<br></blockquote></div><br>