[KLUG Hardware] Re: IDE RAID

[Mike Williams]

On Thu, 23 May 2002 12:01:05 -0400, hardware-request@kalamazoolinux.org 
wrote:
>Message: 1
>From: "Bryan J. Smith" <b.j.smith@ieee.org>
>To: hardware@kalamazoolinux.org
>Date: 22 May 2002 14:01:16 -0400
>Subject: [KLUG Hardware] Re: 3rd party reviews / RAID
>Reply-To: hardware@kalamazoolinux.org
>
>On Wed, 2002-05-22 at 09:06, Mike Williams wrote:
>>Most of the stuff I've read recently, from MaximumPC and others,
>>suggests
>>that IDE RAID 0 doesn't gain you much, at least with the Promise
>>and such
>>controllers.
>
>It doesn't give you crap over the OS' software RAID-0.  In fact, if
>you
>use slaves with masters on the same channel, it can be worse.

Can you elaborate on why?  Lemme take a wild guess:  with IDE only one 
drive can use the channel at a time so you don't gain anything, and there's 
extra overhead in setting up a transfer on the second drive?

>>I seem to remember somebody (Adam?) ranting against them as
>>not even being true RAID cards but regular IDE controllers being
>>sneaky.
>
>Me.  Of course, there _are_ "real" ATA RAID controllers, but only 3
>products.  The Adaptec 2400A, Promise SuperTrak and the 3Ware
>Escalade.

I figured if I guessed wrong the actual ranter would come forward.  Problem 
is those things are expensive.  Fastrack is about $70, but a Supertrack 
will run more like $200.  I'd much rather have a 4-drive RAID 5 than a 
2-drive stripe, though.

>I'm writing an article for a major magazine right now and need
>reviewers.  Let me know if you are intersted.

I'd be glad to.  Reviewing services seems like a fair trade for you 
educating me on the subject.

[snip]

>>Somebody correct me if I'm wrong, but in general, RAID 0 can
>>actually
>>slow you down.  In reading, which is the majority of hard drive
>>activity unless you're editing video or something, rotational
>>latency
>>is the biggest speed factor.
>>Rotational latency being the time you have to wait for the piece
>>of data you're interested in coming around to the read head.  In a
>>stripe
>>set, you have to wait for the data to come around on both drives,
>>which
>>increases the odds that you'll be waiting closer to the maximum
>>time.
>
>If you are using the _exact_same_drives_, the latency is NOT
>increased.

Latency per drive would be identical, yes.  Don't you have to wait for the 
data on all drives to come around, though?  I'm not suggesting that you 
have to add latencies, but the bell curve should lean to the right some.

>In fact, several SCSI drive models have a line for maintaining the
>same
>rotational position or "spindle synchronization" to combat this.  But
>most have found it makes little difference in modern drives.

That's what I was referring to below.  I didn't realize it was a vendor 
specific thing rather than a true standard.

>The additional reality is that _real_ (i.e. non-Win/DOS) OSes queue
>writes and order them as sequentially as they can.

Really?  Why waste processor cycles on such a thing if the SCSI controller 
and / or drive firmware shuffle the write order?  Of course, on most 
machines read performance is much more important than write.

>>SCSI RAID arrays have always been able to synchronize the drives
>
>Er, AFAIK, *NO* SCSI protocol spec does this!  The few drives that do
>are vendor-specific, model-specific.
>
>>so they rotate together, but I've never heard of such a thing in
>>IDE.
>
>Again, if you are using the same models, spindle synchronization is
>not
>that big of an issue in modern drives.  They usually seek near
>synchronous without any additional logic/cabling.

Any idea how that happens?  I can't believe that the rotational speed is so 
uniform that they don't drift.  I'll believe that movement of the 
read/write head is, but that's not the issue when we're talking about 
rotational latency.