>>>>> "Jeremy" == Jeremy Buchmann <jeremy@wellsgaming.com> writes:
Jeremy> Curt Sampson wrote:
>> On Mon, 22 Apr 2002, Jeremy Buchmann wrote:
>>
>>> You minimize the amount of time the I/O takes by using fast
>>> storage devices. This means SCSI.
>>
>>
>> Not necessarially. More disk arms is also a big help, so much so
>> that I would take two IDE drives (assuming that they're fast modern
>> ones) over one SCSI drive any day.
Jeremy> SCSI also has several other advantages...it doesn't suck up
Jeremy> all your CPU time when there's a lot of disk activity, and it
Jeremy> supports command queueing. IDE was designed to be cheap, SCSI
Jeremy> was designed to be good. I've used both and from my
Jeremy> experience, SCSI is The Way.
Well... I wouldn't phrase the problem that 1-dimensionally. There are
IDE drives that support queueing (IBM Deskstar something-or-other) and
some OSs have ATA controller code that really kicks but (FreeBSD, for
instance), so from a software point of view, IDE can work well.
It's even likely that the maufacturing process is nearly identical for
some makes and models.
But the RMA rates for _extreme_ usage don't match. My theory:
I find that IDE drives placed in situations where their request queue
is populated completely for days at a time will fail between 3 and 6
months where SCSI drives can last years in this condition. Pay
attention to the qualification: we're talking not even a milisecond of
unused time for at least hours on end out of a day.
I believe this is due to the SCSI disk having software that will
momentarily stop processing requests to perform a recalibration
... where IDE drives may only do this when they are idle for some
small period of time.
Dave.
--
============================================================================
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: dgilbert@velocet.net | equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=========================================================GLO================