>>>>> "Jeremy" == Jeremy Buchmann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly