<div dir="ltr">Ok, on a whim I tried reconfiguring in home again this morning but from a different login node. There was no load last night (on ext4) and none this morning (on ext5), but now my configure time from /ccs/home/nate is 13m. While not appreciably better than the /lustre time, it is suddenly much faster than the 41m I sent previously. <div><br></div><div>Strikes me that this kind of experience is what confuses/frustrates users.</div><div><br></div><div>Nate<br><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 8:20 AM, Nathan Collier <span dir="ltr"><<a href="mailto:nathaniel.collier@gmail.com" target="_blank">nathaniel.collier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Barry,<div><br></div><div>No problem. </div><div><br></div><div>No packages / master and on /ccs/home/nate</div><span class=""><div><br></div><div><span style="font-size:13.200000762939453px">[nate@titan] time python no_packages.py</span><br></div><div><span style="font-size:13.200000762939453px">...</span></div></span><div><div>real<span style="white-space:pre-wrap">  </span>41m38.700s</div><div>user<span style="white-space:pre-wrap">   </span>1m50.075s</div><div>sys<span style="white-space:pre-wrap">     </span>1m30.034s</div></div><span class=""><div><br></div><div>[nate@titan] time make all</div><div>...</div></span><div><div>real<span style="white-space:pre-wrap">     </span>9m4.977s</div><div>user<span style="white-space:pre-wrap">     </span>5m56.686s</div><div>sys<span style="white-space:pre-wrap">     </span>28m22.310s</div></div><div><br></div><div>In addition to a much slower configure time, the home areas are not accessible to batch submissions. So without the reconfigure script, I could not do a full build from home.</div><div><br></div><div>Nate</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 11:19 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
 Nathan,<br>
<br>
    Can you please do a configure make on your home directory system?<br>
<br>
     It could be since Lustre is a parallel filesystem designed for high bandwidth IO from a parallel computer it is just bad for compiles etc.<br>
<br>
  Barry<br>
<br>
<br>
<br>
<a href="https://www.olcf.ornl.gov/support/getting-started/" target="_blank">https://www.olcf.ornl.gov/support/getting-started/</a><br>
<br>
home areas<br>
Home areas/directories are provided on a Network File System (NFS). The user home areas are by default accessible only to the owning user. Similarly the project home areas are accessible by only member of the project. The areas are backed-up but available space is limited. Because space is limited, each area has a quota. Users should store small source code, scripts, and other similar items in the area. Users should not store large job output or input in the area. Job I/O should be performed in the system’s temporary work area.<br>
work areas<br>
Temporary work directories are provided to each user and project on Lustre file systems. Similar to the home areas, by default, the user and project areas are accessible to the user and project members. The areas provide a large amount of storage, but are not backed-up. In general, job I/O performance will be faster in the lustre areas than the NFS mounted home areas. The temporary work areas are regularly purged of data that has not been recently accessed, because of this all needed data should be backed-up to the HPSS.<br>
<div><div><br>
<br>
> On Feb 26, 2015, at 10:00 PM, Nathan Collier <<a href="mailto:nathaniel.collier@gmail.com" target="_blank">nathaniel.collier@gmail.com</a>> wrote:<br>
><br>
> > They never told you to do compiles on particular file systems or anything?  For example did they ever say DON'T compile on the lustre file system?<br>
><br>
> I have not received any guidance about where to or not to compile. A quick perusing of the user guide doesn't make that clear to me. If it isn't already obvious, I am far from a Titan expert :)<br>
><br>
> Do you know someone here at ORNL who I can talk to to make sure I am not missing something silly?<br>
><br>
> > Perhaps the 52m 'sys' time could be luster overhead<br>
><br>
> It could be, I have heard a lot of complaints about this from people who need to write output or read from files in their applications.<br>
><br>
> Nate<br>
><br>
><br>
> On Thu, Feb 26, 2015 at 10:36 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> On Thu, 26 Feb 2015, Barry Smith wrote:<br>
><br>
> ><br>
> > > On Feb 26, 2015, at 9:16 PM, Nathan Collier <<a href="mailto:nathaniel.collier@gmail.com" target="_blank">nathaniel.collier@gmail.com</a>> wrote:<br>
> > ><br>
> > > Barry,<br>
> > ><br>
> > > > Do you know where /tmp is on the system? Presumably it is fast?<br>
> > ><br>
> > > I am not sure about that. There is a /tmp but I am not sure what it is or if/how I can use it.<br>
> ><br>
> >    They never told you to do compiles on particular file systems or anything?  For example did they ever say DON'T compile on the lustre file system?<br>
><br>
> Ah - I misunderstood earlier. You'd like to have a petsc clone in /tmp<br>
> - and do the build there - and compare the difference [with the<br>
> current luster build].<br>
><br>
> Perhaps the 52m 'sys' time could be luster overhead - and that woud<br>
> disappear with a petsc build in /tmp. [and could be much faster].<br>
><br>
> Satish<br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>