[prev in list] [next in list] [prev in thread] [next in thread] 

List:       beowulf
Subject:    [Beowulf] NASTRAN on cluster
From:       "Currit, Dennis" <Dennis_Currit () atk ! com>
Date:       2005-04-11 17:01:14
Message-ID: 7B8D37027B57D7459984035D83864E360682AF06 () exchangeut1 ! atk ! com
[Download RAW message or body]

--===============0815524344==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53EB8.12135A90"

This is a multi-part message in MIME format.


We just installed a small cluster and are running NASTRAN 2005 on it.  This is the \
first cluster we have set up, so we are beginners.  Anyway, the cluster consists of 5 \
Dell Precision 470 workstations running Fedora Linux.  Each has 4 GB RAM, 2 160 GB \
SATA drives and dual Xeon 2.8 ghz processors.  It seems to run pretty well; there \
were no real tricks.  Some of the NASTRAN bdf files needed to be modified a little in \
order to run, usually by removing statements that assigned specific file paths and \
names to scratch and dbs files.  One thing to consider is that NASTRAN doesn't seem \
to make very good use of dual processor machines.  For example, I have 5 dual \
processor machines.  If I specify dmp=10 on the NASTRAN command, it starts 2 \
processes on each machine and runs MUCH slower than if I had it only started 1 \
process per machine.  There is a (undocumented?) command (sys107=2) that specifies \
that each machine has two processors.  It improves performance somewhat.  On a test \
job, I got the following results:

Single Machine 				523 minutes
5 node cluster (dmp=5)			148 minutes
5 node cluster (dmp=10)			199 minutes
5 node cluster (dmp=5 sys107=2)	128 minutes

Also, I didn't do any RAID.  My thought was that I would rather put /tmp and /scratch \
on different physical drives.  After I had it set up, I talked with MSC and they \
recommended using RAID 0.  They also recommended using ext2 for /scratch rather than \
ext3.  I changed that and my test job ran in 125 minutes.  

Also, MSC NASTRAN uses a maximum of 2 GB or RAM under 32 Linux, but I have seen \
documentation that suggests you get a real perfomance benefit by having at least 3 GB \
on each node.  Along this line, I couldn't get jobs to run when I specified mem=2gb, \
but they did run when I specified mem=500mw (500 mega words, just under 2 GB).

My impression is that performance is limited by CPU speed, not I/O.  I would spend \
more money on faster (maybe 64 bit) processors than in optimizing the disk system. 


[Attachment #3 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7232.36">
<TITLE>NASTRAN on cluster</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">We just installed a small cluster and are running \
NASTRAN 2005 on it.&nbsp; This is the first cluster we have set up, so we are \
beginners.&nbsp; Anyway, the cluster consists of 5 Dell Precision 470 workstations \
running Fedora Linux.&nbsp; Each has 4 GB RAM, 2 160 GB SATA drives and dual Xeon 2.8 \
ghz processors.&nbsp; It seems to run pretty well; there were no real tricks.&nbsp; \
Some of the NASTRAN bdf files needed to be modified a little in order to run, usually \
by removing statements that assigned specific file paths and names to scratch and dbs \
files.&nbsp; One thing to consider is that NASTRAN doesn't seem to make very good use \
of dual processor machines.&nbsp; For example, I have 5 dual processor \
machines.&nbsp; If I specify dmp=10 on the NASTRAN command, it starts 2 processes on \
each machine and runs MUCH slower than if I had it only started 1 process per \
machine.&nbsp; There is a (undocumented?) command (sys107=2) that specifies that each \
machine has two processors.&nbsp; It improves performance somewhat.&nbsp; On a test \
job, I got the following results:</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Single Machine&nbsp; \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 523 minutes</FONT>

<BR><FONT SIZE=2 FACE="Arial">5 node cluster (dmp=5)&nbsp; \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
148 minutes</FONT>

<BR><FONT SIZE=2 FACE="Arial">5 node cluster (dmp=10) \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
199 minutes</FONT>

<BR><FONT SIZE=2 FACE="Arial">5 node cluster (dmp=5 sys107=2) 128 minutes</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Also, I didn't do any RAID.&nbsp; My thought was that I \
would rather put /tmp and /scratch on different physical drives.&nbsp; After I had it \
set up, I talked with MSC and they recommended using RAID 0.&nbsp; They also \
recommended using ext2 for /scratch rather than ext3.&nbsp; I changed that and my \
test job ran in 125 minutes.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">Also, MSC NASTRAN uses a maximum of 2 GB or RAM under 32 \
Linux, but I have seen documentation that suggests you get a real perfomance benefit \
by having at least 3 GB on each node.&nbsp; Along this line, I couldn't get jobs to \
run when I specified mem=2gb, but they did run when I specified mem=500mw (500 mega \
words, just under 2 GB).</FONT></P>

<P><FONT SIZE=2 FACE="Arial">My impression is that performance is limited by CPU \
speed, not I/O.&nbsp; I would spend more money on faster (maybe 64 bit) processors \
than in optimizing the disk system. </FONT></P>

</BODY>
</HTML>



_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit \
http://www.beowulf.org/mailman/listinfo/beowulf

--===============0815524344==--



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic