by Nikita Nikolaichev
04/08/2003 | 11:58 PM
Today we are going to take a closer look at the first SerialATA hard disk drive, which has already started selling: this is Seagate Barracuda ATA V. Seagate Company appeared a kind of a pioneer in pushing forward the new interface and seems to have really serious intentions. Our goal will be to check how well SerialATA interface works and to compare the performance of SATA and ATA hard disk drives to find out if the game was worth the candle.
So, what is SerialATA? This is a new interface, which should replace the common ATA interface. The major difference between them is a different way of transferring data along the cable. Instead of the parallel 40-pin cable the new interface uses only two conductor pairs plaited together with three earthing conductors making a flat cable. Each conductor pair can transfer the data in their own direction. The data transfer principle is absolutely the same as the one used in Ethernet or FibreChannel (only the operation frequency is different). With this data transfer procedure the interface ensures 1.5Gbit/sec rate at up to 1m distance.
Well, we will not continue with the small talk any more, let’s just answer one question: who needs SerialATA? We will try to recall all parties interested, and we will begin with the hard disk drive manufacturers. Do they really need the new interface? At present, I can hardly find any powerful arguments in favor of the urgent introduction of the new interface.
It’s true, ATA/ATAPI6 standard managed to solve the big drives problem (namely it allowed the drives to overcome the notorious 128GB barrier), and if some of the manufacturers believe that their drives need more speed, no one can prevent them from following Maxtor’s example.
ATA standard is used in millions of PCs and they are potentially ready for the new ATA HDDs to be installed. Yes, of course, older mainboards may have difficulties with HDDs of larger storage capacity. But it can be easily solved by just reflashing the mainboard BIOS. However, there is an opinion that the mainboard guys resorted to this kind of “sabotage” on purpose to force users to buy new mainboards. Because all new mainboards have no problems working with HDDs of large storage capacity.
And the users, who do not like to be blackmailed, can always get an external PCI controller card for new hard disk drives.
Maybe SATA looks very beneficial to the mainboard makers? Maybe, if we regard it as an additional feature, because the longer is the mainboard specification, the easier it is for the seller to convince the customer that he really needs this product. On the other hand, the manufacturers shouldn’t give up the regular PATA support, because there are still too many devices for this interface in the market already and even more are coming. But in this case the mainboard will have to feature additional connectors. And it pushes the prices up, especially since all today’s mainboards support SATA only due to the integrated RAID chips from third companies. Besides, these RAID chips require the connection to the PCI bus, which automatically limits their practical bandwidth from the hypothetical 150MB/sec to 133MB/sec (and why should it be better than UDMA133 then?). so, it appears that the mainboard makers do not need SATA so urgently...
Well, I get the impression that there is no one who really needs SATA interface now. But wait, we forgot to mention one more interested party: the users! Let’s figure out what the advantages are, which the users could get with a SATA hard disk drive installed in their systems. Besides, we will also share our impressions of the “first contact” with a SATA HDD:
Yes, of course the SATA cable is much more compact, and will not take up a lot of room inside the PC case. Besides, you can place it inside the case very conveniently, because it allows up to 1m length.
But since one cable allows connecting only one device to the controller card now, then a system with multiple HDDs will look very much like a snake terrarium: a mess of thin cables. Besides, who told you that the cables are flexible? All cables that I had a chance to touch were easy to bend only in one direction: along the cable. And they are absolutely non-flexible in any other direction. As a result we face a serious problem, which we will dwell on later in this article.
And now a few words about the cable length. SATA standard limits the maximum cable length as 1m. And all promotion materials present it as an advantage. But can you imagine my astonishment, when I opened the boxes with SATA controllers (regular ones and RAID ones) and saw the cable pieces of the common 45cm length. What a swindle!
Now all the big and broad PATA connectors will be replaced with a bigger number of compact SATA connectors.
Yes, the connector has become smaller. From the user’s point of view it means only one thing: it has become harder to plug the cable in. Especially is the PC has already been assembled. The cable connector plugs into the mainboard connector really easily (if you aimed well, of course :), however it quickly loosens the connection between the cable and the SATA device, which seemed so secure to you a minute ago. Since there is no lock on the connector, the rigid cable immediately distorts the connector, so that you need just to shake the PC during transportation, for instance, to lose the contact completely... In fact, the old bigger PATA-connectors provided a much more secure contact due to extra friction...
The opportunity to connect and disconnect HDDs on the fly is a significant improvement. If you wanted to be able to do HotPlug with the ATA hard disk drives, you needed special mobile racks. Now the HDD connectors and electronics are designed to support “safe” HotPlug.
Well, I don’t have any arguments against this feature. The only trifling exception is the fact that the today’s operation systems hardly support the real HotPlug. All this is very relative.
SATA protocol guarantees that every byte of information will be transferred along the cable, unlike ATA/ATAPI6 standard, which provides the check sum only for the data and the commands are all transferred trusting to luck.
Another serious advantage of SATA interface is very high data transfer rate between the HDD and host-controller. With SATA we will finally be able to forget about the Master-Slave concept, so that each SATA device will not split the bus connecting it to the controller with any other device and will have its entire bandwidth at hand. And it is exactly 150MB/sec.
However, until SATA controllers get embedded into the chipset South Bridges, they will have to use the PCI bus to access the memory, which means that we will never get the desired 150MB/sec from the SATA HDD. Moreover, we will not squeeze the sacred 300MB/sec from two SATA drives working in RAID 0 array! Of course, there are mainboards with PCI32/66MHz bus but they are very few...
On the other hand, contemporary hard disk drives can transfer the data at this maximum speed for a pretty short time in a row: until their cache is empty. And as you understand, this will happen very quickly. So, we do not actually need 150MB/sec bandwidth nowadays, so you can regard this feature mostly as a good thing for future products.
Since we came to speak about the future.... If I haven’t yet scared you with all this discussion, I think it’s high time I slowed down with my anti-SATA arguments and cast a glance a few years ahead.
Imagine a computer of the end of 2005. A mainboard with an unbelievably powerful CPU. The processor bus frequency equal to twice the contemporary one, but the mainboard layout didn’t get any more complex, because the developers do not design 32 pins for each ATA connector (16 for data and 16 for control signals) any more. Now they are laying out only 4 signal lines for each SATA connector!
The HDDs have acquired new 2.5” form-factor. The interface used is SerialATA II, of course. The HDDs are no longer powered directly from the system PSU, but are connected to special plugs on the mainboard. This allows to same some power by shutting down the HDD motor if it is idling.
Hm, looks very attractive, don’t you think so? Well, since we are really anxious about it and are not used to keeping our hands in pockets, let’s try to find out what can we get from SATA interface today already:
Well, this seems to be all I could think of so far.
Now let’s have a closer look at the new generation hard disk drive.
Well, this HDD looks almost the same as the regular Barracuda ATA V. Get closer now. I removed the protective SeaShield cover from the electronics PCB for your convenience:
The only difference, which you can notice with a naked eye is the new connector:
There are 7 contacts of the information connector on the left (the long pins are the earthing contacts and the short pins are the information ones) and power contacts on the right. As you see, there are a lot of “long” pins in the right part of the connector. This was designed to ensure proper HotPlug (and unplug, of course). Different length of the power contacts for each voltage (there are three voltages altogether: 3.3V, 5V and 12V) the HDD will always know which way the power supply connector is moving. In other words, it will be able to identify whether is being connected to or disconnected from the PSU.
The remarkable thing about the HDD electronics is a new LSI chip, which I have never come across before and failed to find in the Google search engine. We have already seen an 8MB cache buffer on other HDDs, though it is the first Seagate drive with a cache buffer like that. Anyway, the unknown LSI chip warms up our interest even more.
My initial suppositions about this chip being an ATA<->SATA converter, luckily turned out absolutely wrong. I would like to thank Gary Hendershot for the additional information about this chip, which I can’t wait to share with you.
In reality this chip is none other but an individual controller-transmitter of the serial interface. In other words, this chip simply connects the major hard disk drive controller with the SerialATA Host controller. The LSI chip core feature a beautiful name: “GigaBlaze”. You can find more details about this chip here and here.
This way, Seagate Barracuda SATA V HDD is really the first SATA-drive wit the native SerialATA interface support. No more doubts.
And this is a power adapter:
These adapters will be really demanded unless the mainboards get a corresponding connector onboard.
And these are the information SATA cables:
So, how will we test our SATA hard disk drives? It seems pretty simple at first sight: there are a lot of mainboards with integrated SATA chips from Promise and Silicon Image. However, I wanted to check the performance of SATA HDDs with both: Promise and Silicon Image controllers (so that we could get a better idea of the influence integrated SATA<->ATA translators have), but couldn’t find a mainboard with both controllers onboard.
Besides, it would be absolutely wrong to use different mainboards for the tests like that, not to mention mainboards for different CPUs, because all benchmarks are more or less processor-dependent.
This is exactly the reason why we used one testbed for all our tests with different add-on PCI controller cards.
And what about the hard disk drives? Starting from the beginning of this year we could get hold of some Barracuda Serial ATA V HDDs with 120GB storage capacity and early 3.00 firmware version. At that time we managed to get a sample into our lab and to run some tests, but we didn’t post any results, because they were evidently weird (we will specify the matter below). The performance we managed to squeeze out of that SATA hard drive definitely didn’t correspond to what they were actually capable of, so we decided not to give way to panic. Really, I don’t think it could be a good idea to announce all over the web that the “Serial ATA killer turned out impotent” :)
A little later Barracuda SATA with 3.01 firmware appeared. The results obtained with these drives were completely different from the previous ones, which proved all our suppositions about raw firmware and first samples.
By a lucky chance we got hold of two Seagate Barracuda Serial ATA V HDDs of different storage capacities: ST380023AS and ST3120023AS (80GB and 120GB respectively). And it was really great, because we will be able to compare their performance with that of their ATA analogues.
I was very much exited to have an 80GB drive participating in our review, because this is the most popular and attractive storage capacity from the price-to-capacity point of view. However, if an 80GB ATA HDD were competing with a 120GB SATA HDD, it could be really tough to say, who would win :)
Seagate Barracuda SATA and ATA V HDDs with 80GB storage capacity feature better average seek time than 120GB drives (due to the fact that 80GB hard drives do not use the entire platter capacity). Therefore, if we compared a “fast” 80GB ATA drive with a “normal” 120GB SATA drive, we could have really hard time...
For our comparison we took three Seagate hard disk drives: ST380023A, ST3120023A and ST3120024A. The first two HDDs are the regular barracuda ATA V drives with 2MB cache-buffer, and the third solution deserves mentioning separately. This is Barracuda ATA V but equipped with an 8MB cache buffer. Yes, there are HDDs like that too. And this drive appeared very useful for our test session, because it turned out a kind of a bridge from the regular ATA HDDs to the new SATA ones. As we know, Seagate’s SATA disk drives feature 8MB cache-buffer. That is why when we compare their performance with that of regular ATA drives with smaller cache-buffer, we will not be able to state with certainty what exactly made SATA HDDs faster: larger cache-buffer or faster interface. But now that we have ST3120024A at our disposal we will try to draw “correct” conclusions.
By the way, if you have been reading the passage above attentively enough you can skip the Conclusion section of this article, because I have just given the conclusions away :)
The testbed was configured as follows:
ATA/100 hard disk drives were tested with Promise Ultra100 TX2 controller (BIOS: 2.20.0.14 Drivers: 2.00.29), and SerialATA drives were tested with two controllers: Promise SATA150 TX2 Plus (BIOS: v1.00.0.20 Drivers: 1.0.0.16 ) and SiliconImage SiI CP3112SATA150 (BIOS: 4.1.50 Drivers: 1.0.0.41).
Here are the controllers we used:
Promise SATA 150 TX4 differs from Promise SATA 150 TX2 Plus by the absence of an ATA/133 channel and two SATA-channels laid out instead.
We should also mention that Promise SATA controllers have one remarkable feature distinguishing them from the SiliconImage solution. If the latter is a fully-fledged SATA controller, then Promise cards were designed from the regular Promise ATA/133 RAID-controllers by adding a sufficient amount of Marvel translators (the Marvel logo on the chip marking indicates that). We have already had some experience with the PATA<->SATA translators, and this solution didn’t improve the performance too much. I wonder how these marvel translators will affect the performance of Promise controller cards...
We used the following software for our tests:
Before the tests the AAM register of all HDDs was set to OFF position (FAST mode) with the help of Hitachi Feature Tool Utility. For WinBench tests all the drives were formatted in FAT32 and NTFS as one logical drive with the default cluster (to format the drives in FAT32 we used Paragon Partition Manager software). The tests were run four times each, the maximum result was taken for the diagrams. The drives didn't cool down between the tests. The tests in Intel IOMeter were run in SequentialRead, SequentialWrite, DataBase, WorkStation, FileServer and WebServer patterns. If you are looking for the detailed description of these patterns, please see our previous articles.
The reviewed hard disk drives had the following firmware versions:
Returning to our decision to choose controller cards from Promise and SiliconImage, I would like to say that even though we had already collected quite an impressive amount of SerialATA and even SATA-RAID controllers by the time we received HDD samples with 3.01 firmware, we decided to dwell on only two SATA controllers this time. The reason for this decision is very simple: these two controllers have already become very popular (or will become very popular in the nearest future). Both: Promise Technology as well as SiliconImage, not only produce controller cards based on their chips, but also supply their chips to the mainboard makers to be integrated into their products. Today it is simply poor taste to have no integrated SATA/ATA RAID controller onboard :) So, these two companies are really doing great.
3ware and HighPoint controllers were not included into the article because these are RAID-controllers and it doesn't make much sense to test a single HDD with them. The BIOS of a RAID-controller, as well as its drivers are specifically optimized for work with multiple HDDs, that is why in case of a single hard disk drive an ATA RAID controller is usually slower than just an ATA-controller (at least this is what we usually observed by Promise and HighPoint controller cards).
3ware and HighPoint RAID controllers are quite nice solutions, we have already tested them, but we are going to discuss their performance in greater detail in another article :)
Before we pass over to the actual benchmarks results, let's make a few terms clear. Since I don't think it would be a good idea to use the full models names for the hard disk drives tested, like ST3120023A or ST3120023AS, I suggest the following short names indicating the drives, which should be very easy to understand:
Then, since one and the same HDD can be tested with different controllers, the results on the diagram will stand for a combination of a HDD and a controller card. Unfortunately (or, maybe, fortunately), we had to simplify the controller names as well to make them shorter. as a result we got the following combinations for further consideration:
As you may have already understood, Promise SATA 150 TX2 Plus controller formed two combinations with the mysterious abbreviations, such as "WB" and "WT". This is none other but "Write Back" and "Write Through". The matter is that together with the controller drivers we also got a small utility aka Cache Config:
This utility allows changing the controller work mode (caching strategy). Since Promise PDC20375 chip is very unlikely to have a big cache-buffer, I tend to believe that this is all about software cache emulation. To be more exact it should be about some preliminary processing of the on-going requests by the driver, which will definitely eat up some CPU resources. And very soon we will see it with our own eyes.
Before we start discussing the results obtained, I would like to remind you that this is our first practical investigation of the SATA hard disk drives and SATA controller cards performance and features. We haven't yet decided which controllers should be used as reference ones for illustrative HDDs comparison as well as which hard disk drives should be used for controller tests. Therefore, please keep in mind that the results discussed are obtained for a particular HDD working with a particular controller.
We will start our tests with HDTach 2.61. We have been using this benchmark for three years already and we have seen a lot of strange results, but this is absolutely unbelievable:
First of all, check out the Average Access Time results: 80GB HDDs appeared much better here than 120GB drives (although there is nothing to be surprised with, we have already told you about the cut-down platters of 80GB models). It was a different thing that surprised us: among all 80GB hard disk drives, the results of a Promise-WT + SATA80 combination stood out having shown only 12.6ms access time! The only explanation that comes to my mind right away is that the HDD doesn't do any lazy writes when the WT mode of Promise SATA150 TX2 Plus is enabled.
Secondly, if we take a look at the second line, Read Burst Speed, we will see a very strange picture: the results differences between the tested SerialATA HDDs are simply gigantic. The major "incendiary" appeared Promise controller: depending on the caching mode (WT/WB) the read speed from the HDD buffer (Read Burst Speed) varied from 60 to 334MB/sec!
It is also quite remarkable that the Read Burst speed depends a lot on the hard disk drive firmware versions and controller driver version! :)
But if we take a closer look at the obtained results, we will see that it would be simply impossible for any controller to transfer 334MB/sec via the regular PCI32/33MHz bus. It means that these results are of no value and HDTach benchmark cannot always measure the Read Burst speed for SATA HDDs correctly. As soon as we discovered that, a question arises: does HDTach measure the Read Burst speed correctly for regular hard drives? Or this benchmark is caught unawares only by the tricky Promise drivers?
Well, let's leave out the read speed, as there is nothing specifically interesting there. And as we come to writing...
Please tae a look at the maximum write speed of the ST3120024A HDD (ATA120-8 according to our abbreviations) – it is more than twice as big as by ST3120023A (ATA120)! It would be quite logical to suppose that ST3120024A HDD manages to reach such a high write speed not only due to the mechanical increase in cache-buffer size, but also due to a new caching strategy applied. A little later we will taker a look at the graphs screenshots for reads and writes, and in the meanwhile let’s check another strange phenomenon we discovered.
With the SiliconImage controller all SATA drives of various storage capacity showed not only different maximum write speed (we cannot disregard the possibility of occasional write speed boosts), but also different average write speed. And this happened even though both HDDs feature the same firmware and were tested with one and the same controller. This is really surprising...
Before we start talking about the actual benchmark screenshots, I would like to draw your attention to the processor utilization rate demonstrated by a SATA drive connected to Promise controller working in WB mode: the CPU utilization appeared 17.5%! Well, this is another piece of evidence proving our supposition about the software implementation of WB algorithm in Promise controller drivers. However, HDTach test has already disclosed some of its surprising secrets to us today, so I would refrain from drawing any conclusions so far.
Now, let’s have a look at the graphs obtained in the run of HDTach benchmark. Here is a screenshot taken during ST3120023AS tests with 3.00 firmware and Promise SATA 150 TX2 Plus (WB) controller:
ST3120023AS with 3.00 firmware and Promise SATA 150 TX2 Plus (WB)
The emotions awakened by the read graph are highly positive, but as we come to writing things turn pretty strange. In the very beginning the write rate sky-scrapes (up to 60MB/sec), after that it rests for a while at 50MB/sec and then drops down to 10MB/sec. then the write speed rises again but manages to reach 30MB/sec only and then again crashes down to 10MB/sec. Further on we will see the graph oscillating between the last two values, which will look like a thick green line on the graph.
As we understand, the write speed on the platter by Seagate Barracuda SATA V HDD cannot make 60MB/sec. Then it means that this value is none other but the data transfer rate at which the data block is transferred to the HDD cache-buffer. If this statement is correct then the speed upsurge in the beginning of the tests can be easily explained by the fact that the cache-buffer was filled with more than one request! If the HDD firmware assigns a significant part of the cache-buffer to the lazy write, then we will really see something like that. To double check this supposition I opened the log-file of the HDTach benchmark and was very pleased to discover that the write speed started dropping as soon as it came to the 8th request (as HDTach saw it). After that we resort to simple math1ematics: the cache buffer size is 8MB, the data block size used by HDTach is 1056KB (in reality this benchmark generates a pack of 33 requests with 64 sectors in each, but Promise controller drivers “combine them into one big request”, because the controller works in WB mode, as I understand it).
Unfortunately, the monitoring utility we used didn’t allow to get the request size AFTER it passed through Promise controller drivers. That is why our suppositions about the way Promise controller drivers work, are mere suppositions.
Now we multiply 7 by 1056 and get 7392KB. Let’s subtract from 8192KB (claimed cache-buffer size) the obtained 8392KB and discover that there was not enough room in the buffer for the 8th request! :)
Before the hard disk drive received the 8th data block from HDTach, it had to write at least 256KB of data on the platter (to free some room in the cache buffer for the complete 8th data block to be accepted). And this is possible only if the Seagate drive’s cache-buffer is organized in such a way that it allows uniting several cache blocks with different physical addresses into a single cache-line. Otherwise, the HDD has to rewrite all the data for one of the previous requests onto the platter, before it accepts the new data block.
Well, in reality things are even more interesting. To make a hard disk drive complete the write operation, which every normal HDD always tends to delay to perform a lazy write whenever possible, HDTach benchmark sends a read request (32KB) every time 33 write requests have been sent. What an insidious benchmark! :)
Now let’s see what changes as soon as we shift from firmware 3.00 to firmware 3.01:
ST380023AS with 3.01 firmware and Promise SATA 150 TX2 Plus (WB)
As we see, the test behaves just a little bit differently now. The only difference s that we can now see separate peaks on the write speed graphs (it is probably because the entire buffer can no longer be used for writes…). However, the upsurge in the beginning of the tests is still there and the write speed remained not very high.
And now we will change the work mode of Promise SATA 150 TX2 Plus controller into WT (Write Through) with the help of Cache Config utility. This should slow down the processing of all write requests:
ST380023AS with 3.01 firmware and Promise SATA 150 TX2 Plus (WT)
Well, this changes the entire picture completely. Look how big the write speed now is!
Since the HDD buffer is now filled with 32KB write requests, it gets filled and emptied in a much smoother way.
To make sure that it is not SATA interface or tricky Promise drivers that speed up the writes, let’s have a look at the next three graphs. We will begin with the results shown by SATA 80 HDD with SiliconImage controller:
ST380023AS with 3.01 firmware and SiliconImage CP3112SATA150
As you see, the graph is very much like the previous one. Replacing the controller didn’t tell on the way HDTach worked. Now let’s try to completely change the HDD being tested. We will take a regular ATA/100 hard disk drive, in our case it will be Seagate Barracuda ATA V 120GB (ST3120023A) with 2MB buffer, and a Promise Ultra100 TX2 controller:
ST3120023A with 3.31 firmware and Promise Ultra100 TX2
The write speed become quite normal, i.e. not very high. Could it be the cache buffer size then that affected the results? No problem, let’s check it out. We take an ATA/100 HDD with 8MB cache-buffer:
ST3120024A with 3.33 firmware and Promise Ultra100 TX2
This is where the story comes from! :)
About a year and a half ago I had an argument with one of my colleagues about the influence of the cache-buffer size (and its structure) on the write speed measured by HDTach test. I hope he is reading this review now :)
Well, the only thing left, which we should also check is the CPU utilization as measured by HDTach. Among all the HDD + controller combinations tested we would like to point out only one: SATA 80 (ST380023AS) + Promise SATA 150 TX2 Plus working in WB mode. The CPU utilization in this case appeared about 3 times as high as by all other testing participants.
Summing up the results obtained, we would like to point out the following. With the testing methodology applied by HDTach Seagate drives with 8MB cache-buffer demonstrate better results than HDDs with 2MB cache-buffer. We would also like to stress that it is still too early to claim that the interface type (namely ATA or SATA) affects the performance.
Well, we will try t imitate read and write benchmarks ourselves then, with the help of the excellent Intel IOMeter utility :)
The algorithm used for read and write speed measurements in this test is completely different from what we saw in HDTach benchmark. In our IOMeter patters the HDD receives read and write requests with a fixed queue depth (queue=4), i.e. the hard disk drive is always under a certain workload. At the same time, we do not mix together the reads and writes thus making it easier for the HDD to work. Really, if we need to know the maximum write speed of the hard disk drive, why should we ask it to write and read simultaneously? The second difference of our approach to measuring the read and write speeds is the fact that we make the hard drive work with the data blocks of different size instead of using data blocks of the same size.
As a result, our methodology provides us with much more information about the HDD tested, and not only about it!
Well, let’s begin with SequentialRead. We measure the read speed of the HDD working with data blocks of different sizes. The table below will illustrate the dependence of the read speed on the data block size (the sizes are given in the first column):
Let’s have a look at the test results taken for hard disk drives of different capacities separately. We will start with the 80GB drives:
This diagram allows us to compare the read speed of a regular ATA HDD with the read speed of the SATA HDD, moreover, the latter was tested with three SATA controllers. Yes, there is no mistake: we used three controllers. As you remember, the special Cache Config utility mentioned in the beginning of the article allows us to turn our Promise SATA 150 TX2 Plus into two completely different controllers.
As we see incase the data blocks are small, the SATA HDD working with Promise SATA 150 TX2 Plus controller in WB mode appeared twice as fast as its rivals. I don’t know what you think about it, but I am pretty concerned about this repetition factor. :)
But I am also concerned about the fact that when we set Promise SATA 150 TX2 Plus controller into WT mode, the SATA hard disk drive appeared even slower than the regular ATA solution.
SiliconImage controller didn’t show any outstanding results: the performance of a combination with this controller was about the same as the performance of the regular ATA HDD working with a “regular” Promise Ultra100 TX2 controller.
When we work with bigger data blocks (>86KB) all SATA controllers and drives appeared equally fast and the ATA drive fell a little bit behind them. Its read speed reached 40MB/sec (as soon as the data block size grew up to 16KB) and stopped there.
The results indicate that SATA controllers without specifically optimized drivers do not increase the HDD read speed in case of smaller data blocks. But let’s not hurry with the conclusions too much, because as you remember, we saw some unknown chip on the Seagate drive picture. Maybe it is the one that prevents SATA interface from working to the utmost of its powers?
Let’s check the performance of 120GB HDDs now:
As we see, ATA HDDs are the winners this time. Moreover, a solution with 2MB cache-buffer appeared faster than a solution with a larger cache-buffer.
It is hard to say what made SiliconImage SATA controller and SATA HDD work so slowly. Especially, since the 80GB drive performed just fine with the same controller, as we saw in the previous tests. Well, let’s add this question to our list of mysteries :)
And now let’s discuss another phenomenon: the read speed of a SATA hard disk drive with Promise SATA 150 TX2 Plus controller. Being a dedicated materialist, I claimed that this performance growth is simply impossible without any special optimization. With quite a big probability, we dare claim that the requests are processed and cached by the controller driver, which automatically lays the entire workload onto the system CPU.
IOMeter test also measures the CPU utilization during disk operations processing, so that we can compare the results shown by all our controllers and double check our suppositions:
Take note of the upper graph: it proves just excellently that the WB mode of Promise SATA 150 TX2 Plus controller is implemented on the software level. When the data blocks are of small size the CPU is loaded almost completely. At the same time, as the requests size increases (here we are talking about requests sent to the HDD and hence received by the controller driver), the CPU utilization drops down rapidly. When the data blocks are of larger size, the CPU utilization reaches around 30% and then drops down to the level of other testing participants.
A little bit earlier I expressed a supposition that the controller drivers in WB mode combine the data blocks with sequential addresses, but the CPU utilization graph suggests that the driver algorithm is far nit that simple. But there is one thing, which we can state with all certainty: the driver doesn’t optimize the requests more than 64KB big.
By the way, Promise SATA controller managed to show not only the highest CPU utilization in this test, but also the lowest! Take a look at the results shown by a SATA HDD and a Promise SATA 150 TX2 Plus controller in WT mode. When the data blocks size is below 4KB, the CPU utilization of this combination is lower than that of all other configurations. And the most curious thing about it, is the fact that it hardly depends on the data block size! What tricky drivers Promise has got!
Now we are passing over to the writes:
Just like in the previous case we will consider the results of 80GB HDDs first.
Promise SATA 150 TX2 Plus controller proved also very fast when processing write requests (in WB mode). But the SiliconImage controller is also evidently faster than Promise ATA controller. Have you noticed that the graph for SATA Promise controller in WB mode is always about one step ahead of the SiliconImage graph (I still insist on the assumption that Promise combines data packs :) Even the angle of inclination on the same intervals is similar!
Note that a stumbling stone for SiliconImage controller appeared 8KB data blocks.
The performance of 120GB HDDs gave us to understand that larger cache-buffer is of no effect during sequential writes. Anyway, why did we expect it to speed up the writes at all? If the amount of sequential data written onto the hard disk drive is much larger than the buffer size, then the latter will have absolutely no influence on the write speed (unlike the way HDTach works). Also take note that ST3120024A HDD (Barracuda ATA V with 8MB cache-buffer) processed writes slower than ST3120023A (Barracuda ATA V with 2MB cache-buffer). In other words, it looks as if the large buffer has negatively affected the HDD performance, doesn’t it? Well, I assume that it is mostly not because of the buffer size increase but because of the different firmware version of the HDD with 8MB cache-buffer.
And in conclusion let’s check the CPU utilization during writes:
As we have expected, the situation is about the same as we saw in case of reads. When we process smaller data blocks, the CPU utilization for Promise SATA 150 TX2 Plus controller reaches 100% in WB mode and hardly overcomes 50% in WT mode. SiliconImage controller loads the CPU a little bit more than Promise SATA 150 TX2 Plus in WT mode. But the best results were again demonstrated by the good old Promise Ultra100 TX2 buddy.
Having tested the HDDs performance in Sequential Read and Write tests, we suggest paying a bit of attention to random requests. DataBase pattern suits perfectly well for this investigation, because it always selects the address of an 8KB data block with the help of the random numbers generator. Besides, this pattern will allow us to find out how different controllers react to different writes-to-reads ratios.
So, let’ begin with the linear workload (queue=1):
To make the analysis easier we will separate the graphs for 80GB HDDs from those for 120GB HDDs.
The first diagram shows the performance of 80GB models tested:
The hard disk drive with SATA interface are evidently faster than their ATA forefather. The advantage of SATA-drives is especially great when the write requests share is bigger. No wonder, since SATA drive feature bigger cache-buffer, which makes the lazy write more efficient. Make sure you check pay attention to the performance of our SATA drive with Promise SATA 150 TX2 Plus controller in WB mode. When working with RandomWrite requests the performance of this combination grows up. And this is also no surprise to us, as we know very well already that in WB mode the drivers of Promise SATA 150 TX2 Plus controller process the requests “specifically”. As we see, the controller driver performs write requests caching (or sorting) as efficiently, as the HDD performs lazy write algorithms (in some cases, this caching is even more efficient than the HDD lazy write).
120GB HDDs demonstrate a completely different situation: ATA drive with smaller cache-buffer is very successfully competing with the SATA HDD and a SiliconImage controller. But what struck us as something really unexpected, was very uncertain performance of the ATA drive with 8MB cache-buffer. As we see, it gets worse and worse as the writes share increases.
Now let’s increase the workload (queue=16):
Under this workload the HDDs performance appeared different enough, so that we can easily distinguish between the graphs. The best one in this testing conditions is a SATA HDD combined with Promise SATA 150 TX2 Plus controller in WT mode. Only in case of Random Write the leadership goes over to the same HDD with the same controller in WB mode. The ATA hard disk drive starts very well. It runs neck and neck with the SATA drive and Promise SATA 150 TX2 Plus controller in WT mode when processing Random Reads, but as the number of writes gets bigger and bigger, the ATA drive starts falling behind the rivals. SATA drive with SiliconImage controller didn’t prove very fast in with Random Reads, but the bigger grew the writes share, the closer it approached the SATA drive and Promise SATA 150 TX2 Plus controller in WT mode.
The drives with 120GB storage capacity keep surprising us. The leader remains the same, it is an ATA drive with smaller cache-buffer, and the maximum gap between the leader and the ATA solution with 8MB cache-buffer occurs when the amount or reads and writes are equal. In other words, it happens exactly in the situation where we have expected to see the advantages of the larger cache-buffer!
So, to make the “optimization” principles of different controllers finally clear, we are going to run another set of tests with 256 requests queue depth.
Here it is, the notorious optimization. No doubt that Promise SATA 150 TX2 Plus controller in WT mode copes with requests sorting best of all. Taking this fact into account, it is quite strange that the performance of the same controller in WB mode proved so low. The performance drop by this controller is most likely to be caused by the fact that controller driver needs more time to process the request. Since the data block address in DataBase pattern is always calculated at random, the optimization, which has proven so efficient for Sequential-requests, namely packet chain command, appeared wasted and only slows down the overall commands processing. As a result, we get lower performance values...
SiliconImage controller can compete with Promise SATA 150 TX2 Plus (WT) only in the “easiest” modes, when either reads or writes are dominating. In all other cases, this controller is close to failure.
As the number of writes increases, the ATA hard disk drive lags more and more behind, which I assume is a result of smaller cache-buffer size.
For 120GB HDDs everything takes its natural course. ATA solution with Promise Ultra100 TX2 is the fastest, SATA drive with SiliconImage controller is a little behind in the middle, and the ATA drive with 8MB cache-buffer behaves very similarly to its “younger borther”.
After synthetic benchmarks, we feel we need some server stuff :)
Since we cannot predict how big the workload of our server will be, we suggest comparing the HDD + controller combinations according to their average Total I/O values:
The leader among 80GB drives is the SATA solution working with Promise SATA 150 TX2 Plus controller in WT mode. The second prize was won by a SATA drive with SiliconImage controller and the third – by an ATA HDD with Promise Ultra100 TX2 controller. The last one among the four 80GB HDDs appeared a SATA drive with Promise SATA 150 TX2 Plus controller in WB mode. As we have already pointed out to you several times, the WB mode slows down the HDD and controller card in case of random requests.
Among the 120GB HDDs the laurels belong to an ATA drive with 2MB cache buffer. The second fastest is a SATA drive with SiliconImage controller and the last one appeared an ATA drive with 8MB cache-buffer.
It is interesting that as soon as the requests type changes (WebServer pattern has no write requests unlike FileServer pattern), the overall picture changes as well. For example, the SATA drive with SiliconImage controller gives in quite noticeably, while in FileServer pattern this combination performed very stably. But just look how big is the performance improvement of ATA drives here! Even though the first prize was again awarded to the SATA drive with Promise SATA 150 TX2 Plus controller in WT mode, just like in the previous pattern.
The server benchmarks revealed a certain advantage of SATA hard disk drives and Promise controllers. But how well will the drives run if they are used for desktop needs? And what is the difference between the disk subsystem workload of a desktop PC and a server? First of all the difference lies with the requests intensiveness. This is why our WorkStation pattern is aimed at checking the HDD performance under smaller workloads (1-32 outcoming requests):
We use a different formula to calculated the HDD performance rating in this pattern. In the server patterns we simply averaged the Total I/O values obtained. And since high workloads are not typical of desktop disk subsystems (to be more exact, they may occur sometimes, but it will not last long), it would be more correct to take them into account as well but to assign a certain weight coefficient to them:
Performance = 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
As you see, this is a very simple formula: the contribution to the final performance rating is inversely proportional to the corresponding queue depth. Note that this formula has been derived empirically and we don’t claim any deep scientific background to be involved :)
But anyway, it rates the HDDs very quickly. Have a look at the 80GB drives: SATA HDDs are indisputable winners here. The 120GB SATA drive performed a little less impressive, but it also managed to outpace the rivals in its own group.
I wonder what caused this speeding of SATA drives? Is it the interface that helps them out? It is more likely to be larger cache-buffer, as the write requests are quite numerous in WorkStation pattern.
Now let’s compare the hard disk drives with the good old WinBench99 test set:
As usual, we will take a closer look at two major subtests: Business Disk WinMark and High-End Disk WinMark.
The first thing I would like to draw your attention to is the performance of 120GB drives in Business Disk WinMark. The large cache-buffer is evidently an advantage here. Even with ATA100 interface Seagate Barracuda ATA V with 8MB cache-buffer appeared 17% faster than the drive with smaller cache. But the SATA drive turned out even faster than that! If we compare the performance of 120GB drives in High-End Disk WinMark, we will see that the advantage of an ATA drive with 8MB cache-buffer over the same drive with a 2MB cache-buffer is not very big, while the SATA model is far ahead of both of them.
In the 80GB group the situation is very similar: SATA hard disk drives are stably ahead of ATA solutions in both tests. Note that the SATA drive with Promise SATA 150 TX2 Plus controller in WB mode proved faster in Business Disk WinMark, while in High-End Disk WinMark its performance appeared lower than that of a SATA drive with Promise SATA 150 TX2 Plus (WT) controller.
Now let’s check the performance in NTFS file system:
Well, the changes are not that drastic, but they are noticeable :)
First of all, there is hardly any advantage left of the 120GB HDD with 8MB cache-buffer over the drive with 2MB cache-buffer in High-End Disk WinMark. It is even smaller than the measuring error.
Secondly, the performance of SATA HDD with Promise SATA 150 TX2 Plus (WT) controller in High-End Disk WinMark test appeared lower than incase the controller worked in WB mode. It is really strange, because in FAT32 the situation was completely the opposite.
WinBench99 tests let us conclude that SATA hard disk drives demonstrated a really impressive performance boost provided not only by large 8MB cache-buffer. At the same time we wouldn’t claim that the “faster” interface was the only one to praise for the performance improvement: we shouldn’t forget about the influence of the firmware versions.
But anyway, we cannot deny it: SATA HDDs work faster than their ATA predecessors.
The last test set, which we are going to use this time is our favorite FC-Test. If you are not yet familiar with this benchmark, please consult our article called “X-bit labs Presents: FC-Test for Hard Disk Drives”.
The main peculiarity of our HDD file copy testing methodology is the way the files sets on the HDD tested are created and read. We measure how much time it takes to create a certain set of files on the HDD (in other words, we measure the write speed) and to read these files from the drive afterwards (which is the average read speed).
The second important peculiarity is the fact that we do not use any synthetic files sets to test the drives (this could make the task a lot easier). For our tests we use absolutely real files taken from a real PC. That is why we claim that we test the hard disk drives in real conditions. Especially since many of you surely have a folder called Windows or MP3 on the drive :)
The third peculiarity, which is quite unpleasant, unfortunately, is the fact that our test uses operation system calls that is why the results are very dependent on the OS status at the time you run the test (paging file content, disk cache status, etc.). We can ensure more stable results by making a paging file of some fixed size and starting the test immediately after Windows restart (of course, only after the startup is complete). Also numerous iterations may also be of some help :)
So, let’s check the HDDs performance, and to be more exact, the performance of several HDD + controller combinations in FAT32:
All results in MB/sec are summed up in this table. The diagrams below will make the analysis more illustrative:
As we see, with smaller files (Windows and Programs patterns) all HDDs perform equally fast. But as soon as the average file size grows bigger than the cache buffer of some hard disk drives (the average files size in MP3 pattern is 3.65MB), the beautiful ordered picture disappears immediately…
SATA hard disk drive with Promise SATA 150 TX2 Plus (WB) controller takes the lead, and two SATA drives of different storage capacities, namely 120GB and 80GB, with SiliconImage controller follow closely behind the leader. And just a tiny bit behind we find an 80GB SATA drive with Promise SATA 150 TX2 Plus (WT) controller.
Note that the best result shown by an ATA HDD is still over 20% worse that the worst result shown by a SATA HDD. Moreover, this best result among ATA drives belongs to a 120GB HDD with 2MB cache-buffer. It is all natural that it outperformed the 80GB drive, because the 120GB model has a bigger cylinder and hence can write a bigger data block per single pass. But how come that the solution with an 8MB cache-buffer fell so far behind? No clue…By the way, the results obtained in FC-Test contradict the results obtained in HDTach: which test to you personally trust more then? :)
In the ISO pattern the leading positions get occupied by SATA drives with SiliconImage controller and the performance of a SATA HDD with Promise SATA 150 TX2 Plus controller appears absolutely independent of the requests caching mode. It is interesting that ATA HDD with 120GB storage capacity and 2MB cache-buffer is still much faster than its counterpart with 8MB cache-buffer.
And in Install pattern (the average file size is 1.4MB), the initiative again goes to a SATA drive with Promise SATA 150 TX2 Plus (WB) controller. It manages to get about 2.5MB/sec (10%) ahead of the closest rival.
Well, writes seem to be much better performed by SATA HDDs. And what about reads?
And when reading, the SATA drives no longer have any advantage over their ATA analogues. The only combination, which managed to show a noticeably different result is a SATA drive tested with Promise SATA 150 TX2 Plus (WB) controller. Although this time the influence is just the opposite: we saw performance improvement with writes and here we see a significant performance drop! What’s the matter? Could it be high CPU workload that limits the performance of the disk subsystem? Or maybe the WB algorithms of the controller get in conflict with the read ahead algorithms of the hard disk drive? To tell the truth, we have no definite answer yet…
Well, now that we have already checked the read and write speeds, let’s combine these two modes. We are about to start the actual copy tests.
Just in case let me remind you that for FC-Test the HDD tested should be formatted as two logical drives of equal size and the copy tests will be carried out within one logical drive as well as between the two logical drives.
At first we are going to copy the preliminarily created file set within the same logical drive:
A quick look at all this mess pushed us to make a few comments. Firstly, SiliconImage controller is a definite winner here: it showed the best performance for all file sets.
Secondly, WB-caching seems to make sense during copy operations. And thirdly, an ATA drive with 8MB cache-buffer has finally shown its real power. Do you see the tremendous difference between the results shown by the same 120GB models differing only in the cache-buffer size? I assume this is very convincing evidence of the large cache-buffer advantages.
When we copied file sets from one logical drive to another (the heads have to be moved to longer distances than in the previous tests), the situation remained almost the same. The only thin worth mentioning is the improvement of SATA-drive’s performance with Promise SATA 150 TX2 Plus controller working in WB mode.
Again the ATA-drive with 8MB cache-buffer is much faster than its brother with the 2MB cache-buffer.
Well, let’s shift to a different file system. In NTFS the cluster is smaller, which can affect the performance of the CPU-dependent controllers. Anyway, let’s find it out:
As usual, we will start with writing:
At first sight, there are hardly any changes. Just like in FAT32 the fastest is the SATA drive with Promise SATA 150 TX2 Plus (WB) controller. Moreover, with the smaller files it demonstrated a tangible advantage over the rivals.
Reading is also just the same as we saw in FAT32.
Well, when we copied the file sets within one logical drive, the best results were shown by SATA drives with SiliconImage controller. Promise SATA 150 TX2 Plus controller working in WB mode managed to get ahead only when copying smaller files.
If we compare the copy speeds of SATA and ATA HDDs, we will see that there is only one model, ST3120024A with 8MB cache-buffer that can become a worthy competitor to the newcomers. The regular ATA hard drives with 2MB cache-buffer unfortunately proved 1.5 times slower.
When we copied the files to the second logical drive WB-caching again helps Promise controller to beat SiliconImage in three patterns out of five.
Since our review was supposed to answer two questions: “Are SerialATA hard disk drives faster than their ATA predecessors?” and “Which SerialATA controller provides the best performance today?” we will draw our conclusions in two parts as well.
The first acquaintance with SerialATA interface and the products supporting it didn’t prepare any unpleasant surprises for us. All hardware units worked very stable and fast. So, we are sure that waiting for the first SerialATA products for such a long time was not in vain: the customers will definitely get not beta-versions of the HDDs and controller cards but very thoroughly tested and debugged solutions (from what we hear Seagate Barracuda SATA V HDD with 3.01 firmware are already available in retail).
And the absence of problems is very important when the new generation comes. If some problems arise when the new product is just coming into the market, then the conservative users may get too discouraged to buy it. And if there is no demand, then the company will hardly dare push the supply (the only exception is Intel, because this company is almost a monopolist today).
Congratulations to Seagate Company, which appeared the first one to enter this market and really succeeded with their SerialATA products. Seagate SATA drives proved faster than their predecessors and their production cost will hardly be much higher. Of course, we understand that these are the first drives in this market niche and they are also a kind of transitional product. But despite this fact, we have clearly seen that the contemporary hard disk drives really do need a faster bus. Not to mention the next generation HDDs with native command queuing support and other features provided by SerialATA.
The SerialATA controllers are also worth talking about. We introduced to you two SATA controllers in this review, which are most likely to become very widely spread in the nearest future. The controller manufacturers are very well-known to us: they are Promise Technology and SiliconImage. The products reviewed today have their highs and lows, but in general they both deserve your attention.
SiliconImage controller proved quite fast in all tests, but its trump appeared “desktop” applications. We would also like to stress stably high performance in all copy tests.
Promise controller on the contrary didn’t manage to conceal its server origin. This is probably the reason why there was no optimization for Winbench tests. However, a few very interesting technologies implemented in it and very remarkable drivers helped Promise SATA 150 TX2 Plus to perform really great, and when some optimization didn’t work, another one immediately came to rescue. The only thing that upsets me about testing Promise controller is the fact that my testbed seems to have become too outdated for contemporary HDDs and controllers. Time to upgrade :)
And in conclusion I have to say that my concerns about Promise SATA 150 TX2 Plus being slower because of a Marvel SATA<->ATA converter didn’t prove justified. The results showed that the integrated converter didn’t affect the average access time as well as the overall controller performance in any benchmark.
And a few words about some global matters. The first products have already appeared. It means that very soon the SerialATA products will start streaming down like from a horn of plenty. Is it good? Well, and is there anything bad about it? We haven’t discovered any drawbacks of SATA drives and they proved not any harder top use than the regular ATA HDDs. The price of the new SATA products is certainly a little higher now, but as the new products will be coming out it will definitely go down to an acceptable level. Therefore, I strongly recommend all of you who are about to assemble a new PC, do not make a mistake when choosing the interface.
Bis dat, qui cito dat
"those who give quickly, give twice as much"
We would like to sincerely thank Seagate Company for the opportunity to test Seagate Barracuda SATA V, Promise Technology Company for SATA 150 TX2 Plus and SATA 150 TX4 controllers, and SiliconImage Company for Sil CP3112SATA150 controller.