On Mar 9, 2008, at 3:39 PM, Gleb Natapov wrote:
1. There was a discussion about this on openfabrics mailing list and
the
conclusion was that what Open MPI does is correct according to IB/
iWarp
spec.
2. Is it possible to fix your FW to follow iWarp spec? Perhaps it is
possible to implement i
Oops -- my "delete old MTT stuff" script broke recently and allowed my
disks to fill up over the weekend. So there's a bunch of false
failures in Cisco's MTT from this weekend (builds failed because of
lack of disk space).
--
Jeff Squyres
Cisco Systems
Fixed. Thank for your hint, Ralf.
On Do, 2008-03-06 at 22:23 +0100, Ralf Wildenhues wrote:
> In ompi/contrib/vt/vt/extlib/otf/acinclude.m4, in the macros WITH_DEBUG
> and WITH_VERBOSE, dubious constructs such as
>
> AC_CACHE_CHECK([debug],
> [debug],
> [debug=])
>
> are used
Gleb Natapov wrote:
On Sun, Mar 09, 2008 at 02:48:09PM -0500, Jon Mason wrote:
Issue (as described by Steve Wise):
Currently OMPI uses qp 0 for all credit updates (by design). This breaks
when running over the chelsio rnic due to a race condition between
advertising the availability of a bu
Jeff Squyres wrote:
On Mar 9, 2008, at 3:39 PM, Gleb Natapov wrote:
1. There was a discussion about this on openfabrics mailing list and
the
conclusion was that what Open MPI does is correct according to IB/
iWarp
spec.
2. Is it possible to fix your FW to follow iWarp spec? Perhaps it is
On Mar 10, 2008, at 9:50 AM, Steve Wise wrote:
(just thinking out loud here): The OMPi code could be designed to
_not_
assume recv's are posted until the CPC indicates they are ready. IE
sort
of asynchronous behavior. When the recvs are ready, the CPC could
up-call the btl and then the cre
On Mar 10, 2008, at 9:57 AM, Steve Wise wrote:
A single PP QP might be fine for now, and chelsio's next-gen part will
support SRQs and not have this funky issue.
Good!
But why use such a large buffer size for a single PP QP? Why not use
something around 16KB?
You can do that, but you'll
Hi all,
Where is the "old" orte\mca\smr? I don´t found it in orte/mca/plm...
--
Leonardo Fialho
Computer Architecture and Operating Systems Department - CAOS
Universidad Autonoma de Barcelona - UAB
ETSE, Edifcio Q, QC/3088
http://www.caos.uab.es
Phone: +34-93-581-2888
Fax: +34-93-581-2478
Yes, it all got consolidated down into plm. We need to update the
FAQ; the ORTE frameworks changed quite a bit in the recent ORTE merge...
Ralph's on vacation this week. A detailed answer to your question may
not occur until he returns...
On Mar 10, 2008, at 10:05 AM, Leonardo Fialho wro
Hi Jeff,
I need to implement a heart bit/watchdog monitoring system, I´m looking
for the "best place" to put it and I don´t want to put duplicated code.
I´ll try to put it into PLM for now, and when I get a Ralph´s response I
change it, if necessary.
Jeff Squyres escribió:
Yes, it all got co
Hello,
I developed an interface to call MPI functions from deployed MATLAB
applications. It works for many MPI implementations and, fortunately,
OpenMPI is not an exception.
If you are interested in knowing more, I would very pleased in helping
the project.
Thank you for your great job.
Albe
On Mon, Mar 10, 2008 at 09:50:13AM -0500, Steve Wise wrote:
> > I personally don't like the idea to add another layer of complexity to
> > openib
> > BTL code just to work around HW that doesn't follow spec. If work around
> > is simple that is OK, but in this case it is not so simple and will add
Gleb Natapov wrote:
On Mon, Mar 10, 2008 at 09:50:13AM -0500, Steve Wise wrote:
I personally don't like the idea to add another layer of complexity to openib
BTL code just to work around HW that doesn't follow spec. If work around
is simple that is OK, but in this case it is not so simple and
Jeff Squyres wrote:
On Mar 10, 2008, at 9:57 AM, Steve Wise wrote:
A single PP QP might be fine for now, and chelsio's next-gen part will
support SRQs and not have this funky issue.
Good!
But why use such a large buffer size for a single PP QP? Why not use
s
On Mon, Mar 10, 2008 at 10:03:27AM -0500, Jeff Squyres wrote:
> On Mar 10, 2008, at 9:50 AM, Steve Wise wrote:
>
> > (just thinking out loud here): The OMPi code could be designed to
> > _not_
> > assume recv's are posted until the CPC indicates they are ready. IE
> > sort
> > of asynchronous
15 matches
Mail list logo
