I have a couple notes:
I believe the Areca ARC-1220 uses an IOP-333, rather than IOP-332.
Then again, Areca do seem to update their board designs during the years.
Specifically, all Areca controllers used to have one common outstanding feature:
the separate onboard RAID5/6 XOR ASIC chip, which provided sustained sequential
transfer rates of up to 250 MBps (writes). The reads were actually a tad slower,
maybe 220 MBps. All of this meaured using "cp /dev/zero /dev/sda"
or "cp /dev/sda /dev/null" in Linux, i.e. at the raw block layer.
All of this was available several months before Intel managed to add
RAID6 capability to the later revisions of their IOP333/331 silicon.
This sustained performance level used to be fairly uniform across all the
Areca controllers of that generation. Areca even used to make (or still makes)
external controllers based on the Intel IOP219, which has no on-chip XOR
accelerator at all, and still the performance is the same, owing to the
Areca XOR ASIC.
Looking at the current version of the Areca product web, I have to admit
that it seems as if they ditched their (TM) auxiliary XOR chip in favour of
the Intel IOPs' on-chip "application accelerator" subsystem, even in that
traditional product line.
This would explain the different figures that the THG benchmarks report,
specifically the lower write throughput. The figures are now closer
to competing products that are based on the bare IOP331/333 silicon.
Note that in the meanwhile, there's a new generation of Areca RAID
products - the various MultiLane boards with SFF-8087 connectors,
such as the ARC-1261ML.
http://www.areca.com.tw/products/pcie341.htm
They're based on the Intel IOP341, and though I've never had a chance
so far to benchmark any specimen of that family, based on analogy
with recent external Areca controllers I am fairly confident that with
SATA drives, these controllers will achieve between 500 and 600 MBps
sustained sequential transfer rate into RAID5 and RAID6.
The external ARC-8100 model actually exceeds 800 MBps,
http://www.areca.com.tw/products/sas_to_sas.htm
but that's with SAS drives. It seems that SATA-II drives come with a
performance penalty on RAID, difficult to say if this is due to the electrical
interface, or due to other factors (latency?), generally related to the
"desktop vs. enterprise" comparison between SAS and SATA-II
disk drives on the market today.
For comparison, in my tests, the recent Adaptec 3805 has maxed out at some
380 MBps (read rate from 5 SAS drives), I believe I've observed a write rate
of about 320 MBps. The Adaptec doesn't seem like anything special,
with its fixed cache size - but it's actually pretty powerful at the price.
The new Arecas with 12 ports and above can again have the cache size upgraded.
Also, despite being SATA-II only (due to Marvell HBA chips), the SAS connectors
also contain the SGPIO signals, and the controllers should thus be compatible
with a number of standard SAS hot-swap backplanes (passive = expander-less).
Historically, RAID hardware based on the IOP321 alone would achieve about
100-150 MBps into RAID5, and IOP302/303 based controllers used to provide
about 50 MBps into RAID5 (Adaptec 2120 or LSI MegaRAID 320-1).
These controllers are still on the market today, there are new RoHS versions,
and the prices haven't gone seriously down. Apparently there are regular
customers for whom the apalling performance isn't a problem, and who are
willing to pay a premium for the 100% backwards compatibility.
Industrial process control hardware is all about this.
As for software RAID: it's indeed possible to achieve higher XOR/RS throughput
with a generic x86 CPU - that is, if the Linux native software RAID's boot-up
benchmarks are to be believed
I seem to recall MMX/SSE throughput figures
of around 3 GBps on a Netburst CPU around 3 GHz. Obviously this only makes
sense if your CPU is generally idle, so you can afford to spend some of its horsepower.
An important issue is management comfort. The Areca firmware seems to provide
pretty good comfort, both during array configuration and during critical situations.
It's actually fairly difficult to rip out the wrong drive, if you have a comfortable
management utility for the RAID and a red failure LED flashing at the front
of the respective drive bay.
The Linux RAID can also be dealt with, but it may take more study to get
the drive replacements right. Some commercial software RAID solutions
provide better level of comfort, but hardly any is on par with Areca.
Don't get me wrong, I'm not talking about wizards and other gimmicks
- I prefer simplicity, snappiness, clarity and straight-forward presentation.
Then there's the autonomy of operation - if you have a hardware RAID,
your RAID controller's embedded OS is alive regardless of the state
of your host PC's OS.
Given the current state of compatibility with hot-swap backplanes,
you definitely want a hardware RAID to get the failure LED's to work at all,
and even with a HW RAID, you have to carefully select/integrate your RAID
controller with your hot-swap backplane, to make the LEDs work just right.
As far as video editing is concerned, I believe that whenever you need
to get some transcoding done, you won't have a problem with the disk throughput,
because your data flow will be throttled by the CPU. There are encoding
accelerators, but still. Only at some HD Video or cinema-level resolutions,
while grabbing raw video with (nearly) zero compression, you'll ever exceed
400 MBps. And, in a video editing station, you definitely want to have all the CPU
horsepower available for the video encoding jobs. Get an Areca 1261/1280,
and you'll never be starved of disk IO bandwidth.
Let me finish off with a funny story:
I seem to recall two or three drive replacement accidents involving various
Adaptec AACRAID controllers. Suppose you have a mirror of two drives,
and one of the drives gets out of sync for some silly reason (cabling mess,
power plug pulled out), but is really still healthy. What I did, I attached
the "repelled" drive alone to an AACRAID controller, and removed the
logical array from that drive only, by unconfiguring it in the AACRAID BIOS.
I then attached the now "empty" drive to the RAID controller together
with the drive that has survived, with the idea that I'd rebuild the RAID
from the survivor to the emptied drive. Guess what: the AACRAID
purged the logical array from the survivor drive, right at boot
The apparent logic is, that my delete of the logical array was the
last known operation on the array, and therefore it was replicated
onto the "survivor" drive...
Never had anything like that happen with an Areca controller.
You plug the drive back in and you can forget about it.
Areca seem to maintain a uniform firmware code base across all
the hardware platform that they're using. A new firmware version
is usually available for all the plafroms in sync. Compared to the
competition, this would hint at pretty solid software engineering.
I've never discovered a serious firmware bug in their products
- I've only ever read about bugs fixed in the firmware release notes.
It certainly is silly to use a headline speaking of "RAID scaling of different
RAID levels vs. the number of drives", and then use a particular older
off-the-shelf RAID controller implementation with a pretty deterministic
cap on throughput, characteristic for the particular embedded CPU
Regarding volumes over 2 TB: there are several ways of how to achieve
this, not all of them available in all Windows versions.
Windows 2000 (Server?) can work with multiple <2TB volumes striped together
in software, using the Windows disk management. Generally if your Windows
version can do software striping, it can merge several <2TB disks with a normal
sector size (512B) into a volume of >2^32 blocks. The complete workaround
is that you set up your RAID controller to present several volumes
smaller than 2 TB and stripe them together in software.
Windows 2000 and above can also work with non-standard sector sizes,
namely 2^n multiples of the standard 512B, up to 4 kB per sector.
This is the #1 choice for "volumes over 2TB" with most RAID controllers
out there. Some of them just call this option the "Windows solution
to the 2TB problem". This workaround gives a maximum disk volume of
16 TB (4 kb * 2^32).
And the most progressive way is to use the standard 512B blocks,
but with a greater than 32bit address. On SCSI, this is called LBA64
(64bit LBA address), which is encapsulated in CDB16 SCSI frame format.
This compares to the older SCSI standards of LBA32/CDB12.
(Note that on IDE/ATA there's LBA48.)
As all the PCI-based internal HW RAID controllers are really ported to
the SCSI subsystem in the host PC's OS, and likely even use SCSI
as the transport framing to the controller's private CPU (IOP) "mailbox",
I believe that LBA64+CDB16 is a valid label for this, even with the internal
PCI RAID controllers.
This 64bit address length and CDB16 need to be supported by the host
operating system. AFAIK, this is only true in Windows 2003 Server SP1
(including 32bit) and the 64bit versions of W2K3/XP/Vista (not sure about
Vista 32bit). And of course any recent version of FreeBSD or Linux.
Note that a modern Linux kernel alone is not enough if your distro is out of
date - the user-space utilities (and glibc?) may have a problem too.
Also, as the classic PC BIOS partition table is limited to 2 TB,
so your OS either has to use the volume >2TB raw ("dangerously
dedicated"), or has to support the GPT partition tables.
Support for GPT partition tables generally goes hand in hand
with support for LBA64/CDB16, but don't expect your PC BIOS
to boot from that