[mpich-discuss] Problems with running make

Tue Mar 4 05:59:08 CST 2014

Hi,

Am 04.03.2014 um 00:49 schrieb Gus Correa:

> On 03/03/2014 06:19 PM, Ron Palmer wrote:
>> Reuti, good comment about primary interface for mpi and secondary for
>> the rest of the world.
>> 
>> Yes, setting it up from scratch, and I would love a queuing system as
>> well, I just had no idea such existed (learning by the minute!). These
>> computers are dedicated to this parallelisation jobs I am running and
>> will not run anything else. Would you be able to point my nose in a
>> direction of a simple queuing system?
>> 
> 
> In the open source / free software world:
> 
> I use Torque+Maui:
> 
> http://www.adaptivecomputing.com/products/open-source/torque/
> http://www.adaptivecomputing.com/products/open-source/maui/

Personally I don't like the split of resource manager and scheduler. I struggle between `qstat` and `showq`.

> Another very popular queuing system is the Sun Grid Engine (maybe this
> is what Reuti uses?),

Yep.

> which I think became the Open Grid Scheduler.

After Oracle bought SUN there were first two open source forks besides Oracle's commercial one. The one you mentioned and https://arc.liv.ac.uk/trac/SGE Eventually Univa hired several members of the original development team and bought all assets from Oracle, so that there is one commercial version of GridEngine from Univa.

-- Reuti

> Better ask somebody else (Reuti maybe) about this one.
> 
> http://gridscheduler.sourceforge.net/
> 
> Yet a third one is LLNL's Slurm:
> 
> https://computing.llnl.gov/linux/slurm/
> 
> 
>> All my parallel processing are controlled by my own perl scripts and
>> commandline commands (provided binaries), nothing GUI at all (which is
>> kinda nice).
>> 
>> Do you think shutting down the xserver would make any difference to the
>> performance of these computers? I am pretty sure that they al have a
>> windows manager running by default... I only got them going last week so
>> I have not (yet) gone in to this level of detail.
>> 
> 
> If you are sure nobody will ever want to run Matlab,
> or to show a graph with gnuplot, or perhaps more likely, use a graphical debugger such as DDD (or the equivalent from Intel or PGI), you can live without X-windows.
> 
> I don't see it as a big burden, though, unless there is somebody doing
> heavy GUI stuff while other computation is going on concurrently.
> 
> You could simply start the computers at runlevel 3.
> 
> **
> 
> OK, this is now more about cluster then about MPICH specifically.  :)
> 
> I hope this helps,
> Gus Correa
> 
>> Thanks,
>> Ron
>> 
>> On 4/03/2014 09:06, Reuti wrote:
>>> Am 03.03.2014 um 23:54 schrieb Gus Correa:
>>> 
>>>> On 03/03/2014 04:36 PM, Ron Palmer wrote:
>>>>> Thanks Reuti for your comments. I will peruse that FAQ detail.
>>>>> 
>>>>> I just thought of the fact that each of these rack computers have 4
>>>>> ethernet sockets, eth0 - eth3... I could connect the cluster on a
>>>>> separate ethernet sockets via an extra switch not connected to the
>>>>> internet or any other computers, and accept all communication among
>>>>> them, and keep iptables up on the ethx connected to the outside
>>>>> world. I
>>>>> guess I would have to set up routing tables or something. Ah, more
>>>>> reading :-)
>>>>> 
>>>>> Thanks for your help.
>>>>> Ron
>>>>> 
>>>> Hi Ron
>>>> 
>>>> If those extra interfaces are not in use,
>>>> and if you have a spare switch,
>>>> you can setup a separate private subnet exclusively for MPI.
>>>> You need to configure the interfaces consistently (IP, subnet mask,
>>>> perhaps a gateway). Configuring them statically is easy:
>>>> 
>>>> https://access.redhat.com/site/documentation//en-US/Red_Hat_Enterprise_Linux/6/html-single/Deployment_Guide/index.html#s2-networkscripts-interfaces-eth0
>>>> 
>>>> 
>>>> Use a subnet that doesn't intersect the existent/original IP range.
>>>> 
>>>> http://en.wikipedia.org/wiki/Private_network
>>>> 
>>>> You could also create host names associated to those IPs (say
>>>> node01, node02, node02), resolve them via /etc/hosts on each computer,
>>>> set passwordless ssh across these newly named "hosts".
>>>> This may simpler/safer than messing with the iptables.
>>>> 
>>>> [Actually, the IP addresses you showed 192.168.X.Y, sound as a private
>>>> subnet already, not Internet, but that may be the subnet for your
>>>> organization/school/department already. So, you may set up a different
>>>> one on these three computers for MPI and very-local access.]
>>> Yep, maybe in the 10.0.0.0/8 range.
>>> 
>>> BTW: are you setting up a cluster from scratch - will you also add any
>>> queuing system later on?
>>> 
>>> 
>>>> OpenMPI allows you to choose the interface that it will use,
>>>> so you can direct it to your very-local subnet:
>>>> 
>>>> http://www.open-mpi.org/faq/?category=tcp#tcp-selection
>>> MPICH:
>>> 
>>> http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Hydra_with_Non-Ethernet_Networks
>>> 
>>> 
>>> It should work for other Ethernet interfaces too.
>>> 
>>> Nevertheless: in any case it might be easier for the applications to
>>> use the primary interface solely for MPI, and any other one for the
>>> external access (this is usually my setup, as I don't have to provide
>>> the assignment of other interfaces this way).
>>> 
>>> -- Reuti
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> discuss mailing list discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss