Re: [Fed-Talk] A suggestion for X-SERVEs
Re: [Fed-Talk] A suggestion for X-SERVEs
- Subject: Re: [Fed-Talk] A suggestion for X-SERVEs
- From: Michael Johnson <email@hidden>
- Date: Thu, 17 Feb 2005 10:04:06 -0500
On Feb 17, 2005, at 9:39 AM, Michael Kluskens wrote:
On Feb 17, 2005, at 12:32 AM, Michael Pike wrote:
After cutting my hands to hell, a lot (and I mean A-LOT) of fowl
language, and wondering how the same people who developed the
beautiful powerbook could come up with the X-SERVE rack mounts...
You haven't tried to mount an Xserve in a SGI Origin rack. We're
limited for space and adding a rack just for one Xserve and an Xserve
RAID would squeeze something else, like a workstation work area for
example. Given that our SGI Origin had an opening with just enough
vertical space to hold the two items we were highly motivated.
I have. My first Xserve RAID and Xserve installations were in an SGI
Origin 3400's rack. It wasn't that bad considering the experiences
I've had with the Compaq rack mentioned in my previous post.
Apple ships the Xserve with a set of rail components that should fit
almost anything, but strangely enough the rails in a SGI Origin rack
are spaced precisely such that making Apple's rails work was nearly
impossible; however, it is possible to do but not unless you really
have the skills.
I didn't notice this at all. They seemed to fit a lot better than the
Compaq rack. Maybe since I've been working on SGIs for going on 15
years, it was just second nature to me.
How does a G4's & G5's compare with SGI Origin's and Altix's?
In our testing, the G5 ran circles around it. We did some FFTW stuff
and found the G5 machine with adequate memory was much faster. Of
course, Eric Clements helped a bit in getting access to the machine at
the Reston office and did a little optimization for us. However, the
improvements were only about 10% over the stock code we had submitted.
I've only run one set of benchmarks using a single Fortran 90 FDTD
(Finite-Difference Time-Domain) code with no Altivec hand
optimizations. For a 910 MB calculation, it's 5.1 hrs on a single
processor of a SGI Origin with 300 MHz R12K MIPS (upgraded 1998), 4.6
hrs on a single processor of dual 1 GHz G4 MDD (purchased 2002), 2.7
hrs on a SGI Fuel 600 MHz R12K, 1.6 hrs on a single processor of a
dual 2 GHz G5, 1.3 hrs on a 1.8 MHz P4 Dell/Linux, 0.44 hrs on a
single processor of dual processor SGI Altix 1.4 GHz Itanium2
(purchased 2004). I also have a dual processor 1.4 GHz Opteron
cluster, but I made the mistake of running the tests on the master
node rather than a client node.
Altivec will help, although nothing we did in our code used those
optimizations. A nice thing we noted was OS X seemed to automagically
take advantage of the second processor even though the code wasn't
parallelized.
Not the performance comparison you expected, that's because FDTD moves
massive amounts of data to and from the main memory continually, in
one test comparing identically spec'd Dell PC's there was a factor 2
or 3 difference, it appears the key item was that I had ordered one
machine with the best memory possible and the other machine had been
purchased with the standard memory.
The tests we did used massive amounts of data. We had to make 3D
images out of tomographic slices of about 150MB each taken at 5 degree
intervals. The data set was around 5 1/2 GB. With the machines fully
loaded with memory, this took no time at all as the data was able to be
loaded completely into memory instead of swapping. We tested against
the Origin 3400 (4x500 with 8GB), a dual 2GHz G5 with 8GB, and an IBM
p670 with 8 POWER4+ 1.6GHz processors and 64 GB. The dual G5 was able
to beat the Origin easily, and only the 670 came close (about 20%
slower on the stock, i.e. not optimized by Eric machine).
Should Apple create machines with larger number of CPU's that access
the same memory space I might eventually be able to show my bosses
benchmarks with our codes were Apple wins on cost and performance.
But I expect to have at least one internal code moved to MPI before
Apple's gets into that market and then I'll see what numbers come up.
Right now, it looks like clustering is the way Apple is going to
provide the big iron. I wouldn't expect to see any Altix or pSeries
style things coming from Apple any time soon.
Also, personally I can't see if Apple could make money in that segment
of the market, look at SGI and their stock price.
Yes, but look at IBM. Their server market is doing surprisingly well.
Personally, I detest AIX although I have my fresh new certification
hanging on the wall. However, SuSE Linux on the POWER machines is a
beautiful thing.
Hopefully I didn't go to far afield with this message.
Thread creep is not that bad. We're at least still talking (mostly)
about Apple products used in the federal government. =-)
-Michael
PS Are there any other Michaels on this list who have yet to respond
to this thread?
-----------------------------------
The most beautiful thing we can experience is the mysterious. It is
the source of all true art and science.
--Albert Einstein
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden