Re: SCSI or IDE
On Sun, Nov 24, 2002 at 08:45:04PM +0100, Emilio Brambilla wrote:
> hello,
> On Sun, 24 Nov 2002, Russell Coker wrote:
[...]
> ATA/IDE drives/controllers lack the ability to perform "command queuing",
> so they are not much fast on many concurrent i/o requests (this feature
> will be introduced in serial-ATA II devices, I think)
>
> SCSI can queue up to 256 commands and reorder them for maximum
> performance, furthermore SCSI has been developed to be used in the server
> market, so they are optimized for servers (rescheduling commands and seek
> patterns of SCSI has been written for this kind of use!)
There are lots of IDE vs SCSI arguments that are no longer true that still
surface when this topic is recycled.
CPU: IDE in the PIO days used bucketloads of CPU. UDMA ended that three or
for IDE generations ago. It is not unusual to see benchmarks with IDE drives
using less CPU than SCSI drives, though they are pretty much the same now.
Thermal recalibration: Some drives do periodic "recalibrations" that cause a
hickup in data streaming. This is _not_ and IDE vs SCSI issue, but a drive
issue. Some drives were "multi-media rated", which means they can gaurentee
a constant stream of data without "recalibration" hickups. Many low-end SCSI
drives are mechanicaly identical to the manufacturuers corresponding IDE
drive, and hence have the same "recalibration" behaviour. I'm not sure what
the current state of affairs with "thermal recalibration" and "multi-media
rated", but it wouldn't surprise me if the terms have faded away as it's
probably not an issue on new drives. Anyone else care to comment?
Command Queuing: IDE didn't support command queuing, and SCSI did. I thought
command queuing had been available in IDE for ages... A quick search of the
Linux IDE driver source pulls up bucketloads of matches against queue,
including;
* Version 6.00 use per device request queues
* attempt to optimize shared hwgroup performance
: :
* Version 6.31 Debug Share INTR's and request queue streaming
* Native ATA-100 support
And the ataraid.c code includes references to "ataraid_split_request"
commands. The ide-cd.c code also refers to "cdrom_queue_packet_command".
This might not be actual "command-queuing" so perhaps I'm wrong, but I'm
sure I read ages ago that IDE had at least something compareable. Anyone
actualy know?
In any case, command queuing makes a big difference when you have lots of
slow drives sharing a mega-bandwidth buss. IDE has only two drives, so it's
not as relevant. I believe most benchmarking shows only marginal peformance
hit for two IDE's on the same bus (this might be because IDE does have a
form of command queuing, or it could just be because it doesn't make much
difference). I know SCSI shows nearly no hit for two drives on one bus, but
when you compare 8 SCSI's on one bus with 8 IDE's on 4 buses, I bet they
turn out about the same.
> It's true that on many entry-level severs IDE is enough for the job (and
> a lot cheeper than SCSI), but on hi-end servers scsi is still a MUST!
Many "high-end" integrated SCSI RAID storage solutions are actualy A SCSI
interface to a bunch of IDE disks...
The best way to compare bare single drive performance is to compare drives
at;
http://www.storagereview.com/
IMHO, the big win of SCSI is a single interface with a proper bus that
supports multiple devices. SCSI can drive a scanner, 2 cdroms, and 4
hardrives off one interface using a single interrupt. UW SCSI can handle
up to 15 devices on one interface, and not break a sweat.
If you are going to have more than 6 devices, SCSI is the less painful path
to take, though more expensive.
If you have 6 or less devices, IDE is just as good as SCSI, and bucketloads
cheaper.
The IDE raid cards do open up the 6~12 device area to IDE, but I suspect
SCSI is still slightly less painful, though IDE is definitely cheaper.
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: