A year ago Seagate rolled out its revolutionary hard disk drive, Barracuda ATA IV, the first 40GB-per-platter drive to have 7,200rpm spindle rotation speed. One of the innovations Seagate brought to the IDE HDD market was the noiseless hydro motor, which contributed to the attractiveness of Seagate drives. Barracuda ATA IV received numerous awards from various test labs, journals, web sites and so on. The awards were well deserved as the drive managed to combine high reliability, noiseless work and reasonable price.
But in a while competitor companies announced 40GB-platter HDDs, too, and Barracuda ATA IV left the front pages and headlines.
In another little while, the Internet community was ruffled by rumors like "Barracuda ATA IV wouldn't work in RAID0!"
At first, I was greatly set aback. I couldn't grasp the idea of a HDD that was unable to work in RAID0… All my previous experience told me it couldn't be true. But the number of "victims" was growing and they voiced their complaints louder. At last my nerves gave out and I decided to find out myself where the truth is.
Testbed and Methods
Six Barracuda ATA IV drives of 40GB capacity and three versions of firmware (3.10, 3.19 and 3.75) took part in our tests. As you can easily guess, this made three pairs of drives with the same firmware.
For our tests we also used Promise FastTRAK100 TX2 controller, which is very popular and can be often seen as integrated onto mainboards.
The benchmarking was carried out in three steps. First, three HDDs with different firmware were tested with FastTRAK100 TX2 in SPAN mode, i.e. as single drives. Then dual-drive RAID0 arrays were tested. Stripe block size in the arrays was set to 64KB. For WinBench the arrays were formatted for FAT32 and NTFS as single logical drive with the default cluster.
The tests were run four times each, the average result was then taken for the diagrams. The HDDs didn't cool down between the tests.
We used the following benchmarking software:
- WinBench99 1.2
- IOMeter 1999.10.20
To compare the controller performance with RAID arrays of different types we used new IOMeter patterns suggested by StorageReview.
These patterns are intended for testing the performance of disk subsystem under workload typical of file- and web-servers.
Taking into account the analysis of the disk subsystem workload in ordinary Windows applications conducted by StorageReview, our colleague, Sergey Romanov aka GReY, created a pattern for IOMeter (the pattern is based on the average IPEAK stats for Office, Hi-End and Bootup modes provided by StorageReview):
We'll use the pattern to find out if the HDDs and RAID controllers are attractive or not for an ordinary Windows user.
We also checked the controller performance in different RAID arrays when the read-to-write ratio changed. In the pattern we created, 100% random 8KB data blocks were used and the read-to-write ratio was changing from 100/0 to 0/100 with -10/+10 step.
Well, and the last thing checked was the controller's ability to work with read and write Sequential requests of the changing size in different types of RAID arrays.
Our test system was configured as follows:
- Intel Pentium III (Coppermine) 600MHz CPU;
- ASUS P3B-F mainboard;
- 2 x 128MB PC100 ECC SDRAM by Hyundai;
- IBM DPTA 372050 HDD;
- Matrox Millennium 4MB graphics card;
- Promise FastTRAK100 TX2 BIOS v2.00.0.24/Drivers v2.00.0.25;
- Windows 2000 Pro SP2.
As you may remember from our IDE HDDs review, Barracuda ATA IV performed quite well in Winbench99. So it's interesting to see how the firmware version affects Barracuda ATA IV performance in Winbench99 and what performance growth we will get in a RAID0 array of several Barracuda ATA IV drives.
If we compare the performance of the single HDD and RAID0 array, the latter will turn out faster when working with larger files (e.g. in SoundForge), no matter what firmware the drives have. When working with smaller files, the RAID0 array doesn't have any advantage over the single hard drive.
The overall picture can be evaluated in integral tests. HDD performance is slightly affected by the firmware. In case of a single HDD, the best performance belongs to the one with 3.10 firmware version while in case of RAID0 arrays the HDDs with 3.19 firmware version were the fastest.
Results in NTFS are slightly different:
As we see, 3.19 firmware proved fastest for RAID0. Among single drives the best results were shown by HDDs with 3.19 and 3.75 versions.
On the whole, it should be acknowledged that building RAID0 array of Barracuda ATA IV HDDs is not the most efficient solution for WinBench.
In the end of this part of our review I'd like to offer you the linear read graphs for single Barracuda ATA IV drives (with different firmware versions) and RAID0 arrays.
Intel IOMeter: Sequential Read/Write
We'll begin low-level benchmarks of Barracuda ATA IV and RAID0 arrays built of them with sequential read tests. The point of this test implies that the HDD (array) receives requests for reading data blocks with increasingly bigger address. The data block size requested by a command is changing from 512Byte to 1MB. The request queue depth is set to 4.
Now let's compare the performance of single HDDs:
It turns out that the performance of Barracuda ATA IV depends greatly on the firmware version when dealing with read requests of data blocks of various size! The drive with the "oldest" firmware of all processed 8KB blocks twice as slowly as the HDD with 3.19 firmware! The newest firmware, 3.19, unexpectedly showed quite average results.
But in RAID0 the 3.19 firmware pair of HDDs is doing best of all!
Note that there's no performance growth comparing to single HDDs when the arrays work with small blocks (up to 1KB). But when the size of the requested block reaches 64KB, all arrays "turn to the right mode". Size matters, doesn't it?
Let's see what we have with writes here:
HDDs with different firmware have about the same sequential write speed. We don't miss out the fact, though, that the drive with 3.10 firmware showed the best results and the 3.19 one - the worst.
RAID arrays performance confirms that firmware 3.10 copes best with writes. The array of HDDs with 3.75 firmware also looks good, but only with the blocks over16KB. The array with 3.19 firmware was the slowest in this mode.
So, synthetic tests showed that it's quite possible to double reading speed in an array of two Barracuda ATA IV disk drives. But to make it happen two conditions should be fulfilled: big requests (FAT32 with 32KB cluster?) and highly intensive requests stream.
As I finished the previous sentence, I thought that the statement about requests intensity needs proving.
The next two diagrams show the dependence of the data transfer rate to/from the RAID0 array of the data pack size in case of five workloads (1, 4, 16, 64, 256 requests).
We see that the request queue depth affects greatly the data-transfer rate when reading. While at linear workload (1 outcoming request) RAID array speed hardly exceeds 60MB/sec., it reaches maximum (about 80MB/sec.) with queue equal to 4. On further request queue depth increase, we see performance growth for small data blocks, but the transfer rate doesn't get over 80MB/sec anyway.
The data-transfer rate depends on the request queue depth when processing writes as well. It shows less strikingly than in case of reads, but…
Note how the speed depends on the block size at queue=1. See the graph making a sharp curve when the block size is 128KB? After the block becomes bigger than 64KB (that's the size of the stripe block), it gets divided into "sub-requests" 64KB each (the maximum data block, which can be addressed in ATA/100). These "sub-requests" are transferred to the HDD. The larger the original block, the more "sub-requests" will be created by the controller driver. Accordingly, every HDD has longer request queue and doesn't stay idle.
So, we've found out that Seagate Barracuda ATA IV can use up its entire performance potential in RAID0. But there're two conditions: large size of the requested block (>64KB) or high intensity of smaller requests.
Unfortunately, it's hard to fulfill both conditions when working with ordinary Windows applications … Accordingly, the performance of a RAID0 array made of Barracuda ATA IV drives is rather low in case of streaming requests.
Intel IOMeter: DataBase
This benchmark will show us the way Barracuda ATA IV and arrays made of them cope with deferred write.
The results of the DataBase pattern are provided in the table below:
To visualize the results we made a diagram showing how the performance of single disk drives and RAID0 arrays of two drives depends on the share of write operations.
Well, everything is quite logical. The longer is the request queue, the more chances the controller has to load both HDDs in the array equally with work.
It turned out that Barracuda ATA IV HDDs in RAID0 array cope quite well with this work (random read and write requests). You can clearly see that RAID0 arrays of Barracuda ATA IV and supporting any firmware version were performing faster than single drives under any workloads higher than the linear one (queue=1). ;)
But there's evident difference between the hard disk drives supporting various firmware versions and RAID0 arrays of these drives. HDDs with 3.19 firmware respond better to bigger share of writes while those with 3.75 firmware, on the contrary, fall behind a little.
Intel IOMeter: WorkStation
First, as usual, all results listed in a table:
And now the diagram, of course:
The WorkStation pattern emulates work in typical Windows applications in NTFS5. Here RAID0 of two Barracuda ATA IV devices outperforms the single drive under any workload.
The performance of single drives with different firmware versions is vanishingly small, but in RAID0 the firmware affects it, though slightly. However, as the speed difference is only 1-2%, we should regard all the versions as equally successful in WorkStation pattern. Drives with 3.75 firmware are a little behind, though.
Intel IOMeter: FileServer & WebServer
All of you, guys, who bought Barracuda ATA IV for server use may enjoy the results RAID0 arrays made of these drives show in the above listed patterns. :)
As you see, the RAID0 array provides a nice performance growth over that of a single drive. Of course, the results might be better, but at least there are no such problems as with sequential requests.
As you remember, one of the purposes FC-Test was created for was benchmarking HDD performance in tasks "close to the real ones". :)
In the recent roundup of 13 HDDs FC-Test revealed some interesting features of already well-known drives. That's why I was curious to use FC-Test to test some RAID controllers as well.
For the test to bear some practical value, we'll compare the performance of three RAID0 arrays with 80GB storage capacity with the performance of a single HDD of the same capacity.
Those who are not yet familiar with FC-Test and its methodology can learn more about it in this article; all the others, I assume, will easily understand what we're going to talk about.
The tests were run in NTFS (the results in FAT32 turned out to be much the same) in the following patterns:
|Patterns for FC-Test|
|Total files||Size, MB|
This set of tests may be a little excessive. The ISO pattern alone could be used to check the performance of the Barracuda ATA IV based RAID0 array. But we're also trying to compare drives with different firmware versions with one another, so…
The diagrams show the speed (in MB/sec.) of RAID0 arrays and single Seagate Barracuda ATA IV (80GB, 3.19 firmware) in four testing modes.
We can drive two regularities from the diagrams:
- During writes and file copy operations RAID0 array made of drives with any firmware version is always faster than a single drive.
- During reads RAID0 array made of drives with any firmware version is always slower (sometimes significantly!) than a single drive.
The performance difference between RAID0 arrays built of HDDs with different firmware is evident, but it is quite hard to track any tendency here. :)
Well, there is one, though. RAID0 of HDDs with 3.75 firmware reads a set of files better than the rivals. But anyway it's slower than the single drive performing the same operations.
So why did the dual-disk array turn out to be slower than a single drive at reading, that is, where the RAID0 array should have the maximum advantage over a single drive?
We explored the disk subsystem workload with Performance Monitor and discovered that during reading the maximum request queue depth was only 4 requests while the average value was even less - 1.4 requests! We all remember the way RAID0 of Barracuda ATA IV drives reads data under low workloads and that's exactly what we have in our case!
The benchmarks we've carried out allow making the following conclusions:
- Barracuda ATA IV HDDs do "work" in RAID0 configurations, no matter what those "well informed sources" say.
- Barracuda ATA IV HDDs cope quite well with "server" patterns.
- Barracuda ATA IV in RAID0 read and write small data blocks slowly when the workload is low (small request queue depth).
- All the firmware versions we tested possess the above-mentioned drawback.
Well, can the shortcomings of Barracuda ATA IV be fixed while keeping the advantages? I guess it's possible. In my opinion, the problem of somewhat poor performance of Barracuda ATA IV in RAID0 lies in insufficient optimization of read ahead algorithms. The problem can be solved and I guess Seagate is working on it. Judging by the results shown by different firmware versions, Seagate software developers are on the way to the solution to this problem. It's absolutely undoubted as HDDs with higher firmware version outperform drives with "older" firmware at linear reads.
To Upgrade or Not - That Is the Question…
There're several firmware upgrades for Barracuda ATA IV roaming Internet nowadays and many users have already succumbed the temptation to increase the universal entropy…
I hope this article would help to cool down the minds of those who want to risk their HDD and data for the sake of a slight performance gain.
As you could see the three tested firmware versions didn't cure the problems of Barracuda ATA IV. So we'd better wait for the "right" firmware and only then… :)