Torben,
I do disagree when you imply that IDE performance will catch up
somehow. I just do not think that is technically possible. There's
also a hefty CPU penalty which no one seems able to do anything about.
Then again, there are reasons why few seem to notice it....
The ONLY differences between SCSI and IDE that I think are significant
are that
i) SCSI has stronger bus drivers which allow a better termination
arrangement and therefore a longer bus with more devices,
ii) SCSI is a transaction bus which allows additional operations to
happen during otherwise dead periods.
For users who's capacity and physical reqirements can be met with
with IDE (i.e. many folks), there is no significant difference in the
bus bandwidth available. Furthermore, in such an arrangement, the
drive request re-ordering which can be undertaken by a good
SCSI drive controller could just as easily be undertaken by the host
processor, with minimal timing overhead.
You also mention that the difference between SCSI and IDE starts
to become apparent under NT. My experience is that any decently
threaded O/S is absolutely ripe to handle the HDD device driver
enhancements that could allow the out-of-order execution which
would make an EIDE drive behave similarly to a SCSI (for raw drives
with the same rotational speed and seek times).
My point is that once you have an HDD bus interface which is significantly
faster than the media rate (which both SCSI and EIDE now are), there
is nothing that cannot be done on the processor/controller just as
well as on the drive/controller.
Your point about how much host overhead this might add is well made.
However, until we get I2O, any high-performance CPU which is going
to be slugged with I/O interrupts might just as well do a little
more work to speed up the transfers. This is how I believe Solaris
Server works (the disk transaction intelligence is with the host,
not the drive).
Mark |
