[KLUG Hardware] Re: IDE RAID

[Adam Williams]

>>>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.

Yep, that was me, at least part of the time.  I wouldn't define pointing
out that someone sells shoddy product presented as something is simply
is not as ranting: How about a bullet proof vest made of poster board? 
Yes, I'd tell you that you were nuts if you bought one.

>>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.

OK.  But why spend even $70 if the effective payoff is near zero.  Use
MD or LVM, you'll be accomplishing the same thing.  And by tuning your
file system to the RAID block size you'll get optimization from the
buffer cache on down,  which may accomplish more than a knock-off
psuedo-raid drive aggregator will.
 
>>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.
>>>Somebody correct me if I'm wrong, but in general, RAID 0 can
>>>actually slow you down.  

I can,  so can RAID 5.  It requires a rather specific set of
circumstances to occur.  A poorly configured RAID setup will usually
simply fail to offer an increase in performance.

>>>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.  

Give or take a few milliseconds, yes.  OEM stated latency and seek times
are complete crap anyway.

>Don't you have to wait for the 
>data on all drives to come around, though?  

Sure.  But if the load is relatively even there is only 1/x as much data
per drive per transaction.

>I'm not suggesting that you 
>have to add latencies, but the bell curve should lean to the right some.

?  I did enjoy some of John Donne's stuff, I thought that the bell
tolling for me was rather special.  I mean, all those years ago, how did
he know that bells would have a special affinity for me?
 
>>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 

Because most consumer grade firmware sucks.  And you average IDE
controller doesn't do jack to improve performance.

>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?  

If spindle speed is ~identical then the drives are sort of synces, 
they'll be "locked" at a fixed offset to each other.  With bigger
buffers and faster spindles it really just matters less anyway.

>I can't believe that the rotational speed is so 
>uniform that they don't drift.  

It is pretty fixed.

>I'll believe that movement of the 
>read/write head is, but that's not the issue when we're talking about 
>rotational latency.