AMBER Archive (2009)

Subject: Re: [AMBER] Quality/size of HDD for Amber

From: M. L. Dodson (
Date: Fri Mar 06 2009 - 09:44:45 CST

Francesco Pietra wrote:
> One of the two fast-seeking-time, 150 GB, HDD of my raid 1 was
> steadily loosing sectors until it was hanging the system. To be
> changed. At the time the disks were installed (year 2006) 150 GB was
> the maximum for sata fast-seeking-time. With 50 GB for linux and the
> applications, a bare 100 GB space are left for the data. With
> intermediate 2-electron integral files I already encountered lack of
> space, while I plan do use gamess or nwchem code linked to Amber once
> that will become available.

The speed of the seek is probably irrelevant to AMBER simulations. My
investigations show I/O to be an insignificant contributor to
throughput. GAMESS is more dependent on disk speed, though,
especially if you cache the integrals on a local disk (probably not a
good idea in 2009 unless it is an enormous molecule, but in that case,
a few GB of disk space is probably an insignificant consideration).

In any case, basing disk purchase decisions now on when GAMESS or
nwchem will be interfaced to AMBER is likely a time scale mismatch.
My impression (no inside information) is that such a marriage is
months or years away (unless you write the code yourself, which I
though about doing but decided against: do not know java). The
AMBER/PUPIL people can speak for themselves, of course.

Why not buy two 500GB SATA disks now, rebuild your raid and be done
with it? One day downtime including the time to recompile your
software plus dump/restore time.

Might I also gently suggest that this is slightly off topic for this
email list.

Bud Dodson

> But even for classical MD, where I am mostly involved, I guess that
> investing money in a new fast-seeking-time disk for only 150 GB, as a
> raid 1 replacement, is not for what I really need. I was also
> wondering whether a 300 GB fast-seeking-time HDD is worth the money
> for UMA-type motherboard with 4 dual-opteron cpus and DDR1 400MHz. I
> suspect that a normal SATA disk of 500 GB with 32 MB cache and < 8
> millisecond random seek time would afford much the same performance as
> a fast-seeking disk with 4 millisecond random seek time but much less
> cache.
> Much grateful for either supporting my plan in replacing the disks, or
> pointing out my error.
> thanks
> francesco pietra

M. L. Dodson
Business Email: activesitedynamics-at-comcast-dot-net
Personal Email:	mldodson-at-comcast-dot-net
Phone:	eight_three_two-56_three-386_one

_______________________________________________ AMBER mailing list