Our newest protagonist is the FiT 500, a 5 bay external RAID unit that promises high end performance and flexibility. Can the FiT 500 deliver on the promises its proud parent makes?
The FiT 500 is a new external disk storage unit from AXUS Microsystems, a subsidiary of ASUStek. ASUStek might more commonly be recognised as owning the ASUS brand, manufacturer of components and the famous Eee PC. At least this explains the similarity in company name and logo style – rather than a nefarious competitor, the companies are closely related.
In the interests of full disclosure, we will say that AXUS have requested that we here at OzHardware review the FiT 500, and supplied the unit to us. While we are independent of all hardware manufacturers, and attempt to write impartially, it is always possible that some unintended bias creeps into the review; we advise the reader to be aware of this.
The FiT 500 arrived in a surprisingly large, yet sleek black box. Opening the box revealed that the Fit500 is shipped in parts, rather than an assembled unit – but don’t worry, the amount of work to put it all together is pretty minimal, and doesn’t take any longer than a unit delivered fully assembled.
First, install the drives into the caddies and slide the caddies into the main unit. Then, attach the fan to the rear of the unit, where you’ll also find the standard IEC power socket and the USB and SATA interfaces. Plug in the power and use the supplied metal clip to provide a little protection from accidental plug pulls. Finally plug in the eSATA or USB connections (depending on which connection you prefer), and turn the unit on.
When the FiT500 powers up, the LCD on the front of the unit glows quite bright blue, with white text. The drive LEDs do not light until the drive is configured to be part of an array. Both the drive LEDs and the activity LEDs are blue, and the activity LED flashes with drive, rather than array access, giving you a good view of how busy the disks are. And while the junior geek in me loves the look of blue LEDs with the white chassis, the elder geek wants the activity LEDs to be a different colour (perhaps white, or red) to reduce confusion during a quick glance. Nevertheless, this is perhaps the most minor of quibbles.
The FiT500 supports all the common RAID levels – RAID 0, RAID 1, RAID 3, RAID 5 and RAID 10, as well as non-RAID configurations named "Large" and "". No real surprises there – but when connected via USB, the FiT500 will also make multiple RAID sets available. So you can have a two disk RAID 1 set as well as a 3 disk RAID 5 set in the same chassis. Or a pair of RAID 1 sets or even a RAID 5 and a RAID 0 (data and backup, for example).
In testing, and as is fairly normal for a USB 2.0 enclosure, the performance is limited by the USB interface rather than the disks or the disk controller, so there’s little point in showing a dozen graphics, all nearly identical, with transfer rates at 30MBps and latency at 25ms per request.
The RAID configuration can all be handled from the LCD control panel at the top of the unit. The menu structure is fairly simple:
Let’s build us some RAID arrays!
As previously implied, all the performance tests were conducted using the eSATA connection. This provides far greater throughput (MB per second), and lower latency (seconds per request) than does USB, with the downside that the host can access only the first defined array.
With two disks in the array and configured as RAID 0, our basic overview benchmark ATTO shows us:
That’s ... not bad. That's not bad at all! It’s not quite as fast as if the disks are connected to the motherboard SATA connectors, but it’s certainly no slouch at around 90% of the onboard SATA controllers.
ATTO concentrates on the first few MB of the disk, which sits on the outside of the platters, so in a lot of ways the performance data from ATTO is generally “as fast as it gets”. HDTach gives us performance data across the entire volume, as well as isolating the effects of any cache RAM:
Holy cow that’s good. Interestingly you’ll probably notice that performance actually increases over the first 60% of the array to a maximum of nearly 180MBps, then falls away to just under 120MBps. That’s no slouch.
HDTune gives us more data still – showing the difference between sequential and random access:
Ah, consistency. That’s a good sign. We even replicate the sequential performance curve from HDTach, so it looks like the two results are valid.
The random performance is quite interesting. The result of ~50 IOPS is about what we’d expect to see from a single disk (actually, it’s a fraction lower), so we’re really not seeing any advantage from the 2 disk RAID 0 array for random performance.
There’s no online capacity expansion in the FiT500, so changing the 2 disk RAID 0 to a 3 disk RAID 0 requires deleting the old array and creating the new array. Luckily the process takes only a minute or so to complete (so yes, theoretically, you could delete 8TB of data in just a few seconds if you had physical access to the device).
With a three disk RAID 0 array, ATTO shows us:
Interestingly the 3 disk array does not start out faster than the 2 disk array – indeed it does not pull ahead until the 8.0KB transfer test. After that though the 3 disk array accelerates up to 230MBps, where we seem to reach a different bottleneck. The eSATA interface should be good for 300MBps, so we're seeing only about 75% of maximum. Perhaps the 3 disks can only push 75MBps each - it's still a good result.
Let’s see what HDTach has to say about the 3 disk RAID 0 set:
Impressive. 200+MBps across the first 85% of the array. It seems clear that we are reaching a limit of the embedded RAID controller chip at these throughputs - if not, then we'd expect the graph to be higher at the start and decrease over the entire range. Time for HD Tune then, to see the difference between sequential and random access:
An average of 190MBps across the array makes this no slouch. It matches up with HDTach, although at a slightly lower level (perhaps due to different methods of performing IO).
Again, though, the result of ~50 IOPS is about what we’d expect to see from a single disk, so like the 2 disk array, there is no real benefit to random IO. It looks like the extra latency of the embedded RAID controller is too great to achieve high random IO rates.
Onward to a 4 disk array then. Given what we saw with the 2 and 3 disk RAID 0 arrays, we're not likely to see significant performance increases.
With a four disk RAID 0 array, ATTO shows us:
Let’s see what HDTach has to say about the 3 disk RAID 0 set:
HDTach clearly shows the same performance at the start of the array, but now extends all the way to the end. 200MBps sustained no matter where on disk - which means we're now limited by the RAID controller not the disks. We managed 70MBps per disk with 3 disks; yet with 4 disks we manage only 50MBps each.
Should HDTune then, to see the difference between sequential and random access:
Here we see the same sequential performance as with 3 disks, except the performance does not drop off towards the end of the array.
Again, though, the bane of our results is in random IO - despite having data spread across 4 disks, the FiT can manage only the random IO of a single disk. Indeed - performance has perhaps dropped off a percentage point or two, perhaps indicating we are at the limits of either the RAID controller or our measurement methods.
The five disk RAID 0 array - the pinnacle of size from the FiT500E. No other RAID configuration can offer as much disk space as the RAID 0 configuration (10TB using the current maximum 2TB drives). The Large configuration should also provide 10TB, but will not match the performance of the RAID 0 array, as it accesses each disk individually.
With the maximum five disk RAID 0 array, ATTO shows us:
There's very little performance difference between 4 and 5 drives here. In fact - the biggest change between four and five drives is the risk of data loss (with a 2% annual failure rate, the chance of data loss is nearly 10% in any given year, instead of 7.7%).
Let’s see whether HDTach can offer any additional insights on the 5 disk RAID 0 set:
Yep, the same consistent 200MBps across the array, with no significant dips, valleys or other major inconsistencies to be seen - all further confirmation that 200MBps is as hard as this RAID enclosure can go. HDTune then, to see the difference between sequential and random access:
It's interesting to see that HDTune experiences some short interruptions to transfers, which were not visible on the HDTach graph.
Unfortunately, if you need this RAID array to support high speed random access, even the 5 disk array cannot provide the increases in random IO for which hardware RAID controllers are generally revered.
Let's try something a little different. Instead of searching for performance, let's see what a properly redundant array is capable of.
With a two disk RAID 1 array, ATTO shows us:
We see here the result of having to write everything twice - a 10% "write penalty" on the array. Instead of achieving 105MBps as we do for reads, we see a maximum of 95MBps for writes. Let’s see what HDTach has to say about the mirror set:
Pretty good results for a mirror set. Unlike the RAID 0 set, we see a traditional performance curve, starting high and gradually worsening (as the heads move towards the centre of the disk). We don't see the same read performance as the RAID 0 set though, which indicates that the embedded RAID controller is not capable of using both disks simultaneously to satisfy read requests. Perhaps what we see is more a symptom of a lack of Command Queuing (NCQ) which significantly improves performance in multiple-disk arrays. On to HDTune then, to see the difference between sequential and random access:
An average of 85MBps across the array is quite reasonable and matches reasonably closely the performance of a single disk. We match the sequential performance curve from HDTach and also shows the same improvement from the very start of the disk towards the middle.
Random IO still shows no change - perhaps another indication that the FiT cannot effectively use more than 1 disk at once. Don't confuse the scale on this graph with that of the RAID 0 graph - the RAID 0 graph has an outlier - a single 4KB IO that required 80ms to complete and thus changed the vertical scale. The random IO performance is comparable, between the two arrays.
On a high end RAID controller, RAID 10 is, generally speaking, the highest performing RAID level. The high end controller uses all 4 disks (or 6, 8 etc) to satisfy read requests; while writes only ever require 2 disk accesses (writes to each part of whichever mirror is affected). High-performance mail servers, database servers, virtualisation servers and rendering servers all use RAID 10 to help ensure that disk performance is as high as possible.
With a four disk RAID 10 array, ATTO shows us:
Well, those results seem to be roughly in line with the 2 disk RAID 0 set for both read and write. Not too bad a result but watching the LEDs confirms that the RAID controller really does use only 1 disk in each mirror for read requests, severely limiting its performance (specifically disks 0 and 2 are used). Let’s see what HDTach has to say about the 4 disk RAID 10 set:
Again the performance is in line with the 2 disk RAID 0 set, which is to be expected. HDTunePro shows the now familiar performance arch rather than the perpetually decreasing curve; it's consistent, if not expected:
Well no drama here, performance is nigh on identical to the 2 disk RAID 0 set. The random IO profile is similar:
We move on now to RAID levels that provide resiliency balanced with loss of disk space - protection against single disk failures using parity rather than a mirrored copy. RAID 3 and RAID 5 are closely related; both use an approach where 1 disk's worth of data is reserved for parity. RAID 3 stores all parity on one disk; RAID 5 spreads it equally across all disks. Both RAID 3 and RAID 5 require a minimum of 3 disks, and are often most efficient when there are 2n+1 disks in the array (for example 3, 5, 9 or 17).
With a three disk RAID 3 array, ATTO shows us some very promising results:
Indeed, this is pretty much line ball with the 2 disk RAID 0 set (which is what we should expect - the 3 disk RAID 3 set effectively has two data disks in RAID 0 and a third disk for the parity information). Let’s see what HDTach has to say about the 3 disk RAID 0 set:
This is very promising. 160+MBps across the first 70% of the array is plenty of performance, and close enough to the limits we've previously observed that we should be able to hit those limits again. HDTune then, to see the difference between sequential and random access:
We match the sequential performance curve from HDTach, and we average 150MBps across the array. The minimum 106MBps is more than enough to stream HDTV, and RAID 3 is often considered better than RAID 5 for such purposes.
The most we can say is that random IO is no worse than any of the other modes. But it's still no better. At this stage I really have no hope that it would ever improve.
A four disk RAID 3 array can be problematic. Writing a large amount of data (more than a stripe) may require that the blocks of data, which are generally sized as a power of 2, be broken into an odd number of equal chunks so that it can be stored, and the parity information calculated.
So what can ATTO show us about a four disk RAID 3 array:
Performance is pretty good, on par with the 3 disk RAID 0 array. There doesn't appear to be any significant issue for this RAID controller in dealing with large chunks of data; an excellent outcome. Let’s see what HDTach has to say about the 4 disk RAID 3 set:
Impressive. 200+MBps sustained across the first 85% of the array, just like the 3 disk RAID 0 array - they're indistinguisable it seems. It also seems clear that the limit of the embedded RAID controller chip is more about throughput than parity calculations. HDTune then, to see the difference between sequential and random access:
There are a couple of minor dips in performance, but nothing particularly troubling. We match the sequential performance curve from HDTach.
Random performance of the RAID 3 set. There is nothing insightful to say here.
Finally a five disk RAID 3 array - an excellent balance between cost and hopefully, performance. ATTO shows us:
Excellent. We've managed to hit the throughput limit of the embedded RAID controller while still calculating and storing parity across the array. Let’s see what HDTach has to say about the array:
200+MBps across the entire array. Again we have reached the limits of the embedded RAID controller chip. HDTune then, to see the difference between sequential and random access:
Another match to the sequential performance curve from HDTach.
With the good (sequential IO) comes the bad (random IO).
We're finally in the home straight - we've tested RAID 0, RAID 1, RAID 10 and RAID 3. There's only RAID 5 left. Like RAID 3, one disk's worth of space is reserved for recovering from a failure, but where RAID 3 stores the parity information on one disk, RAID 5 distributes the parity across all the disks. Again, 3, 5 and 9 disks are possible sweet spot configurations, and we're looking out for any write penalties caused by parity storage and calculation.
With a three disk RAID 5 array, ATTO shows us:
Thankfully, the 3 disk RAID 5 set shows performance akin to the 2 disk RAID 0 set. There are scenarios where it could be faster; but there are also scenarios where it should be a lot slower. Let’s see what HDTach has to say about the 3 disk RAID 5 set:
There are a couple of unexpected dips in performance, but nothing particularly worrying. HDTune then, to see the difference between sequential and random access:
If it weren't for the tag in the top left, identifying this as a RAID 5 set, you'd be forgiven for thinking this was a RAID 3 set or the 2 disk RAID 0 set.
There is no hope for random IO.
With a four disk RAID 5 array, ATTO shows us:
No sign of problems with 4 disks in the RAID 5 set, and surprisingly, write performance is consistently better than read performance for larger requests. Let’s see what HDTach has to say about the 4 disk RAID 5 set:
Performance is much more predictable - no peaks or troughs and performance is still right up there. HDTune then, to see the difference between sequential and random access:
Again, there are a couple of small inconsistencies in the data. Random IO results:
Unchanged.
Our final configuration - a five disk RAID 5 array. ATTO shows us:
Let’s see what HDTach has to say about the 3 disk RAID 0 set:
One small blip, but otherwise we see 200+MBps across the array. No matter what we do, we max out throughput before anything else. HDTune then, to see the difference between sequential and random access:
It almost couldn't be flatter. No matter where our data, performance is the same. We match the sequential performance curve from HDTach.
Ah, random IO. The Achilles Heel of the FiT500E.
There's a huge number of graphics and charts in the preceding pages of this review. To make it easier to see how performance changes with more disks, we've re-tabulated the data.
RAID 0 comparison:
RAID 1 / 10 comparison:
RAID 3 comparison:
RAID 5 comparison:
Comparison of 2 data disk configurations:
Comparison of 3 data disk configurations:
Comparison of 4 data disk configurations:
It would seem that it's time for us to sum up the results of our testing.
If it weren't for the poor performance in random IO tests, this would be a huge slam dunk win to the FiT 500E. 200MB per second for sequential or large transfers, no write penalties for RAID 3 and RAID 5? That's a storage nut's dream.
But the woeful random IO performance limits the use of the FiT500E to scenarios where large amounts of large files need to be stored. Storing lots of small files will leave you at the bottom of the performance curve, as the RAID processor spends more time decoding where the data is than retrieving or storing it.
To improve our mark, the FiT500E needs new firmware that handles random IO better for all RAID levels. It should take advantage of NCQ to the disk drives, and potentially "scatter-gather" where requests are re-ordered so that they can be serviced in a smarter way.
Scatter-gather is similar to the way an elevator works. If you need to stop at floors 15, 1, and 22, and the lift is on the ground floor, you don't travel to the floors in this order - you re-order them to save time. This also saves wear and tear on the elevator. A smart RAID controller can optimise random IO requests using a similar approach.
Highly recommended for:
- Backing up your computer
- Movie and TV files (home movies or recording on your Home Theatre PC)
- Music files and CDs
Overall we give the FiT500E a mark of 8 out of 10.
