IDE, SCSI And Recording Everything

Raju writes: "For many years we were told that SCSI is superior to IDE. I always made my systems with SCSI and the others in the household got el-cheapo IDE disks. In the past SCSI beat IDE hands-down but now according to Simson Garfinkel, "today's IDE drives are significantly faster than SCSI drives". In the article at O'Reilly Network he talks about the tests they had run for storage of network data on disks. In the light of this article does anyone see any reason for going with SCSI in a desktop machine? For servers with heavy disk usage patterns it might be different due to command queuing." Disk types aren't what the article's really about, though -- it's a top-level look at network forensics (including advice on building a traffic-analysis system), and makes some interesting points about the unbalanced growth of storage and bandwidth.

Comments

Speed

[CmdrTaco (editor)]

IDE may be faster than SCSI in some benchmark tests, but in multiple drive machines where IDE drives share controllers, SCSI will always be faster. Plus, access times and transfer speeds aren't everything. The fact that SCSI supports multiple IO commands at the same time is a major contribitor to the feel of speed.

Re:From experience

[darkonc]

It's not just buffering. The SCSI protocol allows you to queue a whackload of write requests and then go get more data while the disk is processing your queue and then queue a bit more.

With IDE, you have to have the data waiting and ready to go before the hardware buffer on the drive runs out. If you have any sort of latency problems you're more likely to die with IDE than with SCSI -- it's because of what the protocol allows you to do with your data/commands.

Those sorts of problems aren't as critical in normal disk I/O situations, but they will show up as hickups in the data flow if you're pushing the disks/controller trying to get all of your data to/from the disk in time -- especially if you're seeking all over the disk.