facebook rss twitter

Review: The joys of redundancy: XFX's Revo 64

by Steve Kerrison on 20 July 2005, 00:00

Tags: XFX (HKG:1079), Netcell

Quick Link: HEXUS.net/qabkw

Add to My Vault: x

Revo 64 and Friends

The Revo 64 is based on Netcell's Revolution Storage Processing Unit, bringing with it some features that are both appealing and somewhat unusual.

The vast majority of RAID configurations require driver support from the Operating System. When installing to a RAID array, this can introduce lots of fun and games, often requiring the creation of a driver disk from which the Operating System installer can load the drivers. However, Netcell's SPU takes a different approach. Putting it simply, the system sees the RAID controller as an everyday, run of the mill IDE controller. That means any OS with support for generic IDE controllers should, in theory, support the XFX Revo 64 without issue. This is achieved through the 100% hardware RAID implementation of the Revolution SPU. The array is completely managed by the SPU, meaning it can be presented to the rest of the system as a standard IDE device, with no special treatment required.

Next on the list of notable features is the RAID modes supported by this card. You'll commonly find RAID 5 is used to strike a balance between available disk space, speed and data redundancy. A lot of processing power is required to manage a RAID array however, which is why we rarely see it available on consumer boards and when we do, it gobbles up CPU time. Interestingly, you won't find RAID 5 support on the Revo 64. Instead, RAID 3 is used.

The biggest difference between RAID 3 and 5, is that RAID 3 uses one of the array's drives as a parity drive, storing extra data that can be used to recreate data should a drive be lost. With RAID 5, the parity is distributed across all of the drives. The second difference is how the data is broken down to be spread across the drives. With RAID 5, data is broken down into blocks of a certain size, often in the region of 32, 64 or 128KiB. RAID 3 distributes data at the byte-level.

The competition

I'm no stranger to RAID, having run a SATA RAID 5 array for some time now, which presents an opportunity to compare XFX's Revo 64 against something in the same price range, the Promise FastTrack S150 SX4.

Specifications

Here's a breakdown of both cards' features:

XFX Revo 64Promise FastTrack SX4
Processor:Netcell RevolutionPromise XOR engine
Drive Interface:Serial-ATA 3GbpsSerial-ATA 1.5Gbps
Host Interface:PCI 32bit/66MHzPCI 32bit/33MHz
Number of Ports:3 for 3000 series
5 for 5000 series
4
Host Interface:PCI
RAID Levels:JBOD, 0, 1, 3JBOD, 0, 1, 10, 5
Cache:64MiB onboardUpto 256MiB through SDRAM DIMM

Points of Note

The above table highlights most of the differences between the two solutions, although a few things need further explanation. Firstly, while the Revolution SPU is a 100% hardware RAID solution, the Promise XOR engine is not. XOR calculations are used to create the parity used in the likes of RAID 5 and it is that which the Promise chip accelerates. However, the rest of the array management is handled by the system's CPU, which also means the Promise card requires a custom device driver.

Curiously, while the XFX Revo 64 supports RAID 0, the three port card in my possession will only permit RAID 0 mode with two drives. RAID 0 can run with more disks than this, functioning with three or four drives on the Promise controller. Consultation of the Revo 64 manual suggests that the 5 port version of the card will only support even numbers of drives in RAID 0 and three of five disks in RAID 3.

When performing parity calculations while writing data to an array, cache is helpful to keep the flow of data moving and the rest of the system free to perform other tasks. The Revo 64 has 64MiB onboard cache, whereas the FastTrack SX4 has expandable cache memory. There is, however, an SX4-M variant of the card which comes 64MiB of onboard cache.