<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>the first message should take <50 us.  the broadcast to 5 nodes should
<br></div>take 2-3 more 50 us times.  so at about 200 us, all the slaves will start<br>the DOS attack on the viewer node's nic...<br><div class="Ih2E3d"></div></blockquote><div><br>I am not sure why you compare this to a DOS attack.  The same amount of data (and roughly the same amount of packets) should be arriving at the viewer node.  Yes it is stressing the switch more, but this switch should be able to handle much more traffic than this.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>> But the bcast is always just sending 4 bytes (a single integer), and as
<br><br></div>no, afaik no mpi implementations actually utilize the eth-level bcast,<br>but rather implement bcast as a tree of (uni) sends.</blockquote><div><br>I realize this.  I was just pointing out that the the amount of data I am broadcasting is always 4 bytes.  Since I saw no hiccups when the final gather packets were only 4 bytes, but I do when the final gather packets are 1MB / N -- then the hiccups must be coming from the final gather and not the broadcast.
<br></div></div><br>