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.
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!
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
3ware, It's a waste of /my/ time. So I really don't
care what the tweakers think.
The 3ware cards are reliable, easy to deal
with, have brilliant drivers, good software,
and they WORK!
Always!
I have a 5 of them. I have a friend who has 40,
he agrees.
I use a 2 channel as a backup-to-sata drive, (cheaper than tape), another 2 channel in a
IIS server for payroll stuff, 1 4 channel for
a mail server and 2 8 channels for file/web.
I love'em.
Nuff said.
Moral of this story? You get what you pay for. SCSI should be used for servers.
To be fair, however, I was never able to determine if it was a result of using S-ATA, 3Ware or the linux device driver.
-- Thou hast strayed far from the path of the Avatar.
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.
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.