by Alexey Volkov , Nikita Nikolaichev
06/03/2005 | 02:43 PM
We’re going to check the performance of the Promise FastTrak TX4200 controller in this review. The manufacturer positions it as an inexpensive but high-performance solution.
<%BANNER[article]%>The Promise TX4200 supports up to four hard disk drives with the Serial ATA interface and allows uniting them into arrays of JBOD, RAID0, RAID1 and RAID10 types. Like the earlier reviewed SiI3124 controller, the Promise TX4200 supports both ATA Tagged Command Queuing (TCQ) and Native Command Queuing (NCQ). That is, the controller is compatible with the Serial ATA II extensions to SATA 1.0.
The potentially weak spot of the controller may be its interface. The PCI32/66MHz interface may prove insufficient for using modern hard drives at their full speed. But on the other hand, it ensures compatibility with a mass of computers whose disk subsystem needs more speed/capacity/reliability (underline what’s important for you)…
A special feature of this review is our investigation of the practical gain from TCQ technology. The software of the Promise controller allows enabling or disabling TCQ and NCQ, so we could run two cycles of tests and get the numbers for every array type with TCQ on and off.
Note that you can turn TCQ/NCQ on or off only for all the drives attached to the controller rather than just for some of them, so we couldn’t check out some even more interesting modes. But there’s good in it – the review would take half a year more to write then.
So, that’s what the Promise FastTrak TX4200 controller looks like:
The controller’s PCB has a low profile, but it comes with a bracket for full-size system cases by default. The low-profile bracket is included into the retail version of the controller.
You can see a few connectors to the left of the flash memory chip. The controller can output the operational mode of the disks to these connectors or monitor the temperatures of the drives and the speeds of the fans in the racks if working with the SuperSwap 1100/4100 hot-swap racks.
Four SATA connectors can be found on the right, next to the PDC40519 chip.
Testbed configuration:
We used the following benchmarking software:
We used Sequential Read, Sequential Write, Database, Workstation, File Server and Web Server patterns for the IOMeter tests. You can refer to our previous reviews for details about the patterns.
We created two logical partitions, 32GB each, on the array for FC-Test.
We controlled the TCQ mode by means of the Promise Array Management utility. Deferred writing was always permitted for the drives.
The Database pattern comes first. We use it to check the speed of processing a stream of requests to read and write 8KB data blocks with a random address. By changing the ratio of reads to writes, we can see how well the read/write requests are sorted out.
Here are the numbers for the single drive:
For better readability, we estimate the efficiency of TCQ as the ratio of the array’s results with enabled TCQ to the results with disabled TCQ. Thus, if the ratio is above 1, TCQ is rewarding. And vice versa…
There’s a discernable pattern here. Enabled TCQ reduced the array’s performance at small loads and at high percentages of read operations. It must be the controller’s driver’s blame since we can’t explain the 15% performance hit by anything else. Meanwhile, the controller experiences a 35% performance boost with Random Read requests at the maximum load!
We built graphs for three loads (1, 16 and 256 requests):
As you can see, TCQ affects the performance of the array differently. For example, the biggest speed bonus from enabled TCQ is observed at the maximum load, and mostly with “purely” read or write requests. There’s almost no speed growth with mixed requests.
Curiously enough, the speed of the array in the Random Write mode is the same for loads of 1 and 16 requests in both TCQ On and TCQ Off modes.
Let’s see what we have with a two-disk RAID0 array.
Enabled TCQ increases the speed of read operations, but only at high loads.
The array’s speed bottoms out in the mixed modes at the load of 1 request if we enable TCQ.
Next we build a RAID1 array, i.e. a “mirror”.
Alas, the speed of this array may degenerate, too, with enabled TCQ. And the number of red-colored cells seems to reach a maximum. You can observe a speed gain at read requests only.
We might have supposed that we would have a smaller “average” load on each disk when there are more disks in the array because the load on the array is evenly distributed among all of its drives. And accordingly, we would have worse results with enabled TCQ since the range of “inconvenient” loads becomes wider. That’s true – we do see the results worsening at max loads, but the speed loss at small loads becomes smaller! It seems like the reduction of the load rate helps the drives to do their job better…
Now, let’s examine the performance of the four-disk RAID0.
The RAID0 seems to react to enabled TCQ in the same manner no matter how many drives it is comprised of: it gets a nice read speed bonus at long request queue depths, but becomes worse than with disabled TCQ at writing.
RAID10 is the most complex array type for the controller.
The controller seems to have found this mode too difficult: the table of efficiency is almost all red. We don’t want to make any hasty conclusions, though. This is just our first pattern, and many are yet waiting their turn.
IOMeter is sending a stream of read/write requests to the array with request queue depth = 4. Every minute the size of the data block changes, so we can see the dependence of the linear read/write speed on the data block size as the result.
Click here to view the complete table of results obtained in IOMeter: Sequential Read.
We build a table of efficiency, like in the previous pattern:
First we construct graphs for the RAID0s and then for the rest of the arrays.
TCQ brings no evident gains to the RAID0 arrays, while the more complex RAID10 array slows down considerably in the TCQ mode. The controller’s drivers evidently need additional improvement…
And what about writing?
Click here to view the complete table of results obtained in IOMeter: Sequential Write.
And the graphs:
There are clearly problems with writing to the arrays consisting of many disks. The scalability of the three-disk array worsens (the write speed of the three-disk array is not 1.5 times higher than that of the two-disk array), and then the controller fails utterly with the four-disk array. The write speed of this array is low irrespective of the operational mode of the drives.
The write speed of the complex RAID1 and RAID10 arrays is fluctuating around the speed of the single drive. Well, it’s always good to have some stability. :)
Next, we’re going to examine the controller’s performance in patterns that emulate the disk subsystem of a server.
We compare the arrays by averaging their performance at the four loads.
This time TCQ positively affects the performance of the arrays in the pattern. The average speed has grown up everywhere, which is especially conspicuous with the RAID0 arrays. As you understand, the minor loss at small loads is compensated by the bigger speed gains at high loads here.
Let’s see now what we have in the Web Server pattern.
There’s a little more red color in the table of efficiency. Take a look at the diagram:
The diagram looks fine: enabled TCQ most positively affects the performance of the arrays.
There is a higher percentage of write operations in this pattern, and this fact is going to affect the results strongly.
That’s true: the new technology brings performance gains to the JBOD and RAID0 arrays but the mirroring arrays become a little slower.
Now we reduce the address space to 32GB and rerun the test.
The overall picture has remained the same, even though the efficiency of TCQ technology is again approaching 30% at high loads. The JBOD and RAID0 arrays again react positively towards TCQ, while the RAID1 and RAID10 feel somewhat uncomfortably in this mode.
This test is the last of the synthetic patterns we use in IOMeter. We can now proceed to our second benchmark, FileCopy Test.
We stick to our traditional methodology of using FC-Test: we create two logical volumes, 32GB each, on the array and format them in NTFS and then in FAT32. We create a set of files on the first volume, and then this pattern is read from the array, then copied into a folder on the same partition (copy-near – inside one and the same logical volume), and finally copied onto another partition (copy-far).
The test system is rebooted between the tests to avoid the influence of the OS’s caching on the results. We use five file patterns here:
Let’s start with NTFS. We’re going to examine the results of each test action for each pattern independently due to the abundance of data we have received. The first action is the creation of a set of files on the array.
Take a look at the table of efficiency:
There’s little blue here. It is mostly at the bottom of the table.
Let’s examine the diagrams:
The TCQ mode seems to be a poor helper at creating files. Some speed growth is only observed with small files and only with many-disk arrays. And we suspect even this gain is not due to TCQ, either.
Next goes reading.
The table of efficiency suggests that the TCQ mode more often reduces the read speed than increases it.
Here are the diagrams for each of the patterns:
It’s only the RAID10 that enjoys a speed gain from enabled TCQ, which is by the way contradictive to the results we’ve got earlier (in the Sequential Read pattern). And of course we should single out the speed boost of the two-disk RAID0 when processing the Install pattern.
Now let’s see how the file copy speed depends on the TCQ mode.
There seems to be less of red in the table of efficiency than before. It’s strange since the controller has behaved badly in mixed modes in the earlier tests.
Here are the diagrams for each file pattern:
The RAID1 and RAID10 clearly profit from TCQ. The gain amounted to the whopping 56% for the RAID1 as it was processing large files!
Let’s see if copying from one partition to another is any different.
We seem to have two favorites here: the Install pattern is performed with a positive efficiency on all the arrays, and the RAID1 array profits from TCQ with all the patterns. And the efficiency of TCQ becomes as high as 90% at copying large files! It means that copying a large file on an array with enabled TCQ is performed almost two times faster!
The results of the controller in FAT32 are generally similar to NTFS, so we don’t think it necessary to discuss them at length. You can follow this link to view the tables and graphs for FAT32.
So, we have noticed a few regularities in the file copy tests. Enabled TCQ affects the read speed but slightly, with the exception of the RAID10, and negatively affects the write speed (the RAID10 is an exception). TCQ’s influence on the copy speed greatly depends on the type of the array. The mirroring arrays have profited considerably from enabled TCQ. The RAID0 and JBOD, on the contrary, slow down as we enabled TCQ.
The controller has showed itself a worthy device in our tests. But we should acknowledge that its PCI32/66MHz interface didn’t permit the controller to show a good performance in tests of sequential reading and writing with many-disk arrays. Hard drives have just become too fast. :)
Tagged Command Queuing technology showed its best only at high loads and with complex arrays like RAID10 and RAID1. Unfortunately, we cannot yet explain this behavior of the controller because TCQ-supporting drives are currently being manufactured by a single company.
Do you think it makes sense to perform tests on disks with support of NCQ?
