by Alexander Yuriev
08/27/2004 | 07:43 AM
We have taken a short pause in our tests of multi-channel SATA RAID controllers, but only to return to this subject once again now. This review is about a four-channel controller from Silicon Image, officially called Sil 3114 SATALink 4-Port PCI Host Controller.
The manufacturer’s website says the optimal price to performance ratio was the priority in the development of that solution. This chip has long been around – you may have met it on mainboards or external PCI controllers. So, it seems like it’s all right with the price factor. Let’s now evaluate the performance.
The Sil 3114 host-controller is based on the namesake chip from Silicon Image. It supports up to four SerialATA-150 hard disk drives as well as any SATA 1.0 compatibles. The list of supported RAID types includes JBOD, RAID0, RAID1 and RAID10. Thanks to the controller’s ability to work in a 32-bit/66MHz PCI slot, its maximum theoretical bandwidth is 266MB/s. The controller has 128KB of memory to store the BIOS; the memory can be expanded by adding in up to 4MB of external flash memory.
The following table lists the characteristics of the device:
Silicon Image Sil 3114 SATALink 4-Port Controller Features | |
RAID | JBOD, 0, 1 and 10 |
SerialATA | 4 SerialaATA 150. Compatible with SATA 1.0 standard |
PCI | 32bit 33/66MHz PCI. Compatible with PCI 2.3 standard |
Flash | Supports up to 4MB of external memory |
The small-size SATALink Sil 3114 chip (it is to the right of the center in the snapshot above) allows designing controllers within an extensive form-factor range. This time the host-controller is compact, but its fastening bracket can only be used in standard system cases, so we can’t call it a low-profile device. To the right of the Sil 3114 chip, there’s a socket for external flash memory. Considering the amount of free space on the PCB, they could have made the controller even smaller, but the minimal length is limited by the size of the PCI slot.
Testbed configuration:
We tested the controller using WinBench 99 2.0 and IOMeter 2003.02.15.
We created one partition for the total storage capacity in WinBench 99. We carried out each of the WinBench tests seven times and chalked up the best result.
We used File Server and Web Server patterns in our IOMeter tests.
These patterns are intended for measuring the performance of the disk subsystem under a workload typical for file and Web servers.
We also use the Workstation pattern, created by Sergey Romanov (a.k.a. GReY). It is based on the statistical data about the disk subsystem workload as given in the StorageReview Testbed 3 description. The statistical data for the NTFS5 file system are gathered in three operational modes: Office, Hi-End and Boot-up.
This pattern shows how well the controller performs in a typical Windows environment.
Lastly, we checked out the controller’s ability to process sequential read/write requests of variable size and its performance in the Database pattern, which loads the disk subsystem with SQL-like requests.
Our controller had the BIOS version 5033 and we used the driver version 1.0.0.3. For monitoring and synchronizing our RAID arrays we used the 3DM Disk Management utility. The controller was installed into a 133MHz PCI-X slot (although the controller itself only supports 66MHz PCI).
WD360GD (Raptor) hard disk drives were installed into the rails of the SC5200 system case and fastened at the bottom.
We enabled lazy writing for the disks of the arrays. We ran all the tests with 128KB of the BIOS memory.
We will start out by examining the controller’s processing mixed request streams.
So we are sending a mixed stream of requests for reading and writing random-address 8KB data blocks. By changing the ratio of reads to writes we can estimate how good the controller’s driver is at sorting such requests out.
The results of the controller are tabled below:
The diagrams below show the dependence of the data-transfer rate on the percent of write operations in the request stream for queues of 1, 16 and 256 requests.
Under the linear workload, in the random read mode, all the arrays deliver a similar performance. Their speeds begin to differ when there are more write requests to be performed – the drives’ enabled lazy writing and the array type influence the results.
The speed of the RAID0 array depends on the number of the drives in it, but the gap between RAID0 arrays made of different number of drives is only wide at high write percentages.
The graph of the RAID10 array in fact coincides with that of the two-disk RAID0: the former is only slower than the latter in the random write mode (100% writes).
Curiously enough, the RAID1 array falls behind the single drive at any writes percentages. The more writes there are in the queue, the wider the gap between these two arrays is.
Under a higher load, the RAID0 displays good speed scalability according to the number of disks per array. The three-disk RAID0 scales up somewhat worse that the others, though.
The graph of the RAID10 repeats the one of the two-disk RAID0, like under the linear load. However, there is a difference at 90% of writes and the RAID10 starts slowing down in the random write mode. The graph of the RAID1 has the same shape as under the linear load.
This behavior of mirrored arrays suggests that the current driver/BIOS combo of the Sil 3114 controller does not optimize read requests by alternating them to both disks of the mirror couple. The mirror algorithm doesn’t affect the speed with the RAID10 array, while the controller is definitely slowing down when writing on a RAID1 array.
The load of 256 requests doesn’t influence the rankings at all. The RAID0 arrays are again well-scalable. The RAID10 is identical to the two-disk RAID0, save for the random write mode, while the RAID1 is behind the single drive in all the modes.
The array receives a stream of read/write requests with a request queue depth of 4. Every minute the size of the data block changes, so we can see the dependence of the linear read/write speed on the size of the data block. The sequential read results are listed in the following table:
Here’s a graph that shows the dependence of the controller’s read speed on the data block size:
The arrays reach their maximum speeds at different data block sizes – when the controller can split a big request into several small ones for the HDDs of the array to process these requests in parallel.
Note also that the maximum speed of the four-disk RAID0 is as high as 215MB/s with the Sil 3114 controller – that’s about exactly four times the maximum speed of the single drive. Excellent scalability!
It’s not all that good with mirrored arrays. As you know, some manufacturers use alternation of read requests between the disks of a mirror couple, even at sequential reading. Thus, a RAID1 array becomes more like a RAID0 and the read speed may double, at least theoretically. But the results of our tests suggest that the Sil 3114 doesn’t use such an algorithm. The read speed of the RAID1 is nearly always the same as of the single drive, and the speed of the RAID10 coincides with the speed of the two-disk RAID0.
Sequential writing comes next:
This graph shows the dependence of the controller’s write speed on the data block size:
Again, the arrays reach their maximum speeds at different moments. However, the scalability of RAID0 arrays can only be seen with two- and three-disk configurations. The four-disk RAID0 breaks the rule, reaching only 193MB/s. That’s good in itself, but we had hoped for something better :).
There are no read requests here, and the speed of the RAID10 is far below the speed of the two-disk RAID0 at big requests. The speeds of the RAID1 and the JBOD coincide. That is, the mirror algorithm slows down the execution of write requests only in the “complex” RAID10 array at sequential writing.
Now, let’s turn to patterns that simulate real-life working environments.
The first pattern imitates the typical load on the disk subsystem of a file server:
The graphs show the correlation between the array speeds and the request queue depth:
The RAID0 arrays are well-scalable in the quantity of disks per array, even at small request queue depths. The read speed of the RAID1 array always coincides with the speed of the single drive, while the speed of the RAID10 with that of the two-disk RAID0. Considering that the File Server pattern has only 20% of write requests, we can suppose that the Sil 3114 controller never uses optimization techniques when reading from a mirror.
We calculate the performance rating for each array by averaging the controller’s speed under each workload:
As you see, there are no surprises here, too. The RAID0 arrays line up according to the number of drives per array. The mirrored arrays – RAID1 and RAID10 – are slightly slower than the single drive and the two-disk RAID0, respectively.
Now, we run the Web Server pattern, which has no write requests at all.
The RAID0 arrays boast good speed scalability depending on the number of disks per array. The speed of the RAID1 array always coincides with that of the JBOD, while the RAID10 is as fast as the two-disk RAID0. Considering that the Web Server pattern with its 100% of writes is ideal for mirrored arrays to show their advantages in, we are now absolutely certain that the Sil 3114 doesn’t optimize reading from mirrors.
We calculate the performance ratings of the arrays in the same way as in the File Server pattern:
The arrays took the same positions in the table as in the File Server pattern. Of course, the RAID10 is higher-performing here than the two-disk RAID0, but the difference is negligible, like in the previous pattern.
This pattern simulates the user’s working in various applications in the NTFS5 files system.
The following diagram shows the dependence of the speeds of the arrays on the request queue depth:
The RAID0 arrays are scalable only at request queue depths of 4 and more. The speed of the three-disk RAID0 at request queue depth = 4 is somewhat higher than extrapolation from the other points of the graph would produce.
The mirrored arrays exactly repeat the results of the arrays the mirrors are built from. The only exception is the RAID1 at queue = 4 when it suffers a strange performance hit.
We calculate the performance rating for the Workstation pattern by the following formula:
Performance Rating = Total I/O (queue=1)/1 + Total I/O (queue=2)/2 + Total I/O (queue=4)/4 + Total I/O (queue=8)/8 + Total I/O (queue=16)/16 + Total I/O (queue=32)/32.
Even the high percentage of writes brings no changes into the ranks compared to File Server and Web Server patterns.
This benchmarking suite helps to evaluate the disk subsystem performance in desktop applications.
We will compare the speeds of the arrays in two subtests: Business Disk Winmark and High-End Disk Winmark.
As might have been expected, the RAID0 arrays of two, three and four disks are the fastest. The RAID10 is close in performance to the two-disk RAID0. There was also competition between the RAID1 array and the single drive: the JBOD is faster with Write Through caching, but slower with Write Back caching.
Now we switch to the FAT32 file system:
The speeds are overall faster in FAT32 than in NTFS, and we can also notice that the RAID1 is slower than the JBOD here.
Since the data-transfer rates are the same in NTFS and FAT32, we only publish one diagram for both file systems:
Here are the data-transfer graphs for each of the arrays:
The Sil 3114 controller delivers a nice performance, but only with RAID0 arrays. Mirrored arrays don’t provide any speed bonuses – you should only use them to ensure the security of your data. You may remember from our reviews of dual-channel SATA controllers that the reference BIOS/driver pack from Silicon Image doesn’t have any optimizations for mirrored arrays, but focuses on increasing the speed of RAID0 arrays. As a result, the Sil 3114 can be recommended to people who need an inexpensive controller to give a speed boost to the disk subsystem of their computer.
Currently, you can download drivers for Windows 98 SE, Me, NT, 2000 and XP as well as for 64-bit Windows and Novell Netware from the manufacturer’s Web site (Windows 95 is not supported). If you are a Linux user, you can only try the beta version of the driver.