There are several things worth noting:

1. The Adaptec 2400A uses RAID 1+0, just like the Escalade series, so the article is very misleading, if not inaccurate. See this page for an explanation of the differences between RAID 1+0 and RAID 0+1:

http://www.ofb.net/~jheiss/raid10/

However, Adaptec, in their documentation, does not make the distinction clear and uses nonstandard RAID level notation. So the reviewer cannot be fully blamed, although with all of those days of running tests and setting up arrays, it should have been obvious that they were testing RAID 1+0 on the 2400A, because you must create mirrors first, then the stripe, not the other way around.

2. The 2400A's slow rebuild times have a reason: To check carefully for bad blocks and eliminate them!!! If your RAID 1 controller blindly copied a mirror and assumed everything was fine without read verification on a newly added drive, you'd be pissed if the drive it copied from went out and you were left with your only copy on a drive which is flakey. It is true that modern IDE drives do a lot of this kind of checking behind the scenes automatically, but it is good to have a RAID controller that makes sure everything is okay. Perhaps if the 2400A firmware had an option to turn off or reduce the level of verification, this performance concern would be addressed without having to sacrifice reliability.

3. The 2400A has options to enable or disable writeback caching. If your computer is on a UPS, writeback caching is generally safe, and a 128 MB cache on the 2400A improves performance.

4. Since this was an article concerned with performance, and since the 2400A was getting "low marks" everywhere except on CPU utilization, the reviewer should have stopped and considered adding 128 MB of RAM to the 2400A, and given it more benefit of the doubt instead of accepting numbers at face value.

5. More testing of real-life applications, such as using gcc to compile Mozilla from scratch on Linux, would be helpful. Not everything is a "read one file, operate on it, write it out" single-task application. That is the Win3.1 or DOS way of looking at things, and maybe it can work for certain games, but it's not real life.

The 3Ware and Adaptec controllers are more Promising on real applications (pun intended). If you want LED diagnostics, mature software/firmware, zero CPU utilization, and reliability, go for the 2400A.

I'm curious to know where you found the 1.1.0.15 bios for the sx4000 card, it's not listed on their sites. I'm having some issues with the SX4000 and large drives, and that might do the trick.

Walt C is both right and wrong.

Say we have a RAID 0 with two Western Digital 120 gb Caviars. For sake of argument, say the MTBF is 10,000 hrs.

Now let's compare it to the MTBF of two other WD 120's that AREN'T in a RAID. What happens?

Well, they both fail in much less time than 10,000 hrs because MTBF is BS nonetheless, but the results are more catastrophic when a WD 120 in a RAID fails because its failure effectively nukes 240 gb of space, whereas 120's that are independant only lose 120 gb.

So therefore, the mean time between failures is effectively the same, it's just that the failure is more devastating.

However, say we scale it up to be a raid 0 of 100 drives. The standard deviation from the mean grows bigger and bigger with each drive you add, and since the entire raid fails when the weakest drive goes....

I'd be interested in knowing why they didn't test the Promise card with the max of 256MB of memory and even what the performance and such was like with even as little as 64MB. Someone correct me if I'm wrong but I only read that 128MB was used.

I would also call into question the stripe and cluster size used. Going with defaults is not always the ideal way to go or we would never update drivers beyond what comes with Windows at install time. :)

#107, yes, I would agree that the 2400 is a fine choice for Raid 5.

I have it. After getting nailed by the GXP hard drive issue, I checked every review I could get my hands on concerning the cards and Raid 5. I settled on the 2400 over the escalade, fastrack and others. (I don't think the fast track was yet available in Raid 5 when I made my purchase). I set up a raid 5 consisting of one remaining GXP 60 gig disk, and two new boxed Maxtor 60 gigs. With that setup, I installed W98SE, and left out Gnu/Linux because of the slight complexity with setting up a driver for the install, and I'm new to Gnu/Linux. I left the hot swap/hot spare port empty (you can add a fourth drive on channel 4 as a hot spare, which will automatically start rebuilding on a single drive failure).

When SUSE 8.0 came out, I installed a spare drive on the motherboard, backed up data to the spare drive, then installed SUSE 8.0 to the array, as a dual boot install. SUSE 8.0 recognized the raid setup as a highpoint if I remember correctly (must be the chip), and I've had a dual boot setup on raid 5 now for over 18 months. I finally had the last GXP hard drive fail over 6 months ago, recognizing the noise of the failure instantly as the GXP failure issue. So I had a raid 5 with a failed drive. No problem. I'll simply plug in another 60 gig drive into the fourth channel as a hot spare, and it'll rebuild, right? Wrong.

It appears that Maxtor 60 gig drives sold as oem or sold to dealers are not the same size as Maxtor 60 gig drives sold as a retail boxed drive. So I plug in a new Maxtor 60 gig hard drive to rebuild my array, and it won't build because the new Maxtor is about one and a half gig smaller than the original boxed Maxtors. So what are my options? Transfer the data to the spare drive plugged into the motherboard, wipe the original array, and start over.

Having been stuck with several failed hard drives, I'm not spending anymore money on hard drives till they get so cheap its a joke. Besides, I'm buying the Lindows computers for just over $200, wiping them and installing SUSE Linux on them, so I'm getting all the storage space I need for free.

So what do I do? I install the new array as a raid 1, with two drives, and manually back up to a third drive on the motherboard. After the last Maxtor failure, I have a raid 1 array with one drive, one missing (failed) drive, and one spare hard drive on the motherboard I'm backing up to.

Given the high failure rate of 7200 rpm hard drives, and the manufacturers failing to stand behind them (IBM) or cutting warranties from 3 years to one, and all the games they play for returning the drives, etc., the only thing I can recommend is to stick with 5400 rpm drives for critical data, use the 2400 in Raid 5 with hot spare installed AT THE SAME TIME as when the array is originally built, and cross your fingers.

If you need faster drives, I suggest you get a solid understanding of how the adaptec works under raid 5, and how to restore failed drives in arrays, prior to trusting the array with your data. The manual and web site DO NOT get specific and detailed into failures. For a mission critical setup, if you are planning on using IDE raid, I'd recommend using two 2400 cards in raid 51, with hot spares pre-installed, and a secondary online backup/mirroring system for data, such as another computer with same setup, or a storage array. If the data is backed up on another system you are OK, but if the array also holds your operating system and applications for other users, then you need a redundant backup if you have problems getting the array back to optimal condition. Don't forget, if you lose one drive in the raid 5 array, until the array is built back up to optimal, you are susceptible to losing everything. Also, the more changes are made (different data) to the array before the array is back in optimal condition, the longer and harder the array is to rebuild. And the array will perform much slower while it is rebuilding or while missing one drive.

One more thing. The giggle factor alone is worth it when you see how fast the array performs when you first fire it up. I laughed for almost a week while getting used to how fast the array was when I first set it up.

If I am reading the graphs right, the high CPU utilisation on RAID 5 of the Promise is actually a relative measure, because at 6% who cares?

I've got a rocketraid 404 in my dualie workstation and it SMOKES! The box boots xp in like 15 seconds! All in all, I'd go with raid 0 over the 2nd processor. best computer investment I've made in quite a long time.

GO BUY ONE NOW... haha ;-)

Hey, check out highpoint's newest 4-channel ide raid.... watchout promise!

"I looked into the benchmark results, and I found out why the 3ware Escalade
card performed below expectations in the ATTO Bench32.exe benchmark results.

When the Bench32.exe program runs in Direct I/O mode (i.e. the Direct I/O
box is checked in the Bench32.exe program, which is the default), then all
writes to the disk drive are sent with the FUA bit set (when Windows basic
disks are used). FUA stands for Force Unit Access, and is defined for SCSI
devices. The 3ware Escalade card, Adaptec 2400A, and the HighPoint
RocketRAID card all appear as 'SCSI and RAID controllers' to Windows 2000.
The FUA bit is a way that a computer program can ensure that data is written
to the physical medium of the disk drive, and not just cache memory before
it is acknowledged.

Here is the definition from the SCSI spec, on page 15 of Information
Technology - SCSI Block Commands - 2 (SBC-2), Revision 4 dated 28 July 2001:

"Sometimes the application client may want to have the blocks of data read
from the medium
instead of from the cache memory. The force unit access (FUA) bit is used to
indicate that the
device server shall access the physical medium. For a write operation,
setting FUA to one causes
the device server to complete the data write to the physical medium before
completing the
command."

When Bench32.exe is run on a Windows 2000 basic disk, with the Direct I/O
box checked, all writes to the disk drive are done with the FUA bit set.
The 3ware controller honors this bit, and sends a flush command to the disk
drive after every write to ensure that the data is truly written to disk.
That is why the 3ware card shows lower numbers. Even though the Adaptec
2400A and HighPoint RocketRAID cards receive the write command with the FUA
bit set, they do not send the flush command to the disk drive. This can
easily be verified using an ATA bus analyzer.

When Bench32.exe is run on a Windows 2000 dynamic disk, then the FUA bit is
not set when using Bench32.exe. As you can see from the benchmark results,
this results in much better performance for the 3ware controller."

David Graas
3ware Inside Sales Manager

Something to point out is that Promise products only go up to 6 ports per card, while 3Ware had 8 port cards out a year ago, and now has 16 port cards available.

This is important because I don't believe any of the IDE RAID cards allow you to combine arrays on different cards (at least not with hardware raid).

I have been running 2 8-port escalade cards with 8 100-Gig Hard drives hanging off each for a year, and have been pretty happy with it.

#116:

thanks for pointing that out.
2nd page of this pdf:

http://www.mast.queensu.ca/~stat455/F2001/resources/lecturenotes/le...

"So one can see that as <lambda> gets larger, the thing in the process we're waiting for to happen tends to happen more quickly..."

i'm still of the opinion that a binomial probability explaination and an exponential distribution explaination can co-exist equally. :)

FYI,

Here's a new comparison btwn IDE RAID and SCSI drives:

http://www.xbitlabs.com/storage/ide-scsi/

#87,

The book and author were mentioned in my post, #82. I am referencing the 6th edition, page 508. Try this too.

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=expected...

backing ab up, what he's saying by " vendor supplied" is not redhat, but (for example) Highpoint.

Originally Posted by anonybomber
#112 - I think the reason those and many other drivers weren\'t listed is they aren\'t vendor supplied drivers, they are open source reverse engineered ones.

Its great that there are open source drivers, but many times a vendor provided one will expose more features or performance, and are often stabilier. For those reasons many will not touch a card that doesn\'t have a vendor supplied driver for their OS.

One user commented that the Ata 100 performance scaled better than the ata133 performance. see this - http://tech-report.com/reviews/2002q4/ideraid/index.x?pg=16

But thats not all. In pretty much every graph (there are a few exceptions) ata100 is better than ata133. Is this due to more crc overhead? Could this be caused by overly long cabling/non-ribbon ata cables (rounded ide)? Seems very strange. I am wondering wether I should lower my drive speed down to ata100. Less cpu usage, lower access times, .....

anyone else?

oldfogey

I think you'll find the reason for Promises poor CPU utilization is because it is still a software raid controller compared to the Adaptec and Escalade which are hardware based. On the other hand promise has the Supertrak series which is SUPPOSED to be I2O hardware based.

NOTE: I tried the Supertrak 66 from promise on Suse 8.0, and Version of RedHat from 7.2 all the way up to 8. Despite the fact that it is suposed to be I2O all the distro's I tried crashed hard when the I attempted to load the drivers.

SO, I went and got the Adaptec 2400A and installed it. In less than an hour I had RH8 up and running with the NATIVE DPT drivers which you failed to mention in the review for this cars support. (SCO only was listed).

As far as benchmarks, I haven't done any. I'm just using this at home. You might ask why I spent so much for a home controller card? Because I wanted raid 5 and I have REALLY important data that I dont want to lose (again).

Another plus of the Adaptec card which I am not sure exists in the other cards... Online Capacity Expansion. Not trying to bash the other cards here, but between the hot swap and OCE funtctions of the adaptec card, that is a real plus. As I read it, the system still has to be rebooted, but unless you are really anal about your uptime scores who's gonna complain....

I am quite amazed at the poor performance of the adaptec card at raid 1. I really expected more from this card, but since we're talking about such inexpensive disks, I don't understand why people still use raid 1. Must be the bad economy ;)

Anyhow. thanks for the great review!! I really wish one of these cards had come out as a shining star, but in the end you get what you pay for...

i don't think you get it, waltC.
i mean, math is what it's all about. people wouldn't come up with formulas if they didn't actually apply in the real world.

i can't even think of a way to describe things more clearly than with the probability explaination i gave earlier. please, go back and re-read it more carefully.

if you still say that the chance doesn't increase (recognize, i'm not saying it's doubling, just incerasing), then i guess we'll just have to agree to disagree. :)

I'm not too worried about a one year warranty on a $80 card. If it fails after the first year, I can throw it away and buy another one - and still have spent less than the next cheapest card! Moreover, the replacement card will either have more features or cost less.

so, the chance DOES increase that the "virtual drive" the RAIDing produces will fail, and i'm sure that's what was meant by your MTBF. but you're right, the MTBF of each individual drive doesn't drop.

Yes, that was the central point I wanted to make (however, I'm sure along the way I made some other maybe-not-so-intended-points, as is my curse...;)), that:

Adding a second drive does not affect the MTBF hour estimates of either drive.

Again, I have to disagree with those who think a strictly mathematical view is the correct one. Unfortunately, the math used here leaves out the variable of component quality. You factor in component quality and you might get a scenario like this:

Company A sells 100,000 drives and has a failure rate of 15% within three years

Company B sells 100,000 drives and has a failure rate of 3% within three years

Or, Company A sells drives A and B of varying quality, with failure rates over three years which match the above numbers, respectively

So clearly, the number of drives is not a major factor in the odds of premature failure computation. Theoretically, a MTBF hours computation takes into affect the reliability of as many of the physical components used as there is a record for while estimating the rest. It also assumes certain constants as to temperatures and etc.

Basically, a MTBF hours computation is supposed to provide as accurate a projection of a given drive's likelihood of failure as it is possible for the manufacturer to make. However, these can also be used for advertising and marketing purposes, and so may not be fully reliable (everybody knows the MTBF hour numbers for drives could be cut in half, or doubled, depending on each individual drive, and aren't meant to be an absolute projection of reliability.)

But given that the first drive's MTBF hours don't decrease with the addition of a second drive, it hardly seems relevant to say "Yes, but because you now have two drives your odds of premature failure double," IF the probablility that either drive will fail prematurely (based on MTBF hours) is remote.

IE, I think it's silly for people to be afraid of RAID when they're using quality drives, because they think the possibility of drive failure has doubled with the addition of a second drive. Rather, I think they should view it with all the trepidation they usually feel in adding a second, non-RAID drive into their systems. I mean if you have two, non-RAID drives, and one is the boot disk and the other is not (*chuckle*), if you lose the boot drive--you are exactly where you'd be if one of your RAID drives went down. (And before anyone says "backups"--A RAID system can back itself up, too.)

Originally Posted by dissonance
AG106 - I tested array rebuild times, which are graphed in the review. That involved pulling a drive, formatting it, and letting the array recover and regain redundancy with the new drive. That should cover what you\'re looking for.

Looks like the Adaptec is a fine choice for RAID 5. The conclusion kinda doesn't mention this.

I simply can't believe you did an article of this size and complexity -

without testing the one thing that RAID is usually used for, in the real world.

Recovering from failure. How could you not once pull the plug on a drive and see if it recover?

A high performance raid system that can't recover from a failure is not worth anything.

How about a link to a PRINTABLE version of this article. It would be nice if you guys offered a web print or PDF version of this so it can be read later, or taken home to show a friend, etc.

Please put up such a link.

Originally Posted by reca
(#101)
Besides, do you really need to write those 100Mb chunks in 2 seconds?. I don\'t know what constraints do you have, but 100Mb isn\'t that much to hold for a while in 1Gb and you can even add some]

We produce digital videorecorders, the machine considered is one of our products, we save wavelet images on the disk in blocks of n images per time, so if the dvr is turned off we are not loosing a lot of images, the target for this machine is the largest archive possible, this means weeks/months of recorded video.

Really we\'ve more configurations, we are using Promise too, that seems to work in a more regular way.

We tried 3ware because for dvr recording up to 16cameras we\'ve the pci bus managing 4 video acquisition boards (usually having about 40->80 mbytes per second as bandwidth) , and we want to use the other 1gbit bus for the raid to not saturate the pci bus, since 3ware produces 1gbit raid cards, we tried its 7500 - 4/8/12 family, but we found some problems that we can\'t work around, the one is that deleting files takes a very long time.
We\'re looking for raids that can write at least 50megs per second continuously, 3ware looks the best, but we\'re having the deletion problem, so until now didn\'t find a valiod choice.

Consider that the price is not a problem, this machine can cost up to 30.000$ to the final client, and usually these kind of clients are not looking to the price, so if you can suggest me a valid choice you\'re wellcome.

Consider that we use XPEmbedded too

can you compare to a scsi raid 5 and riad 10 ?

Great review, Diss.

Good comment #76. It would have been interesting to see all those results compared to a WinXP software raid setup. That way we could see which are real RAID, WinRAID, and those that fall somewhere in between. Then we would have a better feel for cost/performance.

reca(#96)
[i]
We use a 3ware escalade7500-12disks in raid 0 with 12maxtor diamondmax 160gbytes disks on a supermicro doublexeon machine with 1gbytes memory onboard, a pci bus and a 1gbit bus that has the raid connected.
[...]
Anyway without this problem this raid showed us that is able to record about 50mbytes per second in a continuous way without loss of performance (when the disk is not full) the maximum timing we found for a write operation is less than 500msecs. without the deletion problem it would be nicer.
[/i]
I agree with AG#97 - it should be turning the hdd write cache off. I have to add that having 12 IDE drives in RAID 0 and no UPS is extremely unreliable. Do you have one?

Besides, do you really need to write those 100Mb chunks in 2 seconds?. I don't know what constraints do you have, but 100Mb isn't that much to hold for a while in 1Gb and you can even add some.

My recommendation is going for RAID 5 or (if the performance is as bad as it looks in this review) JBOD. 12-drive RAID 0 spell disaster. If you lose a drive in a JBOD at least you don't lose EVERYTHING. I think escalade7500 doesn't support RAID 6. I think it would be the choice here.

But yes, SCSI is really expensive if you need those nearly 2Terabytes. But again, I don't know what your company budget is and if you really need that much storage (all in hard-drives).

A comparison to software raid 0/1 in recent windows releases and 0/1/5/10 in linux without a controller might have been good too.

On two of my systems, using a highpoint 372 and a 374 in JBOD mode, with (linux) software raid 0, the performance of a 2 disk raid 0 is identical to the highpoint raid-0 when setup in the hpt bios. Likewise for a raid-1 mirror.

Earlier testing I did with 1 disk on each onboard ide channel, and software striping/mirror also show performance at the highpoint level - provided any secondary device (like a CDRW/zip disk) are not in use at the time.

So - for many systems, you don't even have to spend the $80 bucks on the rocketport to give a performance or redundancy boost to your system.

Do you have a reason the ATA100 write tests to a single disk showed linear increase with file size, but the ATA133 checks did not ?