RE: SCSI and EIDE
Sorry, I just had to get in my two bits about this...
I believe the logic for reordering SCSI IO requests really does belong in the drive. With regard to the performance concerns of the drive's CPU speed for making decisions about the next IO to process: an average seek is 10ms and average latency (time waiting for the drive to spin around to the right sector) is 5.5ms (time for one revolution of a 5400rpm drive divided by 2); on average, the drive's CPU has 15.5ms to think about how to order IOs received while the current IO is being processed. Lots-o-time for your average 16-bit embedded controller.
The drive's CPU can always make better decisions about reordering requests because it knows the details of the drive's parameters and its current state. A drive's CPU can reorder requests based upon seek AND latency; the system's CPU cannot.
Given equal drive parameters, the IO throughput (what matters for multi-tasking OSs) for a SCSI-2 system should be better than EIDE. Where SCSI really begins to shine in IO throughput is using disk block striping (RAID 0) using two or more SCSI disks. You can place 7 disks on a single SCSI bus and come no where near saturating the SCSI bus bandwidth with the random IOs that Linux generates. If one SCSI drive gives you 60 IOs/sec of throughput, seven of those drives gives you 420 IOs/sec of throughput. I only wish it was that easy to increase my CPU performance!
Al Youngwerth
alberty@apexxtech.com
----------
From: Rob Browning[SMTP:osiris@cs.utexas.edu]
Sent: Tuesday, August 13, 1996 6:19 PM
To: Debian User List
Subject: Re: SCSI and EIDE
Sherwood Botsford <sherwood@space.ualberta.ca> writes:
> I agree that you can do this in the OS, but I don't think that it
> *should* be done in the OS.
> 0. In general smarts should be at the point they are used. We had a
> VAX that was about as speedy as a 12 MHz 286 with 287 co-processor.
> However, that vax could handle 8 simultaneous 19 KB terminal lines.
> How? Smart serial cards.
> The CPU should do those tasks that are either too general for
> dedicated hardware, or that don't happen often enough to take up much
> time.
> 1. The OS shouldn't have to care about the layout of the disk.
Not trying to start a flame war here, but if the overhead to the cpu
is minimal, which I would guess it is for seek algorithms, you are
often better off doing it with the cpu. Mainly because changing the
algorithms, fixing bugs, trying out new approaches, etc. can happen
with a simple kernel recompile, and improvment's in CPU speed (which
happen all the time, as opposed to the somewhat slower embedded
controller market) immediately translate to improvements in algorithm
speed. Now if the disks just had some flash ROM and a 386 (or
equivalent that gcc knows about) on board, things might be different.
Either that or a couple of cheap 386's on the motherboard for stuff
like this...
I'm mostly just speculating. I don't know that much about drive
hardware.
--
Rob
Reply to: