Nick,
IMHO, the major issue here is the support for "static" data objects.
This requirement gets directly translated to the XPMEM support for the
platform, otherwise it is very challenging to get it implement.
OpenMPI/OSHMEM provides support for xpmem (actually there is more than
one transport), b
Hi Nick,
> I agree that symmetric objects in the data segment are a challenging issue.
> Could dynamically-allocated symmetric objects be supported much more easily?
Indeed. At least on the technical level you don't depend on a 3rd
party kernel module.
> Does Open MPI / OSHMEM already have cross
Does it mean that contributors don't have to sign contributor agreement ?
On Tue, Oct 11, 2016 at 2:35 PM, Geoffrey Paulsen
wrote:
> We have been discussing new Bylaws for the Open MPI Community. The
> primary motivator is to allow non-members to commit code. Details in the
> proposal (link be
not have to
> sign the contributor agreement, but instead will have to provide a signed
> patch.
>
> George.
>
>
> On Wed, Oct 12, 2016 at 9:29 AM, Pavel Shamis
> wrote:
>
>> Does it mean that contributors don't have to sign contributor agreement ?
>
>
> There might be no more contributor agreement at all...
> (See the discussion on the devel-core ML)
>
My concern (based on experience) that this may prevent some organization
from contribution. Obviously people would have to take this back to legal,
which may lead to a "freeze" in terms of cont
ting CLA with the new one ?"
> If we vote to do so, then everyone will have to sign-off their commits,
> regardless they previously had (or not) signed a CA
>
> Cheers,
>
> Gilles
>
>
> On Wednesday, October 12, 2016, Pavel Shamis
> wrote:
>
>> a. As a d
mber” (e.g., you are a “contributor” status), then this
> is only informational. We respect and want your input, but you don’t
> actually have a vote on this matter.
>
> HTH
> Ralph
>
>
> On Oct 12, 2016, at 7:24 AM, Pavel Shamis wrote:
>
> Well, at least on my side
>
> You mentioned that such a change will block contributions. Did you mean
> only temporarily, while individual Contributor/Member organization legal
> departments are reviewing the new terms? If so, that one-time "cost" may
> be acceptable, since the goal of the new terms are designed to put us
I think one of the main add-ons of the CLA over BSD-3 license was the
clause #3 (Grant of Patent License). As far as I can tell it does not
appear in the new sign-off-CLA.
On Wed, Oct 12, 2016 at 11:06 AM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> On Oct 12, 2016, at 9:02
gt;
> > On Oct 12, 2016, at 12:14 PM, Pavel Shamis
> wrote:
> >
> > I think one of the main add-ons of the CLA over BSD-3 license was the
> clause #3 (Grant of Patent License). As far as I can tell it does not
> appear in the new sign-off-CLA.
> >
> > On We
Personally, I haven't tried iWARP, I just don't have this HW. As far as I
can remember, one of the "special" requirements for iWARP's NICs is
RDMACM. UCT does have support for RDMACM, but somebody have to try and see
if there are any other gaps.
P.
On Fri, Apr 6, 2018 at 8:17 AM, Jeff Squyres (js
Adding Alina and Yossi.
On Thu, Aug 9, 2018 at 2:34 PM Vallee, Geoffroy R.
wrote:
> Hi,
>
> I tested on Summitdev here at ORNL and here are my comments (but I only
> have a limited set of data for summitdev so my feedback is somewhat
> limited):
> - netpipe/mpi is showing a slightly lower bandwi
It looks to me like mxm related failure ?
On Thu, Aug 16, 2018 at 1:51 PM Vallee, Geoffroy R.
wrote:
> Hi,
>
> I ran some tests on Summitdev here at ORNL:
> - the UCX problem is solved and I get the expected results for the tests
> that I am running (netpipe and IMB).
> - without UCX:
>
More UCX packages:
Fedora: http://rpms.famillecollet.com/rpmphp/zoom.php?rpm=ucx
OpenSUSE: https://software.opensuse.org/package/openucx
On Thu, Sep 20, 2018 at 7:53 AM Yossi Itigin wrote:
> Currently the target is RH 8
> And yes, UCX is also available on EPEL, for example:
> https://centos.pkg
I tried to build latest OFED with new ompi rc4, but is looks that vtune
code is broken again ?
gcc -DHAVE_CONFIG_H -I. -I.. -I../tools/opari/lib -I../extlib/otf/otflib
-I../extlib/otf/otflib -D_GNU_SOURCE
-DBINDIR=\"/usr/local/mpi/gcc/openmpi-1.3.1rc4/bin\"
-DDATADIR=\"/usr/local/mpi/gcc/
Adding pointer to OFED bugzilla ticket for more information:
https://bugs.openfabrics.org/show_bug.cgi?id=1537
Jeff Squyres wrote:
VT guys --
It looks like we still have a compile bug in OMPI 1.3.1rc4... See below.
Do you think you can get a fix ASAP for OMPI 1.3.1final?
Begin forwarded me
I would like to add my 0.02 to this discussion.
The "code stability" it is not something that should stop project from
development and progress. During MPI Project live we already saw some
pretty critical changes (pml/btl/etc...) and as result after all we have
more stable and more optimized MPI.
I think you problem is related to this bug:
https://svn.open-mpi.org/trac/ompi/ticket/1823
And it is resolved on the ompi-trunk.
Pasha.
Steve Wise wrote:
When this happens, that node logs this type of message also in
/var/log/messages:
IMB-MPI1[8859]: segfault at 0018 rip 2b
lt.
So I think this is a new bug.
Lemme pull the trunk and try that.
Pavel Shamis (Pasha) wrote:
I think you problem is related to this bug:
https://svn.open-mpi.org/trac/ompi/ticket/1823
And it is resolved on the ompi-trunk.
Pasha.
Steve Wise wrote:
When this happens, that node logs th
Thanks Jeff !
Jeff Squyres wrote:
We just added a mirror web site in Israel. That one was fun because
they requested to have their web tagline be in Hebrew.
Fun fact: with this addition, Open MPI now has 14 mirror web sites
around the world.
http://www.open-mpi.org/community/mirrors/
Most of the IB protocols used by MPI target a LID. There is no
existing notification path I know of that can replace LID-xyz with
LID-123. The subnet manager might be able to do this but begs
security issues.
Interesting problem.
It is not exactly correct. For migration between port
Open MPI currently needs to have connected fabrics, but maybe that's
something we will like to change in the future, having two separate
rails. (Btw Pasha, will your current work enable this ?)
I do not completely understand what do you mean here under two separate
rails ...
Already today you
Nifty Tom Mitchell wrote:
On Tue, Jun 09, 2009 at 04:33:51PM +0300, Pavel Shamis (Pasha) wrote:
Open MPI currently needs to have connected fabrics, but maybe that's
something we will like to change in the future, having two separate
rails. (Btw Pasha, will your current work enable
Hi,
You can select ib device used with openib btl by using follow parametres:
MCA btl: parameter "btl_openib_if_include" (current value: , data
source: default value)
Comma-delimited list of devices/ports to be
used (e.g. "mthca0,mthca1:2"; empty value means to
Rolf,
Did you compare latency/bw for failover-enabled code VS trunk ?
Pasha.
Rolf Vandevaart wrote:
Hi folks:
As some of you know, I have also been looking into implementing
failover as well. I took a different approach as I am solving the
problem within the openib BTL itself. This of cour
this week.
Pasha
Rolf
On 08/03/09 11:14, Pavel Shamis (Pasha) wrote:
Rolf,
Did you compare latency/bw for failover-enabled code VS trunk ?
Pasha.
Rolf Vandevaart wrote:
Hi folks:
As some of you know, I have also been looking into implementing
failover as well. I took a different approach
On my systems I see follow error:
gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include
-I../../../../orte/include -I../../../../ompi/include
-I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../..
-O3 -DNDEBUG -Wall -Wundef -Wno-long-long -Wsign-compare
-Wmissing-prototypes -Wstri
It was broken :-(
I fixed it - r22119
Pasha
Pavel Shamis (Pasha) wrote:
On my systems I see follow error:
gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include
-I../../../../orte/include -I../../../../ompi/include
-I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../..
-O3
Jeff,
Can you please check that we do not brake iwarp devices functionality ?
Pasha
Vasily Philipov wrote:
The attached patch adds support for RDMAoE (RDMA over Ethernet)
devices to Openib BTL. The code changes are very minimal, actually we
only modified the RDMACM code to provide better suppo
Jeff Squyres wrote:
On Nov 11, 2009, at 8:13 AM, Terry Dontje wrote:
Sun's IB group has asked me to forward the following email to see if
anyone has any comments on this email.
Tastes great / less filling. :-)
I think (assume) we'll be happy to implement changes like this that
come from th
Jeff,
During the original code review we found ,that by default we allocate
SRQ with size "rd_num + sd_max" but
on the SRQ we post only rd_num receive entries. It means that we do not
fill the queue completely. Looks like a bug.
Pasha
Jeff Squyres wrote:
SRQ hardware vendors -- please review
In the ompi_proc_t structure (ompi/proc/proc.h:54) we keep pointer to
proc_pml - "struct mca_pml_base_endpoint_t* proc_pml" . I tired to find
definition for "struct mca_pml_base_endpoint_t" , but I failed. Does
somebody know where is it defined ?
Regards,
Pasha
ignore it.
george.
On Dec 7, 2009, at 08:30 , Timothy Hayes wrote:
Sorry, I think I read your question too quickly. Ignore me. :-)
2009/12/7 Timothy Hayes
Is it not a forward definition and then defined in the PML components
individually based on their own requirements?
2009/12/7 Pavel
2009/12/7 Timothy Hayes
Is it not a forward definition and then defined in the PML components
individually based on their own requirements?
2009/12/7 Pavel Shamis (Pasha)
In the ompi_proc_t structure (ompi/proc/proc.h:54) we keep pointer to proc_pml - "struct
mca_pml_base_endpoint_t* proc_pml&
ry, I think I read your question too quickly. Ignore me. :-)
2009/12/7 Timothy Hayes
Is it not a forward definition and then defined in the PML components
individually based on their own requirements?
2009/12/7 Pavel Shamis (Pasha)
In the ompi_proc_t structure (ompi/proc/proc.h:54) w
Jeff Squyres wrote:
Note that I just moved #2163 into "blocker" state because the bug breaks any
non-SRQ-capable OpenFabrics device (e.g., both Chelsio and Neteffect RNICs). The bug came in
recently with the "resize SRQ" patches.
Mellanox / IBM: we are branching for 1.5 tomorrow. Can this bu
I'm checking this issue.
Pasha
Joshua Hursey wrote:
I just noticed that the nightly tarball of v1.4 failed to build in the OpenIB
BTL last night. The error was:
-
btl_openib_component.c: In function 'init_one_device':
btl_openib_component.c:2089: error: 'mca_btl_openib_compone
Please see below.
When using XRC queues, Open MPI is indeed creating only one XRC queue
per node (instead of per-host). The problem is that the number of send
elements in this queue is multiplied by the number of processes on the
remote host.
So, what are we getting from this ? Not much, e
Sylvain Jeaugey wrote:
The XRC protocol seems to create shared receive queues, which is a
good thing. However, comparing memory used by an "X" queue versus
and "S" queue, we can see a large difference. Digging a bit into the
code, we found some
So, do you see that X consumes more that S ? This
a
Sylvain Jeaugey wrote:
On Mon, 17 May 2010, Pavel Shamis (Pasha) wrote:
Sylvain Jeaugey wrote:
The XRC protocol seems to create shared receive queues, which is a
good thing. However, comparing memory used by an "X" queue versus
and "S" queue, we can see a large difference
Jeff Squyres wrote:
On Jun 13, 2007, at 2:41 PM, Gleb Natapov wrote:
Pasha tells me that the best times for Ishai and him are:
- 2000-2030 Israel time
- 1300-1300 US Eastern
- 1100-1130 US Mountain
- 2230-2300 India (Bangalore)
Although they could also do the preceding half hour as well.
Hi,
Try to increase the IB time out parameter: --mca btl_mvapi_ib_timeout 14
If the 14 will not work , try to increase little bit more (16)
Thanks,
Pasha
Neil Ludban wrote:
Hi,
I'm getting the errors below when calling MPI_Alltoallv() as part of
a matrix transpose operation. It's 100% repeata
Jeff Squyres wrote:
Background: Pasha added a call in the openib BTL finalize function
that will only succeed if all registered memory has been released
(ibv_dealloc_pd()). Since the test app didn't call MPI_FREE_MEM,
there was some memory that was still registered, and therefore the
call
Just committed r15557 that adds finalize
flow to mpool. So now openib should be able to release
all resources in normal way.
Pasha
Pavel Shamis (Pasha) wrote:
Jeff Squyres wrote:
Background: Pasha added a call in the openib BTL finalize function
that will only succeed if all registered
Any objections? We can discuss what approaches we want to take
(there's going to be some complications because of the PML driver,
etc.); perhaps in the Tuesday Mellanox teleconf...?
My main objection is that the only reason you propose to do this is some
bogus benchmark?
Palla
Jeff Squyres wrote:
FWIW: we fixed this recently in the openib BTL by ensuring that all
registered memory is freed during the BTL finalize (vs. the mpool
finalize).
This is a new issue because the mpool finalize was just recently
expanded to un-register all of its memory as part of the NIC
Jeff Squyres wrote:
I guess reading the graph that Pasha sent is difficult; Pasha -- can
you send the actual numbers?
Ok here is the numbers on my machines:
0 bytes
mvapich with header caching: 1.56
mvapich without header caching: 1.79
ompi 1.2: 1.59
So on zero bytes ompi not so bad. Also
George Bosilca wrote:
On Aug 13, 2007, at 11:28 AM, Pavel Shamis (Pasha) wrote:
Jeff Squyres wrote:
I guess reading the graph that Pasha sent is difficult; Pasha -- can
you send the actual numbers?
Ok here is the numbers on my machines:
0 bytes
mvapich with header caching: 1.56
mvapich
Brian Barrett wrote:
On Aug 13, 2007, at 9:33 AM, George Bosilca wrote:
On Aug 13, 2007, at 11:28 AM, Pavel Shamis (Pasha) wrote:
Jeff Squyres wrote:
I guess reading the graph that Pasha sent is difficult; Pasha -- can
you send the actual numbers?
Ok here is the numbers on my machines:
0
Jeff Squyres wrote:
Based on discussions at SC, I think it is time to have another IB/
OpenFabrics OMPI pow wow teleconference. It would be good to get
status updates on what everyone is doing in terms of OpenFabrics kinds
of things in OMPI so that we can coordinate the work properly. I'd
Jeff Squyres wrote:
Friday -- right, duh. My bad. So with everyone's replies so far, I
think we're down to:
2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
If we get no
Jeff Squyres wrote:
Are any of the XRC tmp SVN branches still relevant? Or have they now
been integrated into the trunk?
I ask because I see 4 XRC-related branches out there under /tmp and /
tmp-public.
I removed my XRC stuff from tmp repositories (3 of 4)
Pasha
:-)
Nice catch. Please commit the fix.
Pasha.
Jeff Squyres wrote:
Hah! Sweet; good catch -- feel free to delete that extra call.
On Dec 5, 2007, at 6:42 PM, Jon Mason wrote:
There is a double call to ompi_btl_openib_connect_base_open in
mca_btl_openib_mca_setup_qps(). It looks like som
Jeff Squyres wrote:
Hmm. I don't think that we want to put knowledge of XRC in the OOB
CPC (and vice versa). That seems like an abstraction violation.
I didn't like that XRC knowledge was put in the connect base either,
but I was too busy to argue with it. :-)
Isn't there a better way s
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
Isn't there a better way somehow? Perhaps we should have "select"
call *all* the functions and accept back a priority. The one with the
highest priority then wins. This is quite similar to much of the
ot
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote:
Isn't there a better way somehow? Perhaps we should have "select"
call *all* the funct
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 04:08:31PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Wed, Dec 12, 2007 at 03:37:26PM +0200, Pavel Shamis (Pasha) wrote:
Gleb Natapov wrote:
On Tue, Dec 11, 2007 at 08:16:07PM -0500, Jeff Squyres wrote
I will try it.
Jeff Squyres wrote:
This commit does what we previously discussed: it only compiles the
XOOB openib CPC if XRC support is actually present (vs. having a stub
XOOB when XRC is not present). This is on the /tmp-public/openib-cpc
branch.
I have some hermon hca's, but due to d
Tested.
XRC works.
Pasha
Pavel Shamis (Pasha) wrote:
I will try it.
Jeff Squyres wrote:
This commit does what we previously discussed: it only compiles the
XOOB openib CPC if XRC support is actually present (vs. having a stub
XOOB when XRC is not present). This is on the /tmp-public
Adding Open MPI and MVAPICH community to the thread.
Pasha (Pavel Shamis)
Jack Morgenstein wrote:
background: see "XRC Cleanup order issue thread" at
http://lists.openfabrics.org/pipermail/general/2007-December/043935.html
(userspace process which created the receiving X
have that data
member there. It's up to the CPC's if they want to use that info or
not.
Any objections to me removing this #if on the openib-cpc branch? (and
eventual merge back up to the trunk)
I have no objections. We should remove it.
--
Pavel Shamis (Pasha)
Mellanox Technologies
the server to run 365 days
a year.
I have some question about the scenario above. Did you call for the mpi
disconnect on the both ends (server/client) before the client exit (did
we must to do it?)
Regards,
Pasha.
Thanks.
--CQ
-Original Message-----
From: Pavel Shamis (Pasha)
B and iWARP adapters on a 2 node system
(with it correctly choosing to use oob and happily ignoring iWARP
adapters). It needs XRC testing and testing of larger node systems.
Did you run MTT over all thess changes ?
I have few machines with connectX and i will try to run MTT on Sunday.
--
Jon Mason wrote:
I have few machines with connectX and i will try to run MTT on Sunday.
Awesome! I appreciate it.
After fixing the compilation problem in XRC part of code I was able to
run mtt. Most of the test pass and one test
failed: mpi2c++_dynamics_test. The test pass without
to get an
idea what others are planning.
Thanks
-DON
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Pavel Shamis (Pasha)
Mellanox Technologies
7;s use of xrc,
maybe point me to a paper, or both?
TIA
-DON
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Pavel Shamis (Pasha)
Mellanox Technologies
another paper
http://www.cs.sandia.gov/~rbbrigh/papers/ompi-ib-pvmmpi07.pdf
that talks about more efficient usage of receive buffers.
Do you have any numbers showing the actual memory footprint savings
when using xrc?
I don't have.
Pasha.
-DON
Pavel Shamis (Pasha) wrote:
Here is paper
nks,
--Brad
Brad Benton
IBM
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Pavel Shamis (Pasha)
Mellanox Technologies
te_cq_compat(hca->ib_dev_context, cq_size,
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Pavel Shamis (Pasha)
Mellanox Technologies
aling issues expect to make additional improvements over the
next few weeks.
Update results will be posted to the wiki as they become available.
Ralph
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
RHEL4U4, for example -- you have to
manually mknod and chmod a device in /dev/infiniband for every HCA in
the host).
Thanks.
--
Pavel Shamis (Pasha)
Mellanox Technologies
fixed it -- even trivial apps will work or
not work.
Thanks.
On Apr 24, 2008, at 6:24 AM, Gleb Natapov wrote:
On Thu, Apr 24, 2008 at 11:50:10AM +0300, Pavel Shamis (Pasha) wrote:
Jeff,
All my tests fail.
XRC disabled tests failed with:
mtt/installs/Zq_9/install/lib/openmpi/mca_btl_open
te:
Thanks! That's a result of some [helpful] error messages and handling
that I added yesterday when ibcm is not configured on the host.
Fixed in r18273.
On Apr 24, 2008, at 8:22 AM, Pavel Shamis (Pasha) wrote:
The patch below resolves the segfault :
-- btl_openib_connect_ibcm.c.orig
s
Cisco Systems
--
Jeff Squyres
Cisco Systems
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Pavel Shamis (Pasha)
Mellanox Technologies
1. When CM progress thread completes an incoming connection, it sends
a command down a pipe to the main thread indicating that a new
endpoint is ready to use. The pipe message will be noticed by
opal_progress() in the main thread and will run a function to do all
necessary housekeeping (
What about moving posting of receive buffers into main thread. With
SRQ it is easy: don't post anything in CPC thread. Main thread will
prepost buffers automatically after first fragment received on the
endpoint (in btl_openib_handle_incoming()).
It still doesn't guaranty tha
Is it possible to have sane SRQ implementation without HW flow
control?
It seems pretty unlikely if the only available HW flow control is to
terminate the connection. ;-)
Even if we can get the iWARP semantics to work, this feels kinda
icky. Perhaps I'm overreacting and this is
I'm agree with Brian. We may add to the warning message detailed
description how to disable it.
Pasha
Brian W. Barrett wrote:
I think having a parameter to turn off the warning is a great idea. So
great in fact, that it already exists in the trunk and v1.2 :)! Setting
the default value for
As I know only Openib kernel drivers is installed by default with
distribution.
But the user level - libibverbs and other openib stuff is not installed
by default. User need go to the package manager and explicitly
select libibverb. So if user decided to install libibverbs he had
reasons for it
Brian and I chatted a bit about this off-list, and I think we're in
agreement now:
- do not change the default value or meaning of
btl_base_want_component_unsed.
- major point of confusion: the openib BTL is actually fairly unique
in that it can (and does) tell the difference between "t
I'm not sure I follow this logic -- can you explain more?
Sure
Why does this only apply to binary distribution? If libibverbs is
installed by default, then OMPI will still build the openib BTL (and
therefore warn if it's not used). Granted, some distros will only
install libibverbs if
1. Driver doesn't support the HCA - If I remember correct , RH40 by
default doesn't support ConnectX hca . The device_list will be empty.
It is very exotic case.
2. Driver version doesn't correspond with fw version
3. FW was broken
4. Driver was broken and failed to start - it is not very ex
Jeff Squyres wrote:
Who would be interested in discussing this stuff? (me, Brian, ?
someone from Sun?, ...?)
Me.
it seems that Open MPI doen't have HCA parameters for the following
InfiniBand adapter
which using the compute nodes of our SGI Altix ICE 8200EX:
Mellanox Technologies MT26418 ConnectX
I assume that the vendor part ID 26418 should be listed in the section
"Mellanox Hermon"
of the HCA parame
I got some more feedback from Roland off-list explaining that if /sys/
class/infiniband does exist and is non-empty and /sys/class/
infiniband_verbs/abi_version does not exist, then this is definitely a
case where we want to warn because it implies that config is screwed
up -- RDMA devices
r18551 brakes ompi compilation on SLES10 gcc 4.1.0.
I got follow error on my systems
(http://www.open-mpi.org/mtt/index.php?do_redir=672 ):
make[2]: Entering directory
`/.autodirect/hpc/work/pasha/tmp/mtt-8/installs/5VHm/src/openmpi-1.3a1r18553/ompi/mca/pml/ob1'
/bin/sh ../../../../libtool --ta
Ralf Wildenhues wrote:
* Pavel Shamis (Pasha) wrote on Mon, Jun 02, 2008 at 02:25:13PM CEST:
r18551 brakes ompi compilation on SLES10 gcc 4.1.0.
I got follow error on my systems
(http://www.open-mpi.org/mtt/index.php?do_redir=672 ):
[...]
/usr/lib64/gcc/x86_64-suse-linux/4.1.0
The compilation passed on SLES 10 SP1.
So SP1 resolves the gcc/binutils issue.
We need to add somewhere notice that " ompi 1.3 can not be compiled on
SLES10 , please update ... "
Regards,
Pasha
Pavel Shamis (Pasha) wrote:
Ralf Wildenhues wrote:
* Pavel Shamis (Pasha) wrote on M
Last conf. call Jeff mentioned that he see some collectives failures.
In my MTT testing I also see that Pallas collectives failed -
http://www.open-mpi.org/mtt/index.php?do_redir=682
Alltoall
#
# Benchmarking Alltoall
# #processe
Brian Barrett wrote:
Did anyone get a chance to test (or think about testing) this? I'd
like to commit the changes on Friday evening, if I haven't heard any
negative feedback.
I will run it tomorrow on my cluster.
Brian
On Jun 9, 2008, at 8:56 PM, Brian Barrett wrote:
Hi all -
Per
.so.6(__assert_fail+0xf6) [0x2aba5e651256]
[sw216:32013] [ 4]
Pavel Shamis (Pasha) wrote:
Last conf. call Jeff mentioned that he see some collectives failures.
In my MTT testing I also see that Pallas collectives failed -
http://www.open-mpi.org/mtt/index.php?do_redir=682
All
In my MTT testing it looks ok, too.
Brad Benton wrote:
Brian,
This is working smoothly now: both the configuration/build and
execution. So,
from my standpoint, it looks good for inclusion into the trunk.
--brad
On Wed, Jun 11, 2008 at 4:50 PM, Brian W. Barrett
mailto:brbar...@open-mpi.
I tried to run trunk on my machines and I got follow error:
[sw214:04367] [[16563,1],1] ORTE_ERROR_LOG: Data unpack would read past
end of buffer in file base/grpcomm_base_modex.c at line 451
[sw214:04367] [[16563,1],1] ORTE_ERROR_LOG: Data unpack would read past
end of buffer in file grpcomm_b
You'll have to tell us something more than that, Pasha. What kind of
environment, what rev level were you at, etc.
Ahh, sorry :) I run on Linux x86_64 Sles10 sp1. (Open MPI) 1.3a1r18682M
, OFED 1.3.1
Pasha.
So far as I know, the trunk is fine.
On 6/19/08 12:01 PM, "Pavel Sha
where.
I use ssh., here is command line:
./bin/mpirun -np 2 -H sw214,sw214 -mca btl openib,sm,self
./osu_benchmarks-3.0/osu_latency
Meantime, I'm building on RoadRunner and will test there (TM enviro).
On 6/19/08 1:18 PM, "Pavel Shamis (Pasha)" wrote:
You'll
oblem. I'll see what I
can do.
For now, though, just use the default grpcomm and it will work fine.
On 6/19/08 1:18 PM, "Pavel Shamis (Pasha)" wrote:
You'll have to tell us something more than that, Pasha. What kind of
environment, what rev level were you at, etc.
ckout or build and
that the component is either missing or not getting built.
On 6/19/08 1:37 PM, "Pavel Shamis (Pasha)" wrote:
Ralph H Castain wrote:
I can't find anything wrong so far. I'm waiting in a queue on Odin to try
there since Jeff indicated you are usi
Jeff Squyres wrote:
Do you need configury to disable building ibcm / rdmacm support?
The more I think about it, the more I think that these would be good
features to have for v1.3...
I had similar issue recently. It will be nice to have option to
disable/enable *CM via config flags.
On Jul
Ok:
https://svn.open-mpi.org/trac/ompi/ticket/1375
I think any of us could do this -- it's pretty straightforward. No
guarantees on when I can get to it; my 1.3 list is already pretty long...
No problem. I will take this one.
Pasha.
On Jul 3, 2008, at 6:20 AM, Pavel Shamis (
explicit selectionMaybe just hide the print ?
Bogdan Costescu wrote:
On Thu, 3 Jul 2008, Pavel Shamis (Pasha) wrote:
I had similar issue recently. It will be nice to have option to
disable/enable *CM via config flags.
Not sure if this is related... I am looking at using a nightly 1.3
snapshot
1 - 100 of 122 matches
Mail list logo