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 [EMAIL PROTECTED] for more info, including pgp key ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]