Home > Archive > Fortran > October 2006 > 64-bit Workstation Configuration Help Needed
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
64-bit Workstation Configuration Help Needed
|
|
| John S 2006-10-02, 7:03 pm |
| 64 Bit Workstation Configuration Help Needed
In order to move to the next level of problem size, it is time to move from
the present 32 bit PC/Win XP/IVF 9.1/Intel MKL 8.1/RAID 0 scratch disk (4
SATA Raptors with hardware controller) environment.
The computations involve compressed block LU matrix factorization of really
large matrices (above 350,000 unknowns with block sizes on the order of 1000
to 2000). The algorithm relies heavily on level 3 BLAS CGEMM for complex
matrix-matrix mults and on out of core scratch disk IO for storing the
compressed LU factored blocks. This file size gets to be greater than 50 GB
and must be completely read in order to factor the next block of the matrix.
Fortran 90/95, with all of the array features and operator overloading, is
the key to success of this algorithm
The next platform should have fast memory access, fast scratch disk read IO
(read far more important than write), and should have fast level 3 cgemm
blas and LAPACK routines. I have not parallelized the code yet, but that
will be a next step. All of memory should be seen by each processor core
(am very fuzzy on this).
Cost should be less than $10k (hopefully)
So, for a 64-bit workstation, what is the collective ng opinion for:
Processor: AMD Opteron (dual core) vs INTEL;
A motherboard with two processors, each with two cores.
Memory: 16 GB of DDR 3200 or DDR2
Scratch Disks (four in RAID 0):
SCSI 320, 15k rpm; or
SATA II 7.5k rpm; or
SATA I Western Digital Raptors, 10k rpm.
Cost: Are 4 15k rpm SCSI's disks worth the cost over 4 10k rpm
Raptors (in RAID 0)
PCI BUS: PCI-X 64 bit vs PCI-e ? (for RAID 0 hardware adaptor card)
O/S: Linux or Win_64? If Linux, SUSE 64 bit vs RedHat?
Fortran: Intel IVF 9.1
Math Kernel Library:
Intel Math Kernel Library 8.1;
or if AMD Opteron what blas/lapack library is recommended?
What else should be considered?
Thanks.
| |
| ejko123@yahoo.com 2006-10-02, 7:03 pm |
|
John S wrote:
> The computations involve compressed block LU matrix factorization of really
> large matrices (above 350,000 unknowns with block sizes on the order of 1000
> to 2000). The algorithm relies heavily on level 3 BLAS CGEMM for complex
> matrix-matrix mults and on out of core scratch disk IO for storing the
> compressed LU factored blocks. This file size gets to be greater than 50 GB
> and must be completely read in order to factor the next block of the matrix.
Throughput is limited entirely by i/o, so you need to find the fastest
disk/filesystem
combination that you can afford; all other considerations are
secondary, assuming
sufficient RAM. A modern Linux filesystem will outperform Win64 in
this regard.
You might consider a Solaris/Athlon box or even OSX/Intel in addition
to a generic
Linux PC. Ifort/MKL is available for the latter, which will save you
time, and Sun's
compilers and high-performance LAPACK/BLAS are available for free.
--Eric
| |
| Tim Prince 2006-10-03, 8:12 am |
| John S wrote:
> 64 Bit Workstation Configuration Help Needed
>
>
>
> In order to move to the next level of problem size, it is time to move from
> the present 32 bit PC/Win XP/IVF 9.1/Intel MKL 8.1/RAID 0 scratch disk (4
> SATA Raptors with hardware controller) environment.
>
>
>
> The computations involve compressed block LU matrix factorization of really
> large matrices (above 350,000 unknowns with block sizes on the order of 1000
> to 2000). The algorithm relies heavily on level 3 BLAS CGEMM for complex
> matrix-matrix mults and on out of core scratch disk IO for storing the
> compressed LU factored blocks. This file size gets to be greater than 50 GB
> and must be completely read in order to factor the next block of the matrix.
> Fortran 90/95, with all of the array features and operator overloading, is
> the key to success of this algorithm
>
>
>
> The next platform should have fast memory access, fast scratch disk read IO
> (read far more important than write), and should have fast level 3 cgemm
> blas and LAPACK routines. I have not parallelized the code yet, but that
> will be a next step. All of memory should be seen by each processor core
> (am very fuzzy on this).
>
>
>
> Cost should be less than $10k (hopefully)
>
>
>
> So, for a 64-bit workstation, what is the collective ng opinion for:
>
>
>
> Processor: AMD Opteron (dual core) vs INTEL;
>
> A motherboard with two processors, each with two cores.
>
MKL on an Intel Xeon 5100 series should out-perform any CGEMM for
current AMD, even if you change to double precision. Your described
usage may get significant benefit from quad core. Intel quad core CPUs
would be plug-in replacement for Xeon 5100 or 5000 series.
>
>
> Memory: 16 GB of DDR 3200 or DDR2
No Intel platform I know of will go to 16GB DDR2 on a single
motherboard. With FBDIMM, this is entirely feasible. A 16-slot
motherboard will keep the price somewhat under control. Certain AMD
platforms lose performance beyond 8GB old style DDR. DDR2 models may do
better.
Disk: Intel platforms support built-in SATA RAID controllers for
Windows. I haven't seen documentation of performance for applications
such as yours.
>
>
> O/S: Linux or Win_64? If Linux, SUSE 64 bit vs RedHat?
>
RHEL4_U4 has the best scheduler at the moment, for dual socket dual or
quad core (either brand). I suppose there is a CentOS equivalent. SuSE
will catch up soon, no doubt. If you are prepared to use taskset or
such like, it may do as well as RH. Some like the Windows approach of
locking threads to cores after the job is running, or using low-level
affinity calls (also available for linux). Otherwise, Windows may not
match performance of linux. On Xeon 5100 "Woodcrest," with 4 threads,
this may be a matter of <5%. With other numbers of threads, or on AMD
(or any of the quad core processors), it would be larger.
Not trying to denigrate 64-bit Windows; it's a big step forward from XP32.
>
>
> Fortran: Intel IVF 9.1
>
>
>
> Math Kernel Library:
>
> Intel Math Kernel Library 8.1;
>
> or if AMD Opteron what blas/lapack library is recommended?
MKL 8.1 is not optimum for AMD, although improved over previous
versions; possibly MKL may support AMD better soon.
AMD linux libraries make a point of not supporting Intel Fortran.
Work-arounds (like using the gfortran version, dummying out the gfortran
calls not satisfied by ifort), are at your own risk and possibly violate
the terms you agree to when installing. So you may be left with ATLAS
or Goto as the choices for AMD with ifort.
Usual mandatory disclaimer: I don't speak for my employer, go check the
web sites etc.
| |
| Mike Zulauf 2006-10-03, 8:12 am |
| In article <lUiUg.10780$6S3.9434@newssvr25.news.prodigy.net>,
Tim Prince <timothyprince@sbcglobal.net> wrote:
> John S wrote:
>
> No Intel platform I know of will go to 16GB DDR2 on a single
> motherboard.
Here's one:
http://www.apple.com/macpro/specs.html
Mike
--
Mike Zulauf
mazulauf@met.utah.edu
| |
| Tim Prince 2006-10-03, 8:12 am |
| Mike Zulauf wrote:
> In article <lUiUg.10780$6S3.9434@newssvr25.news.prodigy.net>,
> Tim Prince <timothyprince@sbcglobal.net> wrote:
>
>
> Here's one:
> http://www.apple.com/macpro/specs.html
>
Down at the bottom, it says they are FBDIMM; seems contradictory. Maybe
we'll get a p at this one day.
| |
| Mike Zulauf 2006-10-03, 8:12 am |
| In article <bllUg.8485$vJ2.7313@newssvr12.news.prodigy.com>,
Tim Prince <timothyprince@sbcglobal.net> wrote:
> Mike Zulauf wrote:
>
> Down at the bottom, it says they are FBDIMM; seems contradictory. Maybe
> we'll get a p at this one day.
Well, I don't really know the terminology, and what the differences are
between the different RAM technologies. On the other hand, I just did a
quick web search with the terms FBDIMM and DDR2, and it _appears_ to me
that the terms are not contradictory. I come across several sites
claiming systems are using FBDIMM DDR2 memory systems.
But like I said, I'm not really up on this stuff.
Mike
--
Mike Zulauf
mazulauf@met.utah.edu
| |
| Dan Nagle 2006-10-03, 8:12 am |
| Hello,
Tim Prince wrote:
> Mike Zulauf wrote:
>
> Down at the bottom, it says they are FBDIMM; seems contradictory. Maybe
> we'll get a p at this one day.
I have a MacPro with 8GB, I could have ordered 16GB.
It has 2 dual core power pc processors.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Dave Seaman 2006-10-03, 8:12 am |
| On Tue, 03 Oct 2006 04:06:31 GMT, Tim Prince wrote:
> Mike Zulauf wrote:
[color=darkred]
> Down at the bottom, it says they are FBDIMM; seems contradictory. Maybe
> we'll get a p at this one day.
According to System Profiler the memory type on my Mac Pro is "DDR2 FB-DIMM".
--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
| |
| Tim Prince 2006-10-03, 8:12 am |
| Mike Zulauf wrote:
> In article <bllUg.8485$vJ2.7313@newssvr12.news.prodigy.com>,
> Tim Prince <timothyprince@sbcglobal.net> wrote:
>
>
> Well, I don't really know the terminology, and what the differences are
> between the different RAM technologies. On the other hand, I just did a
> quick web search with the terms FBDIMM and DDR2, and it _appears_ to me
> that the terms are not contradictory. I come across several sites
> claiming systems are using FBDIMM DDR2 memory systems.
>
Technically, that appears to be valid; FBDIMMs are built up from DDR2
components. However, to my limited knowledge, FBDIMMs and plain DDR2
aren't interchangeable, and I've heard tales of burning out FBDIMM
motherboards by trying DDR2. The additional on-board buffering of
FBDIMM avoids a loss in performance incurred with DDR and DDR2 as
additional memory slots are used. Google search yields claims that
FBDIMMs based on DDR3 will be plug compatible with current FBDIMM
systems. Early FBDIMMs were associated with somewhat excessive power and
price; I guess there's still a difference. Clearly, working examples
show DDR and DDR2 satisfactory up to 8GB installed, so the advantage
which was expected for FBDIMM at 8GB did not materialize.
This seems an excessive accidental digression from the subject of
Fortran, but it seemed we were headed for possible disaster.
| |
| Ron Shepard 2006-10-03, 7:02 pm |
| In article <Y%pUg.983$If3.481@trnddc07>,
Dan Nagle <dannagle@verizon.net> wrote:
> I have a MacPro with 8GB, I could have ordered 16GB.
> It has 2 dual core power pc processors.
The MacPro machines have Intel processors, not Powerpc processors
(the desktop Powerpc machines were called PowerMacs). This (off
topic) discussion is about machines with Intel processors.
$.02 -Ron Shepard
| |
| ian_d_chivers@yahoo.co.uk 2006-10-03, 7:02 pm |
| I've just had a look at the dell uk site
and a dell 690 workstation can support
2 dual core xeon processors and
up to
32GB DDR2 533 Quad Channel FBD Memory (16x2GB)
this ways in at 8000 uk pounds - not sure
if this fits the budget :-)
hope this helps.
Tim Prince wrote:
> John S wrote:
> MKL on an Intel Xeon 5100 series should out-perform any CGEMM for
> current AMD, even if you change to double precision. Your described
> usage may get significant benefit from quad core. Intel quad core CPUs
> would be plug-in replacement for Xeon 5100 or 5000 series.
> No Intel platform I know of will go to 16GB DDR2 on a single
> motherboard. With FBDIMM, this is entirely feasible. A 16-slot
> motherboard will keep the price somewhat under control. Certain AMD
> platforms lose performance beyond 8GB old style DDR. DDR2 models may do
> better.
>
> Disk: Intel platforms support built-in SATA RAID controllers for
> Windows. I haven't seen documentation of performance for applications
> such as yours.
> RHEL4_U4 has the best scheduler at the moment, for dual socket dual or
> quad core (either brand). I suppose there is a CentOS equivalent. SuSE
> will catch up soon, no doubt. If you are prepared to use taskset or
> such like, it may do as well as RH. Some like the Windows approach of
> locking threads to cores after the job is running, or using low-level
> affinity calls (also available for linux). Otherwise, Windows may not
> match performance of linux. On Xeon 5100 "Woodcrest," with 4 threads,
> this may be a matter of <5%. With other numbers of threads, or on AMD
> (or any of the quad core processors), it would be larger.
> Not trying to denigrate 64-bit Windows; it's a big step forward from XP32.
> MKL 8.1 is not optimum for AMD, although improved over previous
> versions; possibly MKL may support AMD better soon.
> AMD linux libraries make a point of not supporting Intel Fortran.
> Work-arounds (like using the gfortran version, dummying out the gfortran
> calls not satisfied by ifort), are at your own risk and possibly violate
> the terms you agree to when installing. So you may be left with ATLAS
> or Goto as the choices for AMD with ifort.
>
> Usual mandatory disclaimer: I don't speak for my employer, go check the
> web sites etc.
| |
| CharlesBlackstone 2006-10-07, 10:01 pm |
|
John S wrote:
> 64 Bit Workstation Configuration Help Needed
>
>
>
> In order to move to the next level of problem size, it is time to move from
> the present 32 bit PC/Win XP/IVF 9.1/Intel MKL 8.1/RAID 0 scratch disk (4
> SATA Raptors with hardware controller) environment.
>
>
>
> The computations involve compressed block LU matrix factorization of really
> large matrices (above 350,000 unknowns with block sizes on the order of 1000
> to 2000). The algorithm relies heavily on level 3 BLAS CGEMM for complex
> matrix-matrix mults and on out of core scratch disk IO for storing the
> compressed LU factored blocks. This file size gets to be greater than 50 GB
> and must be completely read in order to factor the next block of the matrix.
> Fortran 90/95, with all of the array features and operator overloading, is
> the key to success of this algorithm
>
>
>
> The next platform should have fast memory access, fast scratch disk read IO
> (read far more important than write), and should have fast level 3 cgemm
> blas and LAPACK routines. I have not parallelized the code yet, but that
> will be a next step. All of memory should be seen by each processor core
> (am very fuzzy on this).
>
>
>
> Cost should be less than $10k (hopefully)
>
>
>
> So, for a 64-bit workstation, what is the collective ng opinion for:
>
>
>
> Processor: AMD Opteron (dual core) vs INTEL;
>
> A motherboard with two processors, each with two cores.
>
>
>
> Memory: 16 GB of DDR 3200 or DDR2
>
>
>
> Scratch Disks (four in RAID 0):
>
> SCSI 320, 15k rpm; or
>
> SATA II 7.5k rpm; or
>
> SATA I Western Digital Raptors, 10k rpm.
>
> Cost: Are 4 15k rpm SCSI's disks worth the cost over 4 10k rpm
> Raptors (in RAID 0)
>
>
>
> PCI BUS: PCI-X 64 bit vs PCI-e ? (for RAID 0 hardware adaptor card)
>
>
>
> O/S: Linux or Win_64? If Linux, SUSE 64 bit vs RedHat?
>
>
>
> Fortran: Intel IVF 9.1
>
>
>
> Math Kernel Library:
>
> Intel Math Kernel Library 8.1;
>
> or if AMD Opteron what blas/lapack library is recommended?
>
>
>
> What else should be considered?
>
>
>
> Thanks.
By far, your first consideration should be throughput from your hard
drives. If we can fit our data into RAM (8 gigs), a job may take
minutes. If it starts using swap, it will take a day.
After that, Linux -- I prefer Suse as they still support little guys,
for <= 2 cores intel woodcrest is outbenchmarking opteron and core duo
even better, but since your app will be parallel of multithreaded the
better bandwidth of opterons may be more important with your four
cores, DDR vs DDR2 will be decided for you. If you can wait a couple
months quad cores benchmarks will be coming out and you can see
performance of intel vs. amd for multi-core systems.
| |
| CharlesBlackstone 2006-10-07, 10:01 pm |
|
Tim Prince wrote:
> John S wrote:
> MKL on an Intel Xeon 5100 series should out-perform any CGEMM for
> current AMD, even if you change to double precision. Your described
> usage may get significant benefit from quad core. Intel quad core CPUs
> would be plug-in replacement for Xeon 5100 or 5000 series.
> No Intel platform I know of will go to 16GB DDR2 on a single
> motherboard. With FBDIMM, this is entirely feasible. A 16-slot
> motherboard will keep the price somewhat under control. Certain AMD
> platforms lose performance beyond 8GB old style DDR. DDR2 models may do
> better.
>
> Disk: Intel platforms support built-in SATA RAID controllers for
> Windows. I haven't seen documentation of performance for applications
> such as yours.
> RHEL4_U4 has the best scheduler at the moment, for dual socket dual or
> quad core (either brand). I suppose there is a CentOS equivalent. SuSE
> will catch up soon, no doubt. If you are prepared to use taskset or
> such like, it may do as well as RH. Some like the Windows approach of
> locking threads to cores after the job is running, or using low-level
> affinity calls (also available for linux). Otherwise, Windows may not
> match performance of linux. On Xeon 5100 "Woodcrest," with 4 threads,
> this may be a matter of <5%. With other numbers of threads, or on AMD
> (or any of the quad core processors), it would be larger.
> Not trying to denigrate 64-bit Windows; it's a big step forward from XP32.
> MKL 8.1 is not optimum for AMD, although improved over previous
> versions; possibly MKL may support AMD better soon.
> AMD linux libraries make a point of not supporting Intel Fortran.
> Work-arounds (like using the gfortran version, dummying out the gfortran
> calls not satisfied by ifort), are at your own risk and possibly violate
> the terms you agree to when installing. So you may be left with ATLAS
> or Goto as the choices for AMD with ifort.
>
> Usual mandatory disclaimer: I don't speak for my employer, go check the
> web sites etc.
Tim, where do you learn this sort of in depth infomation?
Thanks...
| |
|
| "John S" <john_shaeffer@REMOVEearthlinkMe.net> wrote in message
news:kreUg.9163$UG4.1305@newsread2.news.pas.earthlink.net...
> 64 Bit Workstation Configuration Help Needed
You are going to do exactly what I have just done for my wireless network
and electromagnetism simulations ;-) !
> Cost should be less than $10k (hopefully)
>
> So, for a 64-bit workstation, what is the collective ng opinion for:
>
> Processor: AMD Opteron (dual core) vs INTEL;
At the moment Intel proc. are faster in level 3 BLAS than AMD ones however
you must make analysis of bottlenecks in your current setup as well as to
make prediction of possible bottlenecks in your future system (which might
be very different). It may turn out that your proc speed doesn't mean
anything in case of slow I/O (both RAM and disks).
As for processors AMD will have its new architecture with real quad-cores
this time next year which seems to be really fast in level 3 BLAS.
> A motherboard with two processors, each with two cores.
Any professional one (workstation or server version depending on your needs
for making it your PC) from Iwill, Tyan, Intel, Arima, Supermicro etc. I
have Tyan Thunder K8WE and it is great... when it works properly. Sometimes
it doesn't work (check www.k8we.com , probably the best forum on the net
about professional workstation boards and problems people can have it this
kind of rigs, not only Tyan).
> Memory: 16 GB of DDR 3200 or DDR2
Well, it is only up to your funding. New AMD motherboards can easily have 32
GB of DDR2 RAM (Socket F) going to 64 GB in near future I suppose. Generally
speaking DDR2 allows you to put more memory than DDR. You will find
motherboards with up to 16 memory slots for dual socket Opterons, both
Socket 940 (DDR) and Socket F (DDR2).
As for Intel you can have comparable amount of memory as for AMD Socket F
but remember FB-DIMMS used in the newest Xeon 5100 are expensive, slow at
read in this generation of chipsets and really slow at write compared to
non-FB DDR2.
> Scratch Disks (four in RAID 0):
>
> SCSI 320, 15k rpm; or
>
> SATA II 7.5k rpm; or
>
> SATA I Western Digital Raptors, 10k rpm.
>
> Cost: Are 4 15k rpm SCSI's disks worth the cost over 4 10k rpm
> Raptors (in RAID 0)
I have thought for a long time how to solve this problem in my system (I
have 12 GB of DDR400 RAM and need ~80 GB for pagefile). Finally I have
chosen 4 x Seagate Cheetah 15k.4 SCSI 36 GB drives in Raid0. Be careful with
proper SCSI controller because it can have low bandwidth due to slow I/O
processor onboard of it as in my case. I made a mistake and bought LSI
MegaRaid 320-1 card which is slow in stream read/write in any Raid which I
will replace to 320-2x. Go for anything faster (LSI, Adaptec etc) and more
expensive.
As for drives the fastest continuous read is offered by the latest
generation of Cheetah 15k.5 which can achieve >130 MB/s per single drive but
they are expensive and min. 73 GB. You can also take fast Maxtor Atlas II
but I am not sure about their reliability (I just don't know). BTW, now I
think SCSI U320 will die very soon so better go to SAS - more expensive ;(.
There is another option with SATA drives. Check forum at www.2cpu.com in
storage threads. There are some guys who build ultra fast systems for
continuous high-res/speed video recording with number of SATA drives
achieving almost 1 GB/s of disk throughput! All depends on the type of your
reads from the disks. If you make just stream read of several GB having SATA
based system makes more sense (even Raptors, comparable speed can be
achieved with much lower costs). If you plan to read your data in "unknown"
small portions and make a lot of them SCSI/SAS is unbeatable. Before you buy
anything read as much as you can about those issues.
The fastest SATA card on the market is the new series of Areca ARC-12.. but
those with 800 MHz Intel 30341 processor including 24 port monster ARC-1280.
> PCI BUS: PCI-X 64 bit vs PCI-e ? (for RAID 0 hardware adaptor card)
In both cases you can have great performance if your card is real PCI-X (not
PCI64/66 MHz). Check how many lanes have your potential PCIe controller,
because some of them are PCIe x8 and dont want to work in PCI x16 slot and
your motherboar may only have PCIe x4 and x16 slots.
> O/S: Linux or Win_64? If Linux, SUSE 64 bit vs RedHat?
>
> Fortran: Intel IVF 9.1
>
> Math Kernel Library:
>
> Intel Math Kernel Library 8.1;
>
> or if AMD Opteron what blas/lapack library is recommended?
I use WinXP x64 with Matlab 64 bit but don't get suggested.
Good luck!
--
uC
www.ultracode.eu
| |
| Tim Prince 2006-10-08, 7:03 pm |
| uC wrote:
> As for Intel you can have comparable amount of memory as for AMD Socket
> F but remember FB-DIMMS used in the newest Xeon 5100 are expensive, slow
> at read in this generation of chipsets and really slow at write compared
> to non-FB DDR2.
This is true, for modest complements of RAM (e.g. 4GB). The reason for
adoption of FBDIMM is the ability to add more RAM without degrading
performance, so it should have value beyond 8GB. No doubt, more data
will be available after mere mortals are able to buy Socket F and
install large DDR2 RAM.
I've even seen reports of tests of DDR2-800. No doubt that moves the
performance as well as cost curves for some applications, but may show
little advantage over DDR2-533 for others.
>
> I use WinXP x64 with Matlab 64 bit but don't get suggested.
XP64 is beginning to catch on for large Fortran applications. So, many
of us are looking for practical solutions to avoid performance
degradation due to continual swapping of threads among cores on 4- and
8-way machines. That problem has been coming under control with linux
tools only recently, and Windows is not known for rapidity of catching up.
On the installation side, XP64 normally is a much more rapid and
foolproof installation than we are used to from the past. With few
options on disk drivers, ACPI, etc, at least there are relatively few
ways to go wrong. Vista-64 beta is available for those who like to
search for blind alleys (broken drivers,...).
I was just watching a crew struggling with installation of SuSE 10.1 on
Athlon-64 on Friday. It's just difficult to be satisfied with the first
working installation when it seems to require disabling so many features.
| |
| Greg Lindahl 2006-10-08, 7:03 pm |
| In article <45290EC1.5040903@sbcglobal.net>,
Tim Prince <tprince@nospammyrealbox.com> wrote:
> So, many
> of us are looking for practical solutions to avoid performance
> degradation due to continual swapping of threads among cores on 4- and
> 8-way machines. That problem has been coming under control with linux
> tools only recently,
PathScale's OpenMP compilers have always statically locked threads to
cores, and that's worked well for a long time in Linux. So I'm not
sure what you were lacking, unless you were using a non-NUMA-aware
compiler.
-- greg
| |
| Michael Prager 2006-10-12, 7:07 pm |
| "uC" <uC@bla.bla> wrote:
>
>
> I have thought for a long time how to solve this problem in my system (I
> have 12 GB of DDR400 RAM and need ~80 GB for pagefile). Finally I have
> chosen 4 x Seagate Cheetah 15k.4 SCSI 36 GB drives in Raid0. Be careful with
> proper SCSI controller because it can have low bandwidth due to slow I/O
> processor onboard of it as in my case. I made a mistake and bought LSI
> MegaRaid 320-1 card which is slow in stream read/write in any Raid which I
> will replace to 320-2x. Go for anything faster (LSI, Adaptec etc) and more
> expensive.
> As for drives the fastest continuous read is offered by the latest
> generation of Cheetah 15k.5 which can achieve >130 MB/s per single drive but
> they are expensive and min. 73 GB. You can also take fast Maxtor Atlas II
> but I am not sure about their reliability (I just don't know). BTW, now I
> think SCSI U320 will die very soon so better go to SAS - more expensive ;(.
>
> There is another option with SATA drives. [...] All depends on the type of your
> reads from the disks. If you make just stream read of several GB having SATA
> based system makes more sense (even Raptors, comparable speed can be
> achieved with much lower costs). If you plan to read your data in "unknown"
> small portions and make a lot of them SCSI/SAS is unbeatable.
I second the recommendation for SCSI/SAS disk subsystems.
Through many years of using PCs, it has become apparently to me
that if disk I/O is important to throughput, SCSI is superior to
other solutions (e.g., ATA, SATA). As uC points out, there may
be specialized cases where SATA equals SCSI. However, there are
many, many cases where it does not, and a disk I/O bottleneck
will really slow down even the fastest processors. (For an
example, consider how slow notebook computers seem for their
processor speeds. This is usually a function of slow disks.)
MHP
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
|
|
|
|
|