First of all I'm not sure about what the function is of the
script you refer to
Emory,
Your "simplistic" description of what a SCSI controller does is
very good (infact it's absolutely right).
To elaborate.... A CPU is a machine that executes a sequence of
instructions from a memory array. Early I/O devices were not this
smart, and required the CPU to baby-sit them. However, sometime
after the system architects got bored with having a powerful CPU
sit around and "poke" a dumb I/O controller with the commands it
needed to do anything sensible, they worked out that an I/O controller
could be just as smart as a CPU. The emancipation of I/O first
happened with Ethernet controllers. With the new type of
semi-intelligent I/O, the CPU sets up a region of memory with a
whole sequence of instructions for the I/O device (in EXACTLY the
same way as the CPU gets its own tasks from memory). Having
initialised such an area of memory, all the CPU has to do is tell
the I/O to start "executing" this set of commands; the I/O controller
then independantly goes away and does all that is asked.
In the ethernet controller world (where this started), the memory
area with the commands was said to be a "descriptor" area. For the
early SCSI controllers with the same intelligence, the commands were
said to be "scripts". (To my knowledge the NCR (Symbios !) 53C700
was the first of these intelligent SCSI controllers). Whatever the
name, the bottom line is that the CPU can set up a list of I/O
commands which the I/O device then executes at its own pace. The
I/O controller only needs CPU intervention once the tasks are
completed (or if something goes wrong !)
This "scripts" capability makes modern SCSI controllers very efficient -
i.e. once the CPU has worked out what is required of the disk
sub-system, it only has to set-up the instructions and it is then
free to do other work. Earlier style I/O devices (including
relatively recent IDE controllers) needed constant attention
from the CPU, which of course meant the CPU was not free to do
other work.
However, the bottom line here is regardless of what physical connection
is used to join the controller to the peripheral (i.e. IDE or SCSI),
the "scripts" intelligence can be built into either type of controller
to allow it to fetch its own command sequence. Whilst IDE controllers
have lagged SCSI controllers in this respect, the latest EIDE devices
have this capability. It is now only the device-drivers for
these items (i.e. software) which might prevent them achieving their
potential.
Mark
p.s. R2O made some very detailed points in two great posts. The
only things I can add are -
1) the media rates on many HDDs are currently >200Mbit/s (~20MB/s).
2) a decent hi-end CPU running at 300MHz is capable of executing
many multi-byte instructions per clock. The feed rate for such a
device is therefore around 2 to 5 gigabytes/sec. (Which means it
is capable of consuming data several orders of magnitude faster
than any HDD sub-system can provide it..........). |
