[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, 2002-11-25 10:17:44 +1100, Donovan Baarda <abo@minkirri.apana.org.au>
wrote in message <[🔎] 20021124231744.GA27869@minkirri.apana.org.au>:
> On Sun, Nov 24, 2002 at 08:45:04PM +0100, Emilio Brambilla wrote:
> > hello,
> > On Sun, 24 Nov 2002, Russell Coker wrote:
> [...]
> > 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.
> 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;

Command queuing is quite new to ide, and only IBM drives support it up
to now, but others are to follow...

>  * 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

This is Linux' internal queuing, not drive queuing...

> 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

That's not really right. Command Queuing allows to to tell the drive you
want to have, say, 10 sectors scattered across the whole drive. If you
give 10 synchronous commands, you'll see 10 seeks. Issuing them as
queued commands will fetch them _all_ within _one_ seek, if there's good
firmware on the drive. Only the drive itself does know the optimal order
of fetching them, the OS only knows some semantics...

> 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

Or it is because the benchmark doesn't ask _both_ drive to send their
very maximum of data...

> when you compare 8 SCSI's on one bus with 8 IDE's on 4 buses, I bet they
> turn out about the same.

> If you have 6 or less devices, IDE is just as good as SCSI, and bucketloads
> cheaper.

Only true if you don't want to see your devices to send at their maximum
speed _all the time_.

> 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.

That's right:-)


   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

Attachment: pgpNku1AhaKHQ.pgp
Description: PGP signature

Reply to: