Subject: About Triton DMA IDE vs. SCSI performance

From: [email-masked] (Bruce Perens)
Date: Sat, 10 Aug 96 15:13 PDT

On Thu, 8 Aug 1996, Douglas Bates wrote:
> For example, Bruce Perens mentioned on this list some time ago that
> the combination of the IDE controller in the Triton chipset with an
> EIDE drive is as fast as fast, wide SCSI. I found that the system I
> was using had the Triton chipset and enabled the Triton-specific
> optimizations in the kernel. The results were very pleasing.
 
I didn't say wide fast. On my system I am getting about 5 MBPS on IDE from
a Quantum Fireball drive, which is as fast as my narrow fast SCSI drive
on a narrow fast Adaptec AIC-7850 SCSI on the same motherboard (an IWILL
P54TS). The speed seems to be limited by the disk media, not by any 
difference between IDE and SCSI.

From: Sherwood Botsford <[email-masked]>
> That would depend on how hard the disk subsystem is being hammered.
> 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.
[...]
> (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.)

Linux can do the ladder-seek algorithm in software for IDE drives, so
much of the intellegence of the SCSI drive is duplicated for IDE and
you get the closest blocks first just as you would with SCSI. The advantage
of the on-board disk cache is reduced, as Linux duplicates it with its own
cache on a faster bus.

No doubt SCSI works better for multiple devices on a single controller.
However, for my configuration this is probably moot - the Triton
provides two DMA capable IDE busses each with its own PCI bridge, and I
have one disk on each.

	Bruce

---

From: Rob Browning <[email-masked]>
Date: 09 Aug 1996 21:37:28 -0500

> difference between IDE and SCSI.

What have you used for testing?  I'm curious to test my own system.
Something more sophisticated than hdparm -t?

> provides two DMA capable IDE busses each with its own PCI bridge, and I

So from this it sounds like if you have two IDE drives, you are better
off to put one on each IDE bus.  Is that true?  I looked for some info
about this, but never found any.

Also, I started using the md (RAID0) driver on a couple of machines,
and it seems to work well.  However, you can't test performance with
hdparm since it doesn't understand md devices.  Is there a good
alternative?

One one machine I striped 2 identical Quantum fireballs, and things
seem good, but the other machine has drives of different makes/sizes.
The md HOWTO says that you can stripe drives of different makes and
sizes, but it doesn't say when it makes sense (performance wise) to do
this.  I did it (just to try it out) with a 1GIG Fireball and a 500MB
Caviar.  Could this actually be a win?  I know that you have two
mechanisms doing the fetching, but if one drives is slower than the
other, it seems that you might have a problem...

Thanks
--
Rob

---

From: [email-masked] (Wayne Schlitt)
Date: Fri, 9 Aug 1996 21:36:54 -0500

>                                                               The advantage

On-board disk caches have _one_ advantage over the Linux disk caching:

  * When data is read off the disk, the head almost invariably starts
    to read data at the wrong sector.  This disk has to keep reading
    data until the correct data rotates under the head.  It is _very_
    easy to throw this information into the on-board cache, just in
    case it can be used later on.  

Caching disk controllers, on the other hand, rarely provide much
benefit when used with Linux...  The memory used by the caching
controller is better used by putting it on the motherboard and letting
Linux manage it...

-wayne

---

From: [email-masked] (Bruce Perens)
Date: Sat, 10 Aug 96 23:43 PDT

> What have you used for testing? [disk drive performance].
> I'm curious to test my own system.

Hdparm and "/bin/time dd". I was mostly interested in transfer
rate. Note that you have to not read the same data twice, as otherwise
you get fooled by the Linux disk block cache.

> about this, but never found any.

I am assuming that I get concurrency that way.

> hdparm since it doesn't understand md devices.  Is there a good

"dd" is simple-minded, but that's not necessarily bad. There are disk
benchmarks available, but I am not familiar with them.

> other, it seems that you might have a problem...

I have one old Caviar 2340 that I have tried on the same machine, and it
is less than half the speed of the Quantum. You'd have to run a benchmark
to see how the thing performed.

	Bruce