SCSI and EIDE
On Fri, 9 Aug 1996, Wayne Schlitt wrote:
> > On Thu, 8 Aug 1996, Douglas Bates wrote:
> > > the combination of the IDE controller in the Triton chipset with an
> > > EIDE drive is as fast as fast, wide SCSI.
> >
> > SCSI's advantage is that it can handle multiple outstanding requests at
> > the same time, while EIDE has to wait for one to complete before it can
> > start a second one.
>
> SCSI can handle multiple request to _different_ devices on the same
> SCSI bus, but I don't think you can have multiple requests to the same
> device.
Yup, it can. One of the parameters exchanged on start is how many
requests the device can queue. Typically queues range from 16 to 50.
But don't ask me to back that up -- top of hte head number.
This is one of the big differences between SCSI 1 and 2. That and the
disconnect/reconnect feature. (Don't *ever* buy a scsi 1 tape drive.
Everything stops when you rewind the tape.)
> > with a a few meg of cache
> > on the drive. (This allows the drive to start being clever and resort
> > the queue'd I/O's for fastest return. E.g. If the head is on cylinder
> > 7, and it gets a read request for cylinder 2000, and cylinder 500, it
> > will do the 500 on the way to the one for 2000.)
>
> This is known as elevator seeking and should be done at the OS level.
> The order that data is written out is very important for data
> reliability, and for this reason, I don't think any hard disk change
> the order of the writes.
There are several different algolrithms for doing this. Elevator seek
is the simplest of them. Some put a higher priority on reads over
writes. Some re-priortize the queue so that requests that have been
outstanding for a while get bumped up the queue.
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.
2. I don't understand why the order matters for reliability --
unless you're talking about power failures. This is a low order failure
mode -- which is why you do backups -- for those rare occasions when the
disk does lose a file when the lights go out. The disk is smart enough
to recognize that a new request to write out sector 12345 makes the
previous request to write out sector 12345 invalid.
3. The kernel of any unixen caches metadata for most of the file
system for long periods of time. This is the whole point of the sync
daemon -- to flush this out to disk.
>
>
> The really big problem that IDE had that EIDE fixed was that IDE
> couldn't do DMA, so the OS had to move each byte from the disk drive.
> On the other hand, SCSI's command overhead can be significant, often
> adding up to 10ms to the simplest command.
>
>
> I would expect that if you only have one disk per EIDE controller, you
> will significantly outperform a single SCSI bus with two disks on it.
>
>
> -wayne
>
>
Sherwood Botsford |Unsolicited email that advertises commercial
Physics Dept |activities will consitute a request for
U of Alberta |spellchecking of all words of less than three
Edmonton, AB, |characters. I charge $US500 for this service.
T6G 2J1 |There is no warranty of correctness of this service.
Reply to: