I'm glad someone liked my explanation :)
I recently built a nice dualie AMD 1.4GHz, 2GB DDR, with 2xU160 36GB
15kRPM hard drives. It's (among other things) a proxy server and
mailer. Proxying, especially when also doing mail, involves some
bandwidth (but not excessive, it's only a 1gbit uplink to the LAN), but
it also involves a lot of seeking. The tagged command queuing and
reduced seek times of the SCSI drives are a big advantage on this puppy.
--MonMotha
R. Scott Belford wrote:
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
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
_______________________________________________
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
