<br><br><div class="gmail_quote">On Fri, Oct 1, 2010 at 3:35 AM, Mark Abraham <span dir="ltr">&lt;<a href="mailto:mark.abraham@anu.edu.au" target="_blank">mark.abraham@anu.edu.au</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br><br>----- Original Message -----<br>From: Roland Schulz &lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;<br></div><div>Date: Friday, October 1, 2010 16:58<br>Subject: Re: [gmx-developers] Collective IO<br>


To: Discussion list for GROMACS development &lt;<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a>&gt;<br><br><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br></div><div class="gmail_quote"><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>On Thu, Sep 30, 2010 at 9:19 PM, Mark Abraham <span dir="ltr">&lt;<a>mark.abraham@anu.edu.au</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">  <div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>----- Original Message -----<br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>From: Roland Schulz &lt;<a>roland@utk.edu</a>&gt;<br><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>Date: Friday, October 1, 2010 9:04<br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>Subject: Re: [gmx-developers] Collective IO<br><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>  To: Discussion list for GROMACS development &lt;<a>gmx-developers@gromacs.org</a>&gt;<br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


  <font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


</div><div class="gmail_quote"><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font>On Thu, Sep 30, 2010 at 6:21 PM, Szilárd Páll <span dir="ltr">&lt;<a>szilard.pall@cbr.su.se</a>&gt;</span> wrote:<br>


  <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font>  Hi Roland,<br>


   <font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font> Nice work, I&#39;ll definitely take a look at it!<br>


   <font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font> Any idea on how does this improve scaling in general and at what<br>


  <font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font> problem size starts to really matter? Does it introduce and overhead<br>


<font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font> in smaller simulations or it is only conditionally turned on?<br>


  </blockquote><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


</div><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font>At the moment it is always turned on for XTC when compiled with MPI. In serial or with threads nothing changes. At the moment we buffer at maximum 100 frames. If one uses less than 100 PP nodes than we buffer as many frames as the number of PP nodes. We also make sure that we don&#39;t buffer more than 250MB per node.</div>


    <div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font><br>


</div></div><div><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px"><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>&gt; </font>The 100 frames and 250MB are both constants which should probably still be tuned.<br>


  <font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br></div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>Indeed - and the user should be able to tune them, too. They won&#39;t want to exceed their available physical memory, since buffering frames to virtual memory (if any) loses any gains from collective I/O.<br>


</div>  </div></blockquote><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>Honestly we hadn&#39;t thought much about the 250MB limit. We first wanted to get feedback on the approach and the code before doing more benchmarks and tuning these parameters. It is very likely that their are no cases which benefit from using more than 2MB per MPI process.</div>


  <div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font><br></div><div><font style="font-style:normal;font-weight:normal;background-color:rgb(245, 248, 240);font-size:14px">&gt; </font>In case we limit the memory usage to 2MB should we still make it configurable? I think adding to many mdrun option gets confusing. Should we make the number of buffered frames a hidden mdrun option or an environment variable (the default would be that the number is auto-tuned)?<br>


<br></div></div>Hmmm. 2MB feels like quite a low lower bound.</div></blockquote><div>The buffering is done on every node before the data is collected to the IO nodes. Thus if you e.g. have 1000 nodes each buffering 2MB and you have 20 IO nodes each IO node gets 100MB.</div>


<div>The IO requirement of an IO node is the same as it is currently for the master. A whole frame has to fit into memory (an IO node never has more than one frame). This can of course be a problem but it is independent of the current approach.</div>


<div>As soon as someone writes code which allows to write a single frame in parallel this can be easily combined with our buffering approach and would overcome this memory requirement.</div><div><br></div><div>Thus our approach doesn&#39;t improve the current memory requirement. But it also doesn&#39;t increases the memory per process ( &lt;2MB) significantly. </div>

<div><br></div><div>Currently more than one IO node e (=1 MPI task on one core) can be placed on one physical node. We will improve this and limit it to one IO node per physical node (thus only maximum one core participates in the collective IO). This makes sure that also the total memory per shared memory node doesn&#39;t increase significantly.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"> Collective I/O requires of the order of several MB per process per operation to be worthwhile. </div>


</blockquote><div>yes. The IO nodes have that as long as one frame is not too small. For very small frames/few atoms Collective IO shouldn&#39;t be important. But performance might still improve because the XTC compression is done in parallel and the write frequency is reduced.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">OTOH you don&#39;t want to buffer excessively, because that loses more when hardware crashes occur. You do have the checkpoint interval as another upper bound, so that&#39;s probably fine. 250MB concerned me, because the BlueGene cpus have up to about 1GB per cpu...</div>

</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<br>I think a hidden option is probably best.<br></div></blockquote><div>OK. We do that (unless their&#39;ll be other opinions).</div><div><br></div><div>Roland </div></div>