<font size=2 face="sans-serif">I'm actually a bit surprised that there
isn't already a '--enable-collective-argument-checks' configure option
that would default to "disabled".</font>
<br><font size=2 face="sans-serif"><br>
Michael Blocksome<br>
Blue Gene Messaging<br>
blocksom@us.ibm.com<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Jeff Hammond <jhammond@alcf.anl.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">devel@mpich.org, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">07/25/2013 01:59 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [mpich-devel]
Collective i/o failure</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">devel-bounces@mpich.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>BG-specific discussions?  I don't care what the
Forum thinks about an implementation detail that makes BG more productive
for our users.<br>
<br>
If MPIO_CHECK_OFFSET_ALL is optional and IBM chooses to enable it, what
does that matter to anyone else?<br>
<br>
Jeff<br>
<br>
----- Original Message -----<br>
> From: "Rob Ross" <rross@mcs.anl.gov><br>
> To: devel@mpich.org<br>
> Sent: Thursday, July 25, 2013 2:31:16 PM<br>
> Subject: Re: [mpich-devel] Collective i/o failure<br>
> <br>
> See historical discussions on collective argument checking. -- Rob<br>
> <br>
> On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote:<br>
> <br>
> > MPI_Allreduce on an integer should be almost infinitely fast
on BG<br>
> > so maybe an ifdef guard is all that is required to keep this
from<br>
> > standing in the way of widespread acceptance of MPI-IO.<br>
> > <br>
> > Best,<br>
> > <br>
> > Jeff<br>
> > <br>
> > ----- Original Message -----<br>
> >> From: "Rob Ross" <rross@mcs.anl.gov><br>
> >> To: devel@mpich.org<br>
> >> Sent: Thursday, July 25, 2013 2:03:40 PM<br>
> >> Subject: Re: [mpich-devel] Collective i/o failure<br>
> >> <br>
> >> Just to reiterate the point that RobL made: adding collectives
to<br>
> >> check for completion, etc. of other ranks adds overhead to
the<br>
> >> calls<br>
> >> when they are successful. This in turn makes people not use<br>
> >> MPI-IO,<br>
> >> because it becomes slower, which is good for reducing bug
reports,<br>
> >> but bad for encouraging use of standard interfaces.<br>
> >> <br>
> >> Rob<br>
> >> <br>
> >> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote:<br>
> >> <br>
> >>>> From: "Rob Latham" <robl@mcs.anl.gov><br>
> >>> <br>
> >>>> How did this single rank get a negative offset?  Was
there some<br>
> >>>> integer math that overflowed?<br>
> >>> <br>
> >>> That's for the app developer to figure out.  My
issue is that if<br>
> >>> all ranks had failed the write he probably would have
started<br>
> >>> figuring that out a few days ago and I wouldn't have
gotten<br>
> >>> involved :)   It's the weird hw error that dragged
me into this<br>
> >>> when the non-failing ranks entered allreduce in romio
and the<br>
> >>> failing ranks entered allreduce in the app.<br>
> >>> <br>
> >>> Like I said :<br>
> >>> <br>
> >>>>> Just wondering if there's something I can fix
here in addition<br>
> >>>>> to the<br>
> >>>>> application.<br>
> >>> <br>
> >>> Not the highest priority really.  But I coincidentally
just got<br>
> >>> another report (from ANL this time) that an app is hung
with half<br>
> >>> the ranks in write_at_all and half the ranks in a later
barrier.<br>
> >>> It could be something similar.  I don't have enough
information<br>
> >>> yet to know but I've suggested they look at errors from
write.<br>
> >>> <br>
> >> <br>
> >> <br>
> > <br>
> > --<br>
> > Jeff Hammond<br>
> > Argonne Leadership Computing Facility<br>
> > University of Chicago Computation Institute<br>
> > jhammond@alcf.anl.gov / (630) 252-5381<br>
> > </font></tt><a href=http://www.linkedin.com/in/jeffhammond><tt><font size=2>http://www.linkedin.com/in/jeffhammond</font></tt></a><tt><font size=2><br>
> > </font></tt><a href=https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond><tt><font size=2>https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</font></tt></a><tt><font size=2><br>
> > ALCF docs: </font></tt><a href="http://www.alcf.anl.gov/user-guides"><tt><font size=2>http://www.alcf.anl.gov/user-guides</font></tt></a><tt><font size=2><br>
> > <br>
> <br>
> <br>
<br>
-- <br>
Jeff Hammond<br>
Argonne Leadership Computing Facility<br>
University of Chicago Computation Institute<br>
jhammond@alcf.anl.gov / (630) 252-5381<br>
</font></tt><a href=http://www.linkedin.com/in/jeffhammond><tt><font size=2>http://www.linkedin.com/in/jeffhammond</font></tt></a><tt><font size=2><br>
</font></tt><a href=https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond><tt><font size=2>https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</font></tt></a><tt><font size=2><br>
ALCF docs: </font></tt><a href="http://www.alcf.anl.gov/user-guides"><tt><font size=2>http://www.alcf.anl.gov/user-guides</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>