by Nikita Nikolaichev
10/16/2003 | 08:56 PM
In this article we are going to take a really close look at the features and performance of the new Fujitsu hard disk drive aka MAS3735NP. This particular eldest model in the family is going to represent the MAS product line in our today’s review. MAS HDDs family is the second generation of hard disk drives from Fujitsu featuring 15,000rpm spindle rotation speed. The previous model of the 15K Fujitsu drive has already made a very good impression in our test session in the year 2001 (see our Hard Disk Drives in 2001: Annual Overview). So what surprises has Fujitsu prepared for us this time?
Two major innovations in the MAS family are the use of 18GB platters and U320 SCSI protocol support. As you already know, MAM HDDs were based on 9GB platters and supported only U160 SCSI. Which never prevented them from being really fast for their time.
The cache-buffer of MAS drives in 8MB big, i.e. it remained of the same size as the cache buffer of the previous generation models. Also, Fujitsu doesn’t offer any 15K HDDs with FibreChannel interface still: only the standard SCA-2 (the last two letters of the marking are “NC”) and 68-pin Wide (the last two letters of the marking are “NP”) SCSI drives.
Here it is, our today’s main character:
The looks is very familiar, don’t you think so? :)
The table below contains the brief MAS drives specifications:
As you see, there are three models in the MAS HDD family: single-, dual- and four-platter hard disk drives of pretty standard storage capacities equal to 18GB, 36.7GB and 73GB respectively.
If we compare the average seek time claimed by the manufacturer for its MAS HDDs with the specifications for Fujitsu MAM drive, we will notice that the new generation drives should be somewhat faster, because their claimed average seek time is 0.2ms shorter. Well, the doubling of the per platter data density seems to have positive effect not only on the linear read speed increase, but also on the random sector access time.
Our testbed was configured as follows:
To connect the hard disk drives we used Adaptec 29160N controller card with BIOS version 3.10.0 and drivers version 4.10.4002 and Adaptec 39320D controller card with BIOS version 4.10.1 (HOST RAID disabled) and drivers version 1.0 and 1.1 (we have already discussed the performance differences provided by the two driver versions, v.1.1 and v.1.0 in our article called: Ultra320 SCSI Interface: Highs and Lows. Part II).
The reviewed drive had the following firmware version: Fujitsu MAS3735NP FW - 0102.
We used the following benchmarking software:
For WinBench tests the arrays were formatted in FAT32 and NTFS as one partition with the default cluster size. The WinBench tests were run five times each; the average result was taken for further analysis. The HDD didn't cool down between the tests.
To compare the hard disk drives performance in Intel IOMeter we used the FileServer and WebServer patterns from StorageReview described in the third edition of their HDD testing methodology.
These patterns are intended to measure the disk subsystem performance under workloads typical of file- and web-servers.
Our colleague, Sergey Romanov aka GreY, developed a WorkStation pattern for Intel IOMeter basing on the StorageReveiw's study of the disk subsystem workload in ordinary Windows applications. The pattern was based on the average IPEAK statistics StorageReview provided for Office, High-End and Bootup work modes in NTFS5 file system and mentioned in Testbed3 description.
The pattern serves to determine the attractiveness of the HDDs for an ordinary Windows user.
Well, and in the end we checked the ability of the drives to work with sequential write and read requests of variable size, and tested the drive’s performance in DataBase pattern, which imitates the work of the disk subsystem with SQL-like requests.
Well, we will start with the DataBase IOMeter pattern. Why with this particular test, you will ask? The reason is its excellent ability to reveal the peculiarities of the HDDs firmware, such as tagged command queuing, efficient lazy writing, etc.
At first let’s check the scalability of the Adaptec 29160N + Fujitsu MAS3735NP combination depending on the queue depth. For this purpose we will show on one picture the performance graphs for processing requests with different reads/writes share under five types of workload, which were obtained with Adaptec 29160N controller card.
You can clearly see that the dependence of the requests processing speed on the queue depth is not linear! At first the results jump up, however, under heavy workloads the performance boost is not that great any more, even though the requests queue depth keeps increasing in geometric sequence.
As we have already pointed out in our article called Ultra320 SCSI Interface: Highs and Lows. Part II, the SCSI controller drivers have two parameters, which has a direct influence on the HDD performance. They are MAXTAGS and NumberOfRequests. The first parameter determines the size of the requests pack, which can be transferred to the hard disk drive for further processing. Within this pack the HDD can change the order of requests processing. The second parameter is the maximum number of requests, which can be sent to s SCSI controller. By the way, when I am talking about the requests queue depth during the discussion of the benchmarks results, I imply the requests queue going into the controller (I cannot address any requests to the HDD directly, I cannot avoid the controller here).
So, what do we see on the diagram? While the requests queue depth going into the controller is smaller than the maximum TCQ depth supported by the drive, any increase in the workload results into a significant performance boost. Well, this is absolutely correct, because the larger is the requests pack sent to the HDD by the controller, the more opportunities it has to re-arrange these requests into the optimal queue from the performance point of view. When the requests queue exceeds the size of its internal buffer, the performance can still increase only if the controller driver does all the sorting and rearranging itself, before sending the requests to the HDD. In other words, if the controller driver creates the “optimal” N-request queues for the drive, where N=MAXTAGS. Since the controller is unfamiliar with the internal geometry of the HDD, the requests queue optimization performed by the controller is significantly slower than the requests optimization carried out by the HDD itself. That is why the performance grows “slower” under heavy workloads, because all the opportunities for requests queue optimization have already been used.
Now let’s compare the performance of different SCSI controllers (Adaptec 39320D was tested with two different driver versions):
As you see, Fujitsu MAS3735NP hard disk drive appeared a little faster when working with U160 Adaptec 29160N controller than with the U320 controller. Moreover, driver 1.1 for Adaptec 39320D controller turned out slower than driver 1.0.
Now let’s increase the workload:
And we see that the performance difference between different controllers/driver versions grew even more evident. The maximum performance is again obtained with the Adaptec 29160N controller, and the worst results are shown by our HDD with Adaptec 39320 with driver version 1.1.
Further workload increase makes this parity even more stable.
Fujitsu MAS3735NP achieves the maximum performance with the U160 controller. Does this mean that U160 interface is “faster” than U320? Well, if we evaluate the interface speed according to the performance of a single HDD, then yes, U160 is faster. However, as you see, a lot depends not only on the maximum interface bandwidth but also on the quality of algorithms used in the controller driver (we are not going to go into details regarding the “compatibility” of the drivers and HDD firmware here).
Now let’s pass over to Sequential Reading and Writing.
The situation here is pretty familiar to us already:
When we work with larger data blocks our single hard disk drive performs equally fast with both controllers. And as soon as we shift to smaller data blocks the victory goes over to U160 controller. The driver version for the U320 controller hardly tells on the performance under this type of workload.
The situation repeats with write requests again.
Now let’s check the performance of Fujitsu MAS3735NP in server patterns. As usual we will begin with FileServer:
Note that the performance of our HDD with Adaptec 39320D controller remains unchanged for 64 and 256 outgoing requests and for both driver versions. But this totally contradicts the results obtained by Seagate Cheetah 15K.3 HDD (see our Seagate Cheetah 15K.3 Hard Disk Drive Review)!
Wait, and who told you that Fujitsu hard drive supports the queue depth offered by the controller? If the maximum queue depth, which can be processed by our Fujitsu drive, equals 32 requests, then the controller will have to limit the size of the requests packs sent to the drive to this particular number. And in this case it doesn’t matter what the driver actually supports…
Well, now we have to take a few much more precise measurements, i.e. to increase the workload much slower.
The rating is just a formality, but I still have to do it, to give you a better idea of our today’s testing participant’s performance:
The next thing to look at is the WebServer pattern. Let’s see if anything changes here:
Strange as it might seem, but the changes are evident: the results of our HDD running with the U320 controller and v.1.0 driver caught up with the results of the U160 controller. However, as soon as we install the v.1.1 driver the HDD slows down quite noticeably.
It is interesting, but I have always believed that WebServer pattern is “easier” for the drive, because it has no write requests at all. However, I seem to be mistaken: when it turns out that there are no writes among the incoming requests, the optimization of the requests queue gets much lower, because the firmware cannot perform lazy writing any more.
In WorkStation pattern the maximum workload makes only 32 outgoing requests therefore it would be really interesting to see which controller is preferable for use with Fujitsu MAS3735NP HDD.
The situation seems to be surprising again. Driver version 1.1 for U320 controller took a revenge for the failure in server patterns. Wit this driver our hard disk drive appeared almost as fast as in case of Adaptec 29160N controller.
I would even say it did run exactly as fast :)
The last benchmark we are going to take a look at today is our good old veteran – WinBench99.
I don’t think there is any need to go deep into details regarding the HDD performance in typical office applications. We’d better take a closer look at the performance difference in two integral subtests: Business Disk WinMark and High-End Disk WinMark:
Well, there is hardly any difference at all. :)
And why should it be there, actually? We have just seen that under small workloads the HDD performed equally fast with both controllers. But there is still something really exciting about the WinBench99 results. It is the linear read graph. Have a look here:
Wow, it seems to me I haven’t seen such beautiful graphs for a long time already. Note that at almost half of the entire surface the linear read speed (which also means the number of sectors per track) remains unchanged and sticks close to 80MB/s (to be more exact to 78.8MB/s).
To tell the truth, this seems to be the hardest part for me to write today. at first I was going to make a “Contemporary 15K HDDs comparison” and then to add the results for Fujitsu MAS and Maxtor Atlas 15K. However, during work I realized that this is going to become a separate serious article.
So, today I introduced to you a new Fujitsu MAS hard disk drive family, gave you an idea about the drives’ features and performance. The benchmarks results for Fujitsu MAS3735NP drive showed that the new generation of 15K Fujitsu HDDs has everything required by the today’s market. And how good it is against the background of its competitors, will be very soon discussed in our upcoming roundup.