by Sergey Romanov , Nikita Nikolaichev
01/12/2004 | 11:58 PM
We have already devoted two reviews to IBM/Hitachi hard disk drives on our web-site, and in two more articles they participated as “mutes”. Nevertheless, we collected twice as mach information about the drive as we have already shared with you, and there is still a lot of exciting stuff left behind. However, it is not about the amount of data, but the extraordinary character of this data that attracts us most and that pushed us to continuing the investigation about one of the most exciting products in the hard disk drive market. If you are interested in HDDs in general, and are curious about IBM (now Hitachi) in particular, then you should enjoy reading this article a lot.
The thing is that 180GXP HDD family appeared an unusual, maybe even mysterious, and conceptual. Deskstar 180GXP should be replaced with Deskstar 7k250, but we have every evidence proving that this new Hitachi solution will inherit a lot from the predecessor. And this predecessor appeared not that simple at all: the number of outstanding peculiarities, which we have already discovered, exceeds all possible (read common) limits. But we will return to this matter later today :)
There is one more reason why we decided to continue working on this material. Our old testbed based on Intel Pentium III 600E has long deserved a retirement that is why we tested all the latest hard disk drives on two test platforms. Finally, the database of benchmark results, which we have obtained using new testing methodology and new test system, has grown big enough for the old testbed to be finally retire. In the pervious article we kind of introduced a new testbed to you, and the current review is going to be a sort of a farewell article: farewell to the good old testbed and the hard disk drive solutions from the Blue Giant.
The history of hard disk drives is about half a century old already and IBM brand name is a definite legend of this history, no doubt. We owe the era of personal computers in general and hard disk drives in particular to this great company. This way, the very first floppy drive was developed by IBM in 1956 and was called RAMAC (Random Access Method of Accounting and Control). They first implemented an aerodynamic actuator for the read/write heads in IBM 1302 drive (in 1962). The voice coil has been first implemented in IBM 2310 in 1965, and in 1971 IBM introduced its track following servo in the 3330 model. The IBM 3340 announced in 1973 is the one that gave birth to the term “Winchester”, which has become a common name by now. In 1975 they launched IBM 62GV equipped with the world’s first swing-arm heads actuator, which has also become an inalienable part of the contemporary “Winchesters”. In 1979 IBM 3370 appeared the first hard drive to boast thin-film magnetic heads and special methods for un-length-limited (RLL) coding scheme and IBM 62PC turned out the first drive with “non-floppy” magnetic hard discs.
This way, thanks to IBM engineers by 1980 the floppy drives featured practically the same specifications as the contemporary hard drives, differing only by considerably bigger size. And only in 1980 IBM first time faced a serious competition from Seagate Technology Company (established by Al Shugart, who used to work in the same IBM in the 60s), which entered the market with the first small floppy-drive aka ST506. In the 80s many other companies joined the competition, although you hardly know some of them today. However, the inventiveness of Fujitsu, Rodime, Control Data, Maxtor, Hitachi, Quantum, Conner was not enough to outshine IBM’s engineering geniuses.
In 1990 IBM introduced in its hard disk drives the so called PRML signal processing technology (Partial Response Maximum Likehood), and in 1991 they first used magnetoresistive heads. These two technologies allowed increasing the data density and read/write tract bandwidth quite tangibly. The same year they discovered GMR (Giant Magneto-Resistance) effect in the labs. This innovation used for read heads allowed IBM to overcome another barrier in data density increase. IBM Deskstar 16GP hard drives introduced in 1997 were the first to feature GMR heads. All these technologies were open and many HDD manufacturers eagerly licensed them from IBM. Therefore, we owe the active growth of the HDD storage capacity, which has even exceeded the famous Moore’s law, solely to the IBM Corporation.
But there is nothing eternal in this world. No matter how sad it is we will never see new hard disk drives from the Blue Giant (at least during the next few years). Starting January 2003 its entire hard disk drive business including the development, manufacture, sales and technical support has been handed over to Hitachi Corporation (see this document for details). For this purpose, Hitachi has even established a new Hitachi Global Storage Technologies division. I do not want to speculate on the reasons behind this transition, but this is an undeniable fact and there is nothing we can do about it. Now let’s just take a glance at the entire history of the pioneer known as International Business Machines and take off our hats in silence.
During the last couple of years IBM started to fall behind the rivals in the eternal “armaments race”, being the very last of all hard disk drive manufacturers to increase the data density. However, a great lot of different small peculiarities, inevitably made its products the fastest among the competitors of the same weight category. However, this time the situation got somewhat different: all manufacturers announced their HDDs with 60GB per platter data density in September 2002. Since there had already appeared numerous announcements about IBM going to close its HDD business, the launch of Deskstar 180GXP turned out quite a surprise (I would like to mention that the whole press-release sounds highly pathetic, I strongly recommend taking a look at it :)). Well, we really like pleasant surprises like that :)
Now our primary goal is to find out how great the last IBM product actually is.
The new product family appeared pretty big and included the models with the following storage capacities: 30GB, 40GB, 60GB, 80GB, 120GB and 180GB. Besides the increase of the maximum storage capacity by 1.5 times, IBM also claimed that its HDDs ran 25% faster than the predecessors. However, the internal project name – Vancouver 2 – doesn’t give us much hope for significant improvements compared to 120GXP aka Vancouver.
Among the changes made to the new product family we have to point out the use of fluid dynamic bearings instead of the IBM’s traditional ceramic ones, and the use of classical aluminum platters instead of the glass ones. The top models acquired a larger 8MB buffer. Since the maximum HDD storage capacity has exceeded 128GB, they acquired 48bit addressing, which appeared in the ATA/ATAPI-6 standard, however Ultra DMA/100 still remained the fastest data transfer protocol. Also the new hard drives were said to support “Tag ’n seek” technology, which was expected to ensure about 20% performance boost compared with the competitors’ products.
The official documents say that “IBM's performance-enhancing technology - "tag 'n seek" - is a method of controlling commands sent from the host processor to the hard drive, enabling faster application activities for the end user. "Tag 'n seek" tags each command that arrives at the drive's buffer with an identifier, then reorders and processes the commands in the most efficient manner.” No more details have been revealed that is why we have to finish the logical chain ourselves :). In fact, “Tag ‘n seek” is just a commercial name for Tagged Command Queuing technology.
For better understanding of the idea behind this innovation, we have to imagine how the disk input/output system of the PC actually works. Suppose, a program on your computer needs to read some data from the disk drive. The disk subsystem sends a command to the HDD to read the data via the DMA protocol, alongside with the address and size of the requested data block. The HDD needs a certain amount of time to complete the reading of these data, when the system can actually do whatever, though the communication channel to the HDD remains busy and it is impossible to use for contacting any other devices in the system. As soon as the reading is over, this causes an interruption informing the system that the operation has been completed. Then the channel is ready for further work.
An evident drawback of this algorithm is the fact that ATA-channel and maybe also the input-output bus are always highly loaded. To get the data from the platter the HDD needs to select one of the heads (if there is more than one), move the heads block to the desired cylinder, wait for the platters to move with the required sector facing the heads and then read the data.
All these operations usually take from a few tenths of milliseconds up to a few tens of milliseconds in case of sequential reading. This way, the HDD communication channel is kept busy for nothing most of the time. What is bad about it? If there is only one HDD connected to this channel, then it is OK. And if there are any other devices connected to the came cable, they will be slowed down significantly.
They have already found a solution to this problem in SCSI protocol. The main idea implies that they split the data request and data reception phases. As soon as the command has been sent to the device, the connection with this device is terminated until the interruption signal arrives. After that the system checks with all devices requesting the information about the fulfilled command. This way, it is possible to set tasks to a few parallel devices at a time, or to set multiple tasks to one and the same device. In this case the read and write requests are lined up inside the HDD and are processed concurrently: first the HDD processes those, which will take less time to be completed. This mode is called Tag Queued.
A similar technology in IDE drives is implemented with the help of additional Read/Write DMA Queued commands, which have been added to ATA/ATAPI-4 standard within the implementation of Command Queuing and Overlapping. They differ from the regular reads and writes by the identification label assigned to each command. This label helps inform the computer which particular command of the received ones has been performed successfully. The label can equal any integer from 0 to 31, which means that a HDD can “digest” up to 32 commands at a time. This way we can greatly optimize the heads positioning routs thus increasing the overall HDD performance.
Since all contemporary HDDs feature lazy write function, the efficiency of TCQ (Tagged Command Queuing) for writes is quite doubtful. However, when it comes to reading, TCQ should give second wind to the drives. Moreover, we should see a twofold improvement when we have two HDDs connected to a single cable. Of course, if you want to see the real effect made by the specifically queued commands, the HDD should be loaded with two or more simultaneous requests, which is not common for desktop systems. However, in the server field TCQ may become highly valuable for enhancing the disk subsystem performance.
For “Tag ‘n seek” to work properly, its implementation in the hard disk drive is not enough. The OS should also support R/W DMA QUEUED, i.e. at least the IDE Busmaster drivers should be updated. HighPoint Technologies has these drivers, and maybe so do some other chip makers. We are going to devote a separate article to this matter later on, so stay tuned :)
Before we pass over to the specifications comparison of the two latest Deskstar generations, I would like to tell you a mystical story about IBM’s behind-the-scenes game. The thing is that 180GXP announced in September and its today’s version differ from one another. Firstly, the specifications now list additional 40GB models marked as (sic!) IC35L060AVV2 40GB. Why “models” in the plural? Well, because there are two of them, and we can only guess what is the sacral idea behind this dualism. :) Anyway, there is a regular 40GB solution and its “optimized” version, though there is no mention at all about the details of this optimization. Thanks goodness they listed the specifications of the two, so that we could somehow figure out the changes that have been made:
I suspect that the non-optimized version is the already familiar cut-down product with a few density zones that have been disabled. However, cutting off one third of the storage capacity will inevitably lead to significant decrease of the average access time. This situation threatened to ruin the hierarchy in the product line that is why they decided to give up the densest cylinders and “thin out” the tracks. As a result, the per-track density in the optimized model has been reduced from 76 to 72 thousand per inch. Stop, how is that possible?
The previous specification version has never heard of 76 ktpi data density; all models features 72 ktpi density. If this is not just a misprint in the product description (which is hardly possible, because the total data density has also mysteriously increased from 45.5 to 46.3GB/sq.inch), then the whole thing appears extremely interesting. After the mass production of Deskstar 180GXP had been started, the engineers found a way to increase the per-track density by another 5%. At the same time they had to start producing 40GB models, that is why all newly manufactured platters with lower data density per track were used for the 40GB models manufacturing. This way, it becomes absolutely clear where the pretty big idle part of the platter in a 180GB model comes from (see our article called Western Digital WD2500JB HDD: More than Drivezilla?!, where we mentioned this fact): the tracks became somewhat denser.
As you remember, we discovered an unusually wide circle on the external “fastest” part of the platter, which was not used for data storage. If they had utilized this area too, they could have got 66GB platter capacity instead of 60GB and design a 200GB model (Maxtor and Western Digital seen to have done exactly what I am talking about, unfortunately, these companies keep silent about the number of cylinders in their solutions). Why did IBM decide to sacrifice maximum linear speed and storage capacity? Maybe it is the limited capabilities of the existing GMR heads or the insufficient bandwidth of the DSP read/write channels.
Taking into account everything we have just said, and keeping in mind that the previous Deskstar 120GXP HDD generation included similar models with lower per-track data density, it makes sense to compare both modifications:
You see that the new model with 40GB storage capacity came to replace the IC35L040AVVN: the same case, the data transfer rate remained almost unchanged, although the data seek time grew up a lot. Let’s continue comparing:
The specs promise us 17% linear speed growth, which strikes as very strange keeping in mind that the physical (momentary) speed and the number of sectors per track grew up by only 11%. However, there is an explanation to this phenomenon: the track and heads switch time got notably reduced. You probably wonder how the track switch time affects the sequential read speed? I will try to explain it now.
Look at the Sectors per track parameter in the table, which indicates the maximum number of sectors per track. For 180GXP this density value equals 1092 sectors, which is a little over half a megabyte of data. If the HDD can read the first half megabyte at the maximum speed, then after that it will need to switch to another head or maybe even move to the next track. The time it spent on these operations is included into the overall sequential read time thus reducing the “linear” (or sustained) speed. The ongoing formula has been taken from IBM documentation:
(Sustained Transfer Rate) = A / (B+C+D)
where:
A = (Number of data sectors per cylinder) * 512
B = ((# of Surface per cylinder) - 1) * (Head switch time)
C = (Cylinder change time)
D = (# of Surface) * (One revolution time)
As you see, the track switch time directly affects the linear read speed. And the successful attempt of IBM engineers to reduce this time by 1/3 could have been called another brilliant breakthrough, if it hadn’t been for one thing…
Having checked the specifications of the previous IBM HDDs, starting from DTLA, I was surprised to find out that Head and Sector Switch Time had been constantly growing in every new model:
With every new generation IBM has been increasing the Head and Cylinder Switch Time, and then in the very last generation it got much shorter for some reason. We wonder why? Maybe it has finally become possible due to “new” platters? We are very unlikely to find an exact answer to this question, however, the claimed error robustness proves our supposition that the platters have something to do with this.
Any media is characterized by the parameter specified as “non-recoverable bit read errors probability”. For hard disk drives it usually equals 1E-10. This probability is reduced down to the value when the stored data is considered safe. This is done by storing Error Code Correct (ECC). So, despite the decreasing number of ECC symbols, the probability of the non-recoverable error in Deskstar 180GXP got much smaller, which can be achieved only due to more stable reading from the platters. As a result, aluminum platters seem to have turned out more reliable than the glass ones, don’t they? By the way, all other hard disk drive manufacturers claim that their non-recoverable error probability has long reached 1E-14, which IBM obtained only in its latest products. At the same time, most manufacturers do not resort to ECC symbols interleaving, when a part of the correction code for one sector is located among the ECC-symbols for the other sector. Frankly speaking, this approach is implemented only in IBM/Hitachi HDDs and those from … Samsung. It seems to be exactly thanks to interleaving that IBM HDDs managed to provide acceptable reliability. At least I personally have seen products, which were reading the data impeccably but extremely slowly. :)
Another surprise popped up when we analyzed the read buffer segmentation. They claimed that their drives feature quite a lot of segments (21 segment is a pretty big number, I should say). However, the tests showed that only the models with 8MB buffer feature that many of them (these models are marked with “-1” in the end, like IC35L120AVV207-1). The models with a 2MB buffer feature only 8 segments, while the HDDs from 120GXP family and the older models really have as many segments as the specs claim: 12. It is exactly the well-done buffer segmentation that is mostly responsible for traditionally high performance of the IBM drives. For a better comparison: Seagate Barracuda IV (and the ongoing models) do not allow simultaneous reading of the two data streams, and Quantum supported up to 8 streams at a time. This way, we can expect younger Deskstar 180GXP models to be even slower than those from the 120GXP family.
Moreover, IBM is not quite honest about the “innovative” Tag ‘n seek technology TCQ first appeared in Deskstar 75GXP that is why I personally doubt that we will see a 25% performance increase of the 180GXP compared with the previous HDD generation.
Among the peculiarities of the Vancouver 2 hard disk drives we should also mention the existence of two different HDDs within the same family. The youngest models (with 30, 40 and 60GB storage capacity) are based on the AVVN design, which implies different case construction and slower data seek. The models with 80, 120 and 180GB storage capacity feature a more common case design, are equipped with a more powerful actuator reducing the average access time.
Vancouver 2 LP and Vancouver 2
In our today’s test session there will be 5 models from the IBM Deskstar 180GXP HDD family and for a more illustrative comparison we will also add the results for a solution from the previous generation 120GXP family. As usual, we will use simpler and shorter names for the testing participants in our diagrams and tables:
If you studied the table above carefully enough, you should have noticed that the IC35L060AVV207-0 model is mentioned twice. This is not a mistake: the 40GB 180GXP HDD was marked exactly like that (check this photo to see what I am talking about).
Our test system was configured as follows:
We used the following benchmarking software:
All drives that support “quiet seek/normal seek” operation modes were switched to the fast mode by means of Hitachi Feature Tool. For WinBench tests, the drives were formatted in FAT32 and NTFS as a single partition with a default cluster size. We used Paragon Partition Manager for FAT32 formatting. The benchmarks were run seven times each; the maximum result was taken for further analysis. The HDDs didn’t cool down between the tests. The tests in Intel IOMeter were run in SequentialRead, SequentialWrite, DataBase, WorkStation, FileServer and WebServer patterns.
These patterns are intended to measure the disk subsystem performance under workloads typical of file- and web-servers.
WorkStation pattern for Intel IOMeter was developed 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.
We will use this pattern for evaluating HDDs efficiency during intensive professional work in Windows.
One of the most important characteristics of a hard disk drive is average access time. The specifications did not indicate any difference between 180GXP and the previous generation models. However, how do the things stand in reality?
In reality the situation is completely different. We got a plenty of surprises:
Probably, it is the different firmware versions that caused different lazy write efficiency: all hard disk drives participating in our today’s race were tested within different timeframe, so that by the end we finished testing the firmware version has already increased up to 6th. Unfortunately, we didn’t check the firmware version of all tested models, nevertheless, we have a few numbers for your reference. The 40GB, 80GB and 180GB models featured A63A firmware, and the 120GB model with an 8MB buffer – A66A firmware. The first model to be tested was the 60GB one that is why it should have the oldest firmware. We see that the first firmware versions for 180GXP boasted almost the lazy write efficiency as the 120GXP solutions.
The mysterious 40GB HDD model, which was first absent in the 180GXP family and then most likely appeared because of some IBM’s OEM customer, prepared the most surprises for us. To begin with, it is not just a 60GB HDD cut down to 40GB in storage space, as you might have thought at first, but an independent product, although the system recognizes it as IC35L060AVV2 40GB, and so says the sticker. The “optimized” model has a modified zones layout instead of the traditional absence of the smallest internal cylinders. Although this is still a “cut-down” model in terms of the overall cylinders amount, with both: external densest tracks and internal slowest tracks sacrificed. As a result, it boasts pretty short average access time, despite the low-cost case typical of the youngest models with slow seek. Only this model and the “cut-down” 80GB one can compete with the previous Deskstar generation in average access time. And this means that 180GXP can’t boast IBM’s traditionally high seek time any more. In fact, this is very weird, as the specifications do not indicate any worsening of the seek time parameter.
Like in case of WD2500JB (see our article called Western Digital WD2500JB HDD: More than Drivezilla?!), the answer to this puzzle lies with the number of servo-marks per track. The thing is that when the heads are moved to a new position, the HDD checks the trajectory on the layout with the help of the passing-by servo-marks. The more servo-marks are on a single track and the faster the rotation speed is, the earlier the electronics will find out if the desired track has been reached. WD2500 had 20% servo-marks than WD2000, while the number of cylinders grew up by less than 17%.
In Deskstar 180GXP IBM cared mostly about high linear speed, thus having increased the amount of servo-marks per track by only 10%, while the number of cylinders grew 27% bigger compared to 120GXP family. Of course, this couldn’t help telling on the average access time. So, it is not only the spindle rotation speed and average seek time that influence to time it takes the HDD to find the requested data. A little later today we are going to find out how all these things will tell on the HDDs performance in real tests.
And now let’s check the linear speeds of our testing participants during reading/writing of data blocks of various sizes:
The performance of 80GB and 180GB models appeared almost equal to that of 120GB/8MB model that is why we didn’t show them on the diagram. As you may see, single-platter modifications perform slower in case of small data blocks compared with the other models in the family. We double-checked the results many times with different HDD samples (we tested 4 of them all in all) and in different moments of time. We cannot find any other explanation besides the fact that the engineers slowed down the youngest models on purpose. 8MB buffer hardly affects the results here, although it does have certain influence: see the small “hump” around the 4KB data blocks area. Keeping in mind that in NTFS the cluster is mostly equal to 4KB, this is very good news.
During writes the situation becomes much more complicated. Single-platter models are still slower when processing small data blocks. 180GB model starts neck and neck with the 80GB one and both 120GB ones, however, as soon as the data block size exceeds 16KB, our hero immediately slows down to the level of a 40GB solution with slower platters. Here we can recall that this HDD performed the slowest of all during random writing… Strange, really… Unfortunately, we had only one chance to play with a 180GB model and didn’t have the opportunity to run the tests anew, to make sure.
Although… Not so long ago we tested Barracuda 7200.7 hard disk drives (see our article called Seagate Barracuda 7200.7 Hard Disk Drive Family) and discovered that the top models with ATA interface demonstrated absolutely the same linear speed drop. I cannot believe that LBA48 addressing can tell on the HDD performance like that!
In real workload-emulating patterns everything proved up to our expectations: the average access time determines all results here. The HDDs didn’t show very diverse results (that is why we didn’t include the results for DataBase pattern where we simply got a bunch of identical curves) and their ratings also appeared pretty predictable.
Only the 80GB model from the 180GXP family manages to outperform the previous IBM HDDs generation due to the “cut-down” platters used in this solution. The 40GB 180GXP model runs as fast as 120GXP, also due to the partial use of the platter surface. The fastest model within the 180GXP family is only 10% faster than the slowest one.
60GB HDD with the biggest access time falls significantly behind the others. Strange as it might seem, but IBM hard drives with 8MB buffer appeared a little slower than their classical fellows. Of course, this difference does not depend on the buffer size. For some reason all the drives that acquire larger buffer usually get a slightly worse access time (this is true for the drives of all HDD makers except Seagate). Anyway, a performance difference of less than 1% can and should be neglected.
In WebServer pattern without any writes at all, the drives proved even more unanimous. Like in the previous case, the leader is the 120GXP representative due to its better functioning under high workloads. Old firmware version of the 60GB 180GXP model is scaled according to the workload just the same way as the 120GXP solution does, while the newer firmware versions appear less “hard-working” here. However, it will not affect the performance, as even in case of a heavily loaded server the amount of simultaneous requests will hardly ever exceed 16.
The results obtained in WinBench99 caused us a lot of troubles this time, because in some cases we got a really big discrepancy. Here you go:
However, we still managed to get a clear picture of the 180GXP HDDs performance by repeating the tests multiple times:
In general, the situation in both file systems looks as follows:
If you have read our Seagate Barracuda 7200.7 HDD Family Review, you should remember that there are a few subtests within High-End WinMark benchmark, which depend greatly on the linear speed. We also know that linear speed in 180GXP has got significantly higher. So, why doesn’t 120GXP lose then? Let’s take a glance at some results of these subtests:
It turns out that 120GXP is 8% faster than its successor in NTFS tests working with video, and 180GXP boasts an 8% advantage over the predecessor only in Photoshop. Witnessing the worst defeat of 180GXP in FrontPage we can state that Vancouver2 is no longer so great in NTFS, as its predecessor used to be, while in FAT32 they retain the parity. Anyway, vancouver2 acquired one very useful feature: larger buffer. I wonder how greatly it will improve the situation now?
In different situations we see from5% to 25% performance boost, however, large buffer doesn’t matter that much for NTFS as it does for FAT32. No doubt, that 180GXP and NTFS are far not the best combination today. There used to be a time when NTFS was WD’s kingdom. Then IBM ousted the competitor from there. And now IBM is leaving the conquered territory. Or it isn’t? We will be able to answer this question when we get the chance to test a new solution from Hitachi, the inheritor of IBM’s HDD business.
But wait, there is still a lot of great stuff left for you :) Have a look at the results obtained for 80GB model tested with two different firmware versions :) maybe the new version will perform better in NTFS, who knows?
The wonder happened and didn’t happen at the same time. To be more exact, we expected quite another thing. All in all, the results in NTFS improved a little bit. Moreover, the biggest improvement occurred exactly where Deskstar 180GXP suffered the worst defeat from 120GXP: in AVS: Express. But look how greatly the Sound Forge results grew in FAT32! As you know this benchmark is very sensitive to lazy writing efficiency and here the model with a 2MB buffer outpaces its counterparts with a large 8MB one! It is even more exciting as the 120GB model features the same firmware version: A66A… Unbelievable…
By the way, according to our observations, in the new firmware version the read buffer segmentation has been brought back to the common 12 segments.
In conclusion we would like to discuss the performance of our testing participants in FC-Test benchmark:
It is not at all surprising that the models with 8MB buffer take the lead in writing: larger buffer ensures an advantage of 17% for them. It is interesting that the previous generation didn’t turn into outsiders in this test. Remembering about some problems the 180GB model had with writes in Intel IOMeter tests, we do not get surprised when we see it losing to the 120GB model. However, it has no problems outperforming HDDs with smaller buffer. Anyway, large buffer is most important for writing. And in IBM’s implementation it is equally efficient for writing small files as well as large ones, which we didn’t see by other HDD manufacturers. It is probably the enhanced brand name algorithms that work this way. :)
Reading also brings us no surprises: HDDs with lower physical speed fall behind. It was pretty interesting to see the HDDs with large buffer perform better when reading small files. As we have already pointed out during the discussion of Intel IOMeter tests, they read 4KB data blocks typical of NTFS a little faster. By the way, in FAT32 the leadership belongs to 120GB 180GXP hard drive with 2MB buffer.
When we copy files within a single FAT32 partition, the solutions with 8MB buffer get about 20% faster than the rest of the testing participants. 120GXP HDD yields a little bit to 180GXP and again manages to stay far from the last positions. And in NTFS the competition was very tense. Again we have every proof that physical speed doesn’t matter for real tasks, and a lot depends on firmware algorithms.
When we copy from one partition to another, the models with 8MB buffer boast an advantage of 34%. Of course, it is a little less than 50%+ we saw in case of Seagate Barracuda 7200.7 HDDs, but it is not bad at all, I should say. It solely because IBM algorithms ensure good performance even with a small buffer that is why larger buffer doesn’t make a dramatic sensation.
Today we are not going to talk about the noisiness and the heat dissipation of the Deskstar 180GXP, because this is far not the most important thing in this case. It is much more interesting to talk about the benchmarks results.
There used to be times, when testing hard disk drives was a relatively simple task: get the software, run the tests, write down the results and compare them. In most cases low-level benchmarks, such as linear speed and average access time, provided enough information for performance analysis. However, time passed and extensive development of the “physical” parameters didn’t ensure sufficient performance improvement any more. So the manufacturers started searching for other alternative ways to increase the performance of their products. Namely, they taught the HDDs to spend less time on user’s tasks processing, provided them with more intelligence. I will not go into details describing all the tricks the manufacturers resorted to in this respect. I will only say that they did succeed here and now the HDDs performance depends on the linear speed and seek time least of all. You don’t believe me?
Remember when the noise management system aka AAM appeared. Enabling “quiet” mode for IBM DTLA resulted into dramatic worsening of the average access time, however, the results in some more or less real applications didn’t indicate any performance drops. And Maxtor drives a little bit later performed even faster in Quiet mode than they did in the Fast mode! And the linear speed… Check our latest reviews in the Storage section and you will see that linear speed increase usually doesn’t push the performance any higher even in those tests where it seems the most logical: during file copy. The victory belongs to the product, which managed to prove the smartest during a certain task processing. And if we have hard disk drives with the same firmware version, higher data density and hence higher physical speed sometimes provide no advantage at all. This is how we got a few extra tough nuts to crack. But this is just the beginning!
Our today’s test session showed very clearly that HDDs, which seem similar at first glance, are completely different in reality. It would be incorrect to base your opinion of the HDD model on the performance and benchmarks results obtained for another model of the same family, even if the only difference between them is the storage capacity. And when we compare the HDDs of the same storage capacity but coming from different manufacturers, it would be incorrect to draw conclusions about the entire product family from this particular manufacturer: some of them distinguish between the top models and the low-end ones by worsening some of their parameters. The best example here will be lower buffer segmentation in the slower HDD models from WD, Maxtor and IBM, and Seagate U7, which differs from Barracuda V by microcodes, but works just like any other 5400rpm drive. We could recall much more examples, such as reducing the lazy writing efficiency by Maxtor drives or slowing down the track seek. Besides that, the performance of a hard disk drive may change drastically with the introduction of the new firmware version and improvement of the firmware algorithms.
Well, anyway, let’s return to our today’s testing participants and IBM Deskstar 180GXP HDD family.
Since recently, the youngest (single-platter) Deskstar models are designed in a different case, which worsens the positioning speed, exceeding the difference between 8.5ms and 8.8ms claimed by the specs. Moreover, according to our experience, there are HDDs among Vancouver solutions, which features get worse with the time. Their read graph is either ugly from the very beginning, or turns ugly during the tests, and the obtained results never correspond to what we saw by models with a straighter graph. Moreover, younger models perform worse with small data blocks (less than 16KB), which is even harder to explain. I have no idea how they managed to do it with the same electronics.
Keeping these two facts in mind, it is not at all surprising that 60GB model always loses to its larger fellows that is why I wouldn’t recommend it. However, Vancouver2 aka Deskstar 180GXP turns completely different starting from 80GB storage capacity, showing much nicer results. Nevertheless, in NTFS their performance is not any better than that of the previous generation solutions, Deskstar 120GXP, and only larger buffer balances the scale towards newer model.
180GB model was almost always slower than the 120GB one, which also doesn’t make it an attractive purchase. So far the only reasonable explanation of its behavior is not quite correct implementation of LBA48 support. Recalling similar situation with Seagate Barracuda 7200.7 HDD, while its SerialATA relatives, didn’t have a problem like that, we can even start suspecting the Promise Ultra 133/TX2 controller.
I hope that after these detailed explanations it will be much easier for you to make your choice.
P.S.: There is one more piece of this puzzle, which we haven’t yet checked. The average access time of IC35L060AVV2 during writing is as high as that of the other HDDs of the same family, despite much worse average access time during reading. I feel quite suspicious about it. I wish I could disable lazy writing and see if there is any trick there as well.