Re: OT: SCSI better than IDE?

• Previous message: J.H.M. Dassen (Ray): "Re: Is there any encrypted or secure NFS?"
• Maybe in reply to: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Next in thread: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Reply: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Reply: Karsten M. Self: "Re: OT: SCSI better than IDE?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Debian-User Mailing List <debian-user@lists.debian.org>
Date: Sat, 03 Jan 2004 15:16:23 +0100

Hello,

(one of my favorite off-topics... I couldn't resist)

Once upon a time (until the early pentium machines), all IDE access had
to be handled by the CPU. The apparently simple process of reading a
file into memeory would produce severe system load on the order of +-
40-60%. Handling large files would render your machine unusable for
minutes even if there was little actual data processing taking place.

While with SCSI, much of the I/O would be done by the controller,
leaving the CPU free to do the actual work. Every end-use could feel
this with tasks like converting a sufficiently large image to grayscale.
Or, much worse, dealing with audio or (god beware) video data.

This has much improved with Intels' Triton chipset, IIRC the first to
offer DMA for IDE. Now the I/O for IDE devices is almost as smart as
SCSI. The difference is still measurable but slight -- everything else
being equal, the user will no longer 'feel' the SCSI machine to be
faster than the IDE box. Period.

However, SCSI offers another advantage. With IDE read requests, the
controller opens the connection, sends its query, and waits.... until
the disk has eventually found the chunk of data and served it.
In contrast, and SCSI disk may disconnect from the bus after it has
received the request. It will seek the file, read it into it's own
cache, and only reconnect when it is finished and can send the data down
the line in a burst. In the mean time, the SCSI bus is available for the
host adapter to talk to other devices.
For a single acess, this protocol overhead will actually lead to higher
latency times.

Now consider today's seek times of a few milliseconds combined with high
transfer rates. Add the tendency to have RAM in abundance that's mostly
used for buffering data.
To enjoy the benefits of the SCSI disconnect feature one must have
several disks in a box and much IO going on with all the disks at once,
over a prolongated time. Think of a large and busy database. Very large
and very busy. Not dozens, but hundreds of requests at once -- Google
perhaps, or FedEx, or a Bank.

For single-user workstations, you would need very special needs to come
up with a scenario where SCSI would provide a 'feelable' advantage.
Certainly, you may from time to time point to your screen and say 'this
process went faster because of SCSI', but doing so will likely waste
more time than you just saved.

cu,
Schnobs

-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

• Previous message: J.H.M. Dassen (Ray): "Re: Is there any encrypted or secure NFS?"
• Maybe in reply to: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Next in thread: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Reply: Paul Morgan: "Re: OT: SCSI better than IDE?"
• Reply: Karsten M. Self: "Re: OT: SCSI better than IDE?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]