Slashdot Mirror
Comparison of Nine SATA RAID 5 Adapters
Robbedoeske writes "Tweakers.net has put online a comparison of nine Serial ATA RAID 5 adapters. Can the establishment counter the attack of the newcomers? Which of the contestants delivers the best performance, offers the best value for money and has the best featureset?"
TFA says nine adapters, but the graphic says eight, whoops.
Go away, or I will replace you with a very small shell script.
After 32 pages, it's probably just best to skip to the conclusion:
http://www.tweakers.net/reviews/557/32
Where it has the executive summary:
Areca ARC-1120: highly recommended
RAIDCore BC4852: recommended
HighPoint RocketRAID 1820A: recommended
For several reasons, we will refuse recommendations on the remaing adapters in this comparison
I think that pretty much covers the jist of the article.
Things you think are in the Constitution, but are not.
3ware Escalade 8506-8 is lagging far behind the competition. Moreover, it misses important features such as online capacity expansion, online RAID level migration and RAID 50 support.
http://www.tweakers.net/reviews/557/6
What they say in the article is almost damning really...
Get a free iPod Nano 4GB!
But RAID is nota one size fits all game - the detail of the article is extremely useful for people who will be tailoring their RAID to a specific application. Yes, this article is specialised, but I hardly see how reducing it to a list of three, relatively meaningless names is helping.
Get a free iPod Nano 4GB!
I had a Rocket Raid 100 (IDE 4 drive RAID1/0) and a RocketRaid 1640 (4 Channel SATA RAID 0,1,5) card. With nothing connected to the 1640 and 2 mirrored drives on the RR 100 the disks attached to the RR100 in bios show up on the 1640, and when windows gets to the boot screen it locks up.
When I removed the drives in windows, it booted up without problems. Highpoint has sent me diag tools to run rather than building this in their lab!
I'm not too impressed with them so far.
Well, cheap+reliable == linux + softraid + Enhanced Network Block Device + Enterprise Volume Management System (or LVM2). It is often faster than non-hw-raid (fake-hw controllers.
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
While I've admittedly not read the entire article (it's really long) I couldn't find much info about drivers. It seems the author basically assumed one would be running windows, which for servers (the most likely place for a RAID array) is a pretty poor assumption. I've tried a number of SATA RAID cards on my linux server (SuSE 9.1) and keep getting driven back to SCSI due to crappy/non-existant driver issues. Thank god for Addonics SATA-SCSI adaptors which work great and have saved me a bunch of money.
It's a nice article comparing performance but without a serious analysis of drivers along with it for Windows AND linux (and Mac if applicable) the article isn't complete. I don't really care which one is fastest if I can't run it on my system.
Both are nice cards, but I would not recommend them to anyone who does not have extensive PC hardware knowledge. They are fussy, carpicious and very hard to troubleshoot when they go wrong.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Areca ARC-1120 looks better on each and every page except for the sequential read/write tests where it tends to come in third [I'm just reading off the graphs].
The RAIDCore BC4852 seems fastest for sequential reads/writes.
BOTH of these have linux support. The Areca supports: Mandrake (9.0),Red Hat (7.3, 8.0, 9.0, AS 3.0), Fedora Core (2, 2 AMD64), SuSE (7.3, 9.1 Pro, 9.0 SLES, 9.0 SLES AMD64)
The RAIDCore: Red Hat (9.0, AS 3.0), Fedora Core (1)
The Areca also supports Windows XP and Server 2003 64-bit versions and BSDs: 4.2R, 4.4R, 5.2.1 (incl. source).
Also, the Areca ARC-1160 (they finished testing after the original article was written, so it didn't make it into most of the text) appears at the top of all of the Index/performance tests, except for "Fileserver - Large Filesize - RAID 1/10" and "My SQL - Data Drive - RAID 1/10".
Video Production Support
SCSI, in its current form, is just opening itself up to becoming antiquated.
Perhaps, though personally I've had far more trouble getting SATA (and IDE) drives to work than SCSI drives and I've used both extensively. Driver issues mostly. SCSI's performance is better in multi-user systems, it's easy to set up, drivers tend to be less problematic especially on systems other than Windows, and it can have more devices attached. People claim it's more reliable though I have no evidence of this, and frankly am a bit dubious of the claim. SATA is also easy to set up and is a lot cheaper, though the drivers are still less ubiquitous than with SCSI and performance doesn't match SCSI yet for multi-user systems. (on a single user system it doesn't matter much)
That said, the next generation of SCSI is Serial Attached SCSI which is compatible with SATA. A SAS controller will be able to use SATA drives if you don't need the extra features of SAS. SCSI isn't going away, it's just adapting.
Sure everyone buys a few spare drives.. but make sure you buy more than one RAID card. If the RAID card goes, unless you replace it with an identical make and model, you can kiss your data goodbye.
That's what I like about software RAID on Linux - you can mount the array on another linux box if you need to.
Have yet to see a good comparison between low-end hardware RAID and Linux software RAID..
London's finest organic fairtrade coffee
I, personally, would completely avoid any card manufactured by Promise or Highpoint as I've had crap luck with them in the past. They're just not very good cards, imho. And I'm not talking about their performance in Linux. I'm talking their performance in general. They're crap by my estimation regardless of platform. After losing data on my Windows 2000 box becuase of a crappy Highpoint card, I'll never buy another.
Anyway, your assertions are not even germaine. You point to the problem with "trick-BIOS" software RAID cards, which have been around for years and are not exclusive to SATA-RAID. They are shit cards, period...have been from the day they were made. Most of the cards in this review, however, are true hardware based SATA-RAID cards.
And, again, they all are supported on Linux. 3Ware, for example, has been a bastion of Linux support for ages.
As for the whole winmodem issue, who cares? What has it to do with a freaking troll blathering incorrectly about Linux not supporting SATA-RAID cards? Besides, the fact is, winmodems are NOT real modems. They're telecom interfaces, but not modems. You need software to make them modems. And I'm not talking about driver software to give access to the cards' functions. I'm talking software that has to implement the modem functionality itself...because the modem functionality doesn't exist on the "winmodem"...because it's not really a modem. Just because we now have linmodems.org and such to provide that software, it doesn't automagically make them "real" modems.
Are you kidding?
RAID 5 can be explained in a few pages - the math, the implementation, the whole bit. Have you ever seen a technical drawing of a transmission? Modern slushboxes are about the most advanced mechanical engineering application that the average person ever comes in contact with (when they aren't at the airport).
You won't find an article that does most of the issues involved in designing and implementing a transmission justice. I know you just meant it as an example, but still.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
At any given point in time, your system is in one of three states:
- partially idle (there's unused CPU and disk I/O capacity),
- CPU-bound (the CPU is fully utilized but there's disk I/O bandwidth available), or
- I/O bound (the CPU has spare cycles, but the disk can't provide data fast enough to put them to use).
I suppose that a heavily overloaded system could be both CPU and I/O bound, but it would require a mix of CPU- and disk-intensive processes that isn't usually seen in practice.Let's ignore the partially idle case, in which there's ample disk and CPU to go around, as it doesn't really matter in this scenario whether the CPU or disk controller perform the XOR operations.
In the case of a CPU-bound process, you're going to incur the additional CPU overhead of the XOR operation. XOR is almost absurdly fast, particularly if the data is in the CPU's cache. I'm pretty sure that modern CPUs execute XOR on at least one byte per clock cycle. But let's say, for the sake of argument, that it takes three cycles per byte. On a CPU clocked at 3 GHz, you'd be able to perform XORs on one gigabyte of data per second if you ignore memory and cache issues. Given moderate memory bandwidth, you're also able to transfer over a gigabyte of data to or from the CPU per second. Given a more reasonable amount of data (say, one megabyte, to transfer), you'd be looking at a CPU impact of around one millisecond to perform the XOR. That's a 0.1% impact at most in a CPU-bound environment, and that's presuming you're doing a megabyte of disk I/O per second.
Now let's look at the I/O-bound case. Here, the CPU is sitting around waiting for the disk I/O to finish up. In this case, it clearly doesn't matter who's doing the XOR operations, since the CPU isn't fully utilized. PCI bus utilization is going to be increased by up to 100% (in the worst-case scenario involving drive mirroring; the worst-case RAID5 scenario is a 50% increase). A typical server's 66 MHz 64-bit PCI bus has a capacity of around 533 megabytes per second (PCI Express increases this dramatically, but let's stick with pessimistic examples for now). At the moment, a SCSI bus tops out at 320 megabytes per second, and those transfer rates are only achievable with at least four drives on the channel and an almost exclusively sequential I/O mix (the best-case numbers for a 15,000-RPM drive are about 100 megabytes/second). So there's generally bus bandwidth to spare.
You raise a number of other points in your note that are potentially issues (hot swappability, for example). But I've become convinced that the CPU/machine performance argument against software RAID really only made sense when CPUs/memory/bus bandwidth were much more constrained.