I have always just compiled everything the same way I would for a single processor 
machine and just specified twice as many processes at runtime.  This seems to have the 
same effect from checking with 'top'.  It pegs both processors anyway.  My main 
problem is very processor intensive and not communication intensive though, so this 
method, if you want to call it that, might not work as well if there is a lot of 
talking going on.

I use LAM/MPI not MPICH but I was under the impression that they quite similar.  It is 
very possible that I have no idea what I am talking about.  I find this is the case 
fairly often, so feel free to correct my ignorance.

Original Message -----------------------
Hi all.

I posted this enquiry a couple of weeks ago but received zero responses. Is
this because this is the wrong forum for such an enquiry? or did it just
get overlooked?

I'm trying again in the hope that someone can either shed some light on
this problem, or point me to a more appropriate forum.

Many thanks for your help.

original message follows....

I am now running MPICH_p4 on dual-processor (Oscar) cluster nodes and would
like to take advantage of message passing by shared memory when possible
(ie when 2 processors are on the same box). I have re-compiled MPICH and
specified the --with-comm=shared flag and re-installed MPICH on all nodes
of the cluster.

So far so good.

However, when I run a job that attempts to run two processes on the same
dual-processor machine I get....

p0_12728: (0.001227) Specified multiple processes sharing memory without
configuring for shared memory.p0_12728: (0.001351) Check the users manual
for more information.

I checked the users manual and it didn't shed much light, in fact it made
me question whether the p4 device will even work --with-comm=shared under
LINUX. What does it mean "without configuring for shared memory"? I am
running a SMP kernel on a dual processor machine, is there more I must do?

The simulation works fine if I specify processors on separate nodes for the
simulation.

Any insights would be welcome.

Many thanks for your help.


Giles

-------------------------------------------------
G.R. Lesser
Visiting Scientist
-------------------------------------------------
US Geological Survey
Coastal and Marine Geology Program
345 Middlefield Road MS 999
Menlo Park, CA 94025
e-mail: [EMAIL PROTECTED]
tel:     +1 650 329-5475
fax:    +1 650 329-5190
-------------------------------------------------
WL | Delft Hydraulics
internet: http://www.wldelft.nl
US Geological Survey Western Region
Coastal and Marine Geology
internet: http://walrus.wr.usgs.gov



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Oscar-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-users



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
Oscar-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-users

Reply via email to