[luau] INFO: Heavy duty storage needs
R. Scott Belford
sctinc at flex.com
Thu May 2 16:27:22 PDT 2002
I have searched for such a concise and practical explanation of why SCSI
is accepted as the better storage solution for high-intensive seeks.
Now I understand. Thanks for explaining this so clearly.
On Thursday, May 2, 2002, at 12:46 PM, MonMotha wrote:
> This is true. In terms of raw I/O speed, IDE drives have caught up
> with SCSI. The reason? The bus is no longer the bottleneck. Even the
> best of SCSI drives would have trouble saturating a 100MB/sec bus
> (though SCSI is 160). If all you need is raw I/O speed (which is a
> good chunk of what your average single user desktop will be working
> with, especially if they're doing a lot of multimedia), IDE drives are
> a great choice (especialy combined with a software RAID solution, such
> as the Linux software RAID or some of the software "RAID" cards that
> are now out for the 'dozers).
>
> SCSI shows it's strength in Tagged Command Queueing. Unlike IDE
> devices, SCSI drives can work on more than one command at the same
> time, queueing them up in the best way possible. For example, an IDE
> system where a person wants to simultaneously (quicker than a single
> seek on the drive) pull information from 10 places on the disk will
> have to do them in the order the system says. With SCSI, the system
> can send all 10 (or usually 9) requests in quick succession, and the
> drive will service them in the best way possible, minimizing redundant
> seeking, serving out of cache when possible (often even during a seek
> for the next command in the queue), etc. In multiuser environments,
> this can give SCSI a HUGE advantage over IDE. SCSI drives also tend to
> have lower seek times, often due to smaller platter sizes rotating at
> significantly faster speeds (15,000 RPM vs. 7200 or even 5400 RPM).
> This is also the reason SCSI drives tend to have smaller capacity as
> compared to IDE drives while still being expensive. The same
> "technology" has to be used to pack all those bits into a small space,
> but the overall space is smaller (many SCSI drives could almost fit
> their platters into 2.5" laptop HDD enclosures, see fujisu specs on
> platter size). These lower seek times also help performance in
> multiuser environments.
>
> Also, though this is not as much of a deal with UDMA IDE, IDE uses the
> CPU for some of it's processing. The same things are done on SCSI on
> the dedicated controller and onboard the drive itself.
>
> Conclusion: Don't assume SCSI is better, but don't assume raw I/O
> bandwidth is the only measure of a hard drive.
>
> --MonMotha
>
> R. Scott Belford wrote:
>> If you intend to record most or all of the traffic moving over your
>> network, you need to spend as much time thinking about your disk
>> subsystem as your processor and Ethernet card. Last year Sandstorm
>> spent several months comparing IDE drives with the UDMA100 interface
>> to SCSI LVD-160 drives. We also explored a variety of RAID systems.
>> The conclusion: today's IDE drives are significantly faster than SCSI
>> drives costing two or three times more per gigabyte stored.
>> This is not the result we were expecting, and it goes directly against
>> the conventional wisdom that says SCSI is inherently better than IDE.
>> Nevertheless, it does seem to be the ugly truth, at least for
>> straightforward read/write tests in a single-user environment.
>> Although we saw the highest performance with a hardware-based RAID 5
>> system manufactured by _Advanced Computer & Network Corporation_, we
>> saw nearly the same performance with a RAID 5 system based on the
>> _3Ware Escalade 7000_ RAID controller.
>> from an article about network data capture at
>> http://www.oreillynet.com/lpt/a//network/2002/04/26/nettap.html
>
>
> _______________________________________________
> LUAU mailing list
> LUAU at videl.ics.hawaii.edu
> http://videl.ics.hawaii.edu/mailman/listinfo/luau
>
More information about the LUAU
mailing list