<span class="gmail_quote">Ok guys, thanks for all the feedback. &nbsp;<br><br>I guess I should have provided some more specific details. &nbsp;I am using sockets with TCP/IP for the final gather stage. &nbsp;I am doing real-time (volume) rendering. &nbsp;The images are 32-bit (RGBA with 8 bits per channel). &nbsp;The machines are running the 
2.6 kernel and I have confirmed that the max TCP send/recv buffer sizes are 4MB (more than enough to store the full 512x512 image).<br><br>I wrote&nbsp;two simple test programs to make sure that it was not something else in my rather complex rendering pipeline (memory allocation etc.). &nbsp;The server side test program launches N nodes using mpich2, each of which establishes a connection to the view client with a socket over TCP/IP. Then I loop with the client side program sending a single integer to rank 0, then rank 0 broadcasts this integer to the other nodes, and then all nodes send back 1MB / N of data.
<br><br>To make sure there was not an issue with the MPI broadcast, I did one test run with 5 nodes only sending back 4 bytes of data each. &nbsp;The result was a RTT of less than 0.3 ms. Next I did a run with one node sending 1 MB back to the client, the result was an RTT of less than 12ms. &nbsp;Letting the test run in a loop I saw that the first ~100 packets were a bit slower (~16 ms) and then not a single packet took longer than 14 ms. &nbsp;So the performance was very consistent, as expected for a single node. Then I did a run with two nodes sending back  1/2 MB each, the result was an RTT of ~16 ms on frames without a hiccup. &nbsp;About 
0.2% of the frames were hiccups. On a run with 3 nodes sending back 1/3 MB each I got an RTT of ~19-20 ms and again&nbsp;about&nbsp;0.2%&nbsp;of&nbsp;the&nbsp;frames&nbsp;were&nbsp;hiccups. With&nbsp;4&nbsp;nodes&nbsp;sending&nbsp;1/4&nbsp;MB&nbsp;each&nbsp;I&nbsp;got&nbsp;an&nbsp;RTT&nbsp;of&nbsp;~20-21&nbsp;ms&nbsp;and&nbsp;about&nbsp;
3.5%&nbsp;of&nbsp;the&nbsp;frames&nbsp;were&nbsp;hiccups. Finally with 5 nodes sending 1/5 MB each I got an RTT of ~21ms and about 13.5% of the frames were hiccups. &nbsp;I could not test on more nodes as the other computers were in use by other people.
<br><br>One interesting pattern I noticed is that the hiccup frame RTTs, almost without exception, fall into one of three ranges (approximately 50-60, 200-210, and 250-260). Could this be related to exponential back-off?<br>
<br>Tommorow I will experiment with jumbo frames and flow control settings (both of which the HP Procurve claims to support). &nbsp;If these do not solve the problems I will start sifting through tcpdump.<br><br>Thanks,<br>Brendan
<br></span><br>


!DSPAM:47689b2e158461735719037!