<br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Interesting theory but not one that can be easily tested since the<br>programs don't emit &quot;set up took N seconds&quot; and &quot;processing took M
<br>seconds&quot;.&nbsp;&nbsp; There's another chunk of the program which should<br>probably also count as &quot;set up&quot; which is the time needed at<br>each step for the nodes to reconcile their chunks of the model<br>before the next calculation.&nbsp;&nbsp;(My guess is that this last part doesn't
<br>scale well at all.)&nbsp;&nbsp;Perhaps you're counting this second thing in<br>your setup?&nbsp;&nbsp;In any case, I know that the _initial_ setup before the<br>steps run doesn't take all that long, since tail -f on the log file<br>shows the steps after not too many seconds, so the initial setup
<br>is not a key factor.&nbsp;&nbsp;The per step (re)setup can't be measured but<br>could be more significant.</blockquote><div><br>
The theory is that the setup stays constant as you increase the number
of steps, while the run time increases. So you can test the theory by,
as we've been suggesting all along, increasing the number of steps
you're running to see if the scaling you're seeing drastically
improves. It should.<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Again, I don't think it's actually any of these since the CPU time on<br>the compute nodes falls down towards zero.&nbsp;&nbsp;If they were setting up they
<br>would still be consuming CPU time. It looks a lot more like most of<br>the nodes stall while waiting for data before they can proceed<br>to the next step.</blockquote><div><br>
Much of the setup should be done by the head node before dividing up the tasks, I think.<br>
</div><br><br>
</div><br>