To let everyone else know...
We unfortunately ran into a blocker bug today, literally right before
1.3.1 went out the door. Doh!
https://svn.open-mpi.org/trac/ompi/ticket/1832
--
Jeff Squyres
Cisco Systems
I'm going to stay out of the debate about whether Andy correctly
characterized the two points you brought up as a distributed OS or not.
Sandia's position on these two points remains the same as I previously
stated when the question was distributed OS or not. The primary goal of
the Open MPI
Ahh...replied to the MTT segv thread...but will reiterate here: George & I
talked and we are in agreement that we should go ahead and release 1.3.1 as
it currently stands.
Now on to 1.3.2!
--brad
On Thu, Mar 12, 2009 at 7:52 AM, Jeff Squyres wrote:
> So -- RM's -- can we release 1.3.1? The t
I think that this is relatively contained and has not been seen out of MTT
under normal operating conditions. Also, as Jeff has argued, it doesn't
appear to be a regression against 1.3. George & I talked about this and we
are in agreement that we should go ahead and release 1.3.1 as it currently
I am assuming that by distributed OS you are referring to the changes that
we (not just ORNL) are trying to do. If this is the case, this is a
mischaracterization of the of out intentions. We have two goals
- To be able to use a different run-time than ORTE to drive Open MPI
- To use the com
I think I have to agree with Terry.
I love to inspire and see new, original, and unintended uses for Open
MPI. But our primary focus must remain to create, maintain, and
continue to deliver a high performance MPI implementation.
We have a long history of adding "small" things to Open MPI t
Sun's participation in this community was to obtain a stable and
performant MPI implementation that had some research work done on the
side to improve those goals and the introduction of new features. We
don't have problems with others using and improving on the OMPI code
base but we need to
On Mar 11, 2009, at 12:19 PM, Eugene Loh wrote:
I don't understand what's going on, but I guess each process is
calling
sm_btl_first_time_init(), during which it initializes its own
shm_bases
value, FIFOs, and shm_fifo pointer. If a remote process saw those
memory operations in that order,
So -- RM's -- can we release 1.3.1? The tarball is ready (it's made
at the same time as RC tarballs to guarantee that it's the same). All
that's necessary is posting it to the web site and sending out the
announcement.
--
Jeff Squyres
Cisco Systems
