Although there are new HDD models with the 27GB, 33GB and 40GB platters in the today's storage market, the performance leadership (at least according to our tests) still belongs to IBM IC35L0x0AVER07 hard disk drives with 20GB platters. In fact, it seems that the higher is the platter capacity, the faster should be the hard drive, but in reality things are totally different. The matter is that most manufacturers increase the platter capacity by making the tracks shorter, and not by making them "more dense" (having more sectors per track). However, the HDDs from various manufacturers very often differ (sometimes quite significantly) by their STR (Sustained Transfer Rate), i.e. linear read speed. At the same time, WinBench99 shows a really trifling difference between them.

The prevailing view is that higher STR implies high performance in WinBench benchmark set. Now we would like to figure out if this statement is true.

Testbed and Methods

In order to make the first quick check of our hypothesis we took the recently obtained results for "large" IDE HDDs such as Seagate Barracuda ATA IV, IBM Deskstar 60GXP, Quantum Fireball Plus AS, Western Digital Caviar 600BB and Western Digital Caviar 800BB.

Our testbed was configured as follows:

• Intel Pentium III (Coppermine) 600MHz CPU;
• ASUS CUBX-E mainboard, bios 1007A;
• 2x128MB PC133 SDRAM by Hyundai;
• Matrox Millennium 4MB graphics card;
• Windows 98/Windows 2000 Pro.

The disk drives were connected as Master-units to a separate IDE-channel. DMA support in Windows was enabled. We used FAT32 and NTFS file systems to format each of them as one logical drive of the maximum size with the default cluster. All the tests were run 4 times and then the average results were taken for the diagrams. The HDDs didn't rest for cooling down between the tests.

Here are the benchmarks used:

• WinBench 99 1.2
• IOMeter 1999.10.20

Tests

Well, the first diagram is built on the results shown in WinBench99 for FAT32 file system:

As we can see, there is no clear dependence of the WinBench99 results on the STR. Barracuda ATA IV boasts higher read speed than IBM Deskstar 60GXP, however, the latter appears faster in WinBench tests (especially in High-End Disk WinMark). And vice versa: WD hard disk drives with low STR turn out pretty fast in WinBench99.

Now comes NTFS file system:

Again we don't see any dependence of the drives performance in WinBench99 on the Sustained Transfer Rate...

Why are the HDDs performing like that in WinBench99? Maybe it has to do wit the HDDs caching system?

Well, let's try to figure out if the drives caching system can influence their performance. For our investigation we selected IBM Deskstar 60GXP HDD.

As you know, each HDD has the so-called firmware, i.e. some kind of micro-program for the drive processor. So, we dare suppose that high hard disk drive performance is mostly determined by the frequency of its processor and perfection of this firmware, rather than by the data density per platter. As for the functions of this firmware, we can only guess what it is responsible for, because the info of the kind is locked by the manufacturers. However, some facts still penetrate into the world.

Not so long ago, for instance, IBM released a new 1.20 version of its IBM Feature Tool utility, which is now capable not only of changing the UDMA mode and the noise level but also of enabling and disabling two very interesting firmware functions: read ahead and write caching.

To tell the truth, we don't quite understand what's the purpose of providing the users with the possibility to interfere so deeply with the caching algorithms. The only idea that occurs to us is that this is one of the ways to solve the 75GXP family problem.

So, what is read ahead? This is a good old means of speeding up the HDD when reading successions of data. Its major idea implies that when the HDD sector is requested for reading, the drive caches not only the requested sector but also a few neighboring ones. If the next request is addressed to the sector, which is already stored in the cache, it will be fulfilled immediately. The same method is used in the CPUs, for instance, and in many other cases. The difference between the caching algorithms lies with the cache architecture and decision making process, namely with the question "to cache or not to cache". Because if you keep attacking your HDD with short random requests addressed to one and the same sector and the HDD will every time open a new caching line for n-sectors, it will be just a waste of time. Since only the first sector from each caching line is demanded, and all the rest except the one already submitted to the program will be simply thrown into oblivion… Smart firmware should be able to detect whether the sectors read are likely to represent a succession or are just short random requests.

Another important parameter telling on the caching performance is the size of the caching line, i.e. the number of sectors read "just in case". The size of this line may be constant or may change dynamically, depending on the type of reads carried out, or the average file size, if you like. Choosing the proper cache line size will allow to find a compromise between the probability of the request to get into the cache and the memory size spent on this operation.

Smart firmware also doesn't split cache-memory into two parts of static size (for reads and writes), but changes their size dynamically depending on what the user is doing. If the user reads a lot from the HDD, there will be more caching lines for reads, if the write operations prevail, then there will be more caching lines intended for writes. Sometimes it may turn out much more efficient to remove everything from the reads caching lines and to assign them to writing operations. As soon as the fragmented swap-file is written onto the HDD, the info in the read caching lines may be restored as it was before the procedure.

And now let's pass over to write caching!

Write caching implies that the HDD received a sector from the driver and cached it instead of writing down immediately. If this sector is requested for reading, then it gets immediately written down onto the drive and then the read operation is carried out, or it may also be provided directly from the cache (it depends on how "impudent" the firmware is). If firmware sees that the HDD is doing nothing and the heads are located near the sector requested for writing, it performs the write operation. Or it fails to carry out this operation if the user performs an emergency shut down of the PC. In this case, the next Windows booting will be preceded by the ScanDisk.

In order to find out how the HDD performance will change in case read ahead and write caching are disabled, we carried out three additional test sessions for IBM Deskstar 60GXP HDD in UDMA100 mode. Together with the already obtained results in normal conditions we got 4 different cases for consideration:

As we have already said, we checked the HDD performance with the help of two benchmark sets: WinBench99 and Intel IOMeter.

Let's start with WinBench99. Here are the results obtained in Business Disk WinMark and High-End Disk WinMark:

Well, the situation is very interesting. Disabling read ahead reduces the performance of the drive in both: Business Disk WinMark and High-End Disk WinMark. As for write caching, it mostly tells on the performance in High-End test, where disabling write caching resulted into greater performance drop than disabling read ahead feature. We really wonder why… As far as we understand, this test unpacks some files typical of certain applications onto the HDD and then starts reading all these files. The timer detects the time spent on this operation. But what does it have to do with writing then? Does it mean that these files are so small that the info cached by the smart IBM firmware appears enough to provide performance that high? In case both features (read ahead and write caching) are disabled, the HDD performance gets almost 3 times as small as in normal conditions.

So, the cache turns out very important, even determining, in these benchmarks.

Now let's take a closer look at Intel IOMeter. We'll see how the performance of the hard disk drive changes when the read ahead and write caching are disabled.

At first, we would like to offer you the Total I/Ops obtained for IBM Deskstar 60GXP HDD:

Now here is the graph:

A beautiful picture, don't you think so? The first thing that catches our eye here is that in case the read ahead or both, the read ahead and write caching, are disabled, the HDD appears faster than with these features enabled. Unbelievable! Although, this phenomenon is quite normal and can be easily explained.

In the FileServer pattern the probability for the requested data block to follow the one, which has been just processed, is almost null, because the address of the next block is 100% random. And the read ahead algorithms simply idle! Moreover, they even slow down the whole hard disk drive because it has:

• to think how many sectors it has to read and where it has to save them;
• to read these sectors (the tracks in the beginning feature about 800-1000 sectors, a single rotation takes around 4.17ms, so you can get the proportion yourself...).

In other words, we waste a lot of time for nothing when following the read ahead algorithm. So, when this feature is off, the HDD shows its best.

The second look at the results shows us that the worst performance was shown by the drive when we disabled the write caching. This thing is also easy to explain: read ahead causes some performance drops, and all the write requests are carried out immediately, i.e. as soon as they arrive. According to the specification of the FileServer pattern, the writes are performed in 20% of all requests and since the HDD can't change the order in which all operations are carried out, its performance worsens.

The most interesting thing about it is the fact that disabling both: write and read caching, allows the drive to show even better results than in nominal conditions. In other words, disabling read caching eliminates a huge performance drop caused by write caching disabling.

Now let's turn to another pattern: WorkStation:

Here only 80% of the data blocks addresses are obtained randomly, i.e. in 20 cases out of 100 the next data block follows the just processed one. So, it changes the whole picture drastically. The highest result now belongs to the HDD "armed to the teeth", and the lowest result - to the one with write caching disabled. Actually, everything is quite logical: the data block size remained unchanged (8KB), and in 20% cases performing read ahead is hundred percent justified.

This way, in case the requests are not random, disabling the mentioned firmware functions results into performance worsening.

The interesting thing about DataBase pattern is that it also defines the block address randomly, but the write operations here make 33%. As a result, we see a similar picture as for FileServer pattern, but the results shown by the drive with the disabled write caching are even worse here. Since there are more write requests, the average time for processing each of them grew bigger.

Conclusion

These tests show that at present caching algorithms (and maybe even the DSP frequency!) influence the WinBench99 results much greater than the per track data density.

If you belong to regular users, then disabling read ahead and write caching by IBM HDDs will slow down your HDD significantly when working with Windows applications.

If you are using IBM hard disk drives for server needs, disabling read ahead may add more speed to your HDD in some tasks. However, we don't think that the game is worth the candle, as the performance increase you'll get will not be that impressive at all...