Articles: Storage

Bookmark and Share

Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 ]

Database Patterns

In the Database pattern the drive is processing a stream of requests to read and write 8KB random-address data blocks. The ratio of read to write requests is changing from 0% to 100% with a step of 10% throughout the test while the request queue depth varies from 1 to 256.

You can click this link to view the tabled results for the IOMeter: Database pattern.

We will build diagrams for request queue depths of 1, 16 and 256.

Western Digital’s Caviar Black drives leave no chance to their opponents in this test, too. The newer E8 version is even an improvement on the already impressive performance of the older J7. Funnily enough, even the power-efficient products of the WD Caviar Green series are as good as the 7200RPM drives from their opponents at the queue depth of 1 request. Samsung’s F3 is the best drive among those opponents whereas its power-efficient cousin EcoGreen F2 is, on the contrary, the slowest one in this test.

The non-aligned random access has a terrible effect on the performance of the WD10EARS because it has to do more write operations than the other HDDs. Judging by the shape of the graph, this disk cannot make up for this deficiency with its large cache.

When the queue is as long as 16 requests, Western Digital comes out the winner again while the best of its opponents, the Samsung F3 and the Hitachi 1000.C, are only competing with the power-efficient series from WD. The Caviar Black drives are unrivalled, the E8 being better than its predecessor, especially at writing. We should acknowledge the progress WD’s competitors have made: the Hitachi 7K1000.C and the Samsung F3 are faster than their respective predecessors. The Samsung EcoGreen F2 is inferior to the power-efficient drives from the other brands, though.

The WD10EARS still has a very low performance (due to the reasons we’ve explained above) if there are any writes to be processed.

There are no changes in the standings when the queue grows even longer. We can only see the efficiency of NCQ in Western Digital’s drives. They are especially fast at low percentages of writes and, judging by the slump in the right part of the graphs, these HDDs prefer to use their cache for reordering read requests rather than for deferred writing. It is only at pure writing that the cache is optimized for deferred writing with the ensuing increase in its efficiency.

To sum up this part of our tests, we will show you diagrams with each drive’s performance at five different queue depths.

Hitachi’s new-generation HDDs obviously have new firmware algorithms as the overall shape of the graphs suggests. The Hitachi 7K1000.C has become better than its predecessor under mixed loads and has more effective deferred writing. Unfortunately, its NCQ is still far from perfect and its performance scalability at longer queue depths might be better.

The Samsung EcoGreen F2 has inherited its predecessor’s firmware. And it shows a rather passive behavior and does not do well under server loads. The SpinPoint F3 is different. It looks like Samsung finally dared to introduce considerable changes into the firmware algorithms in that HDD. The drive’s NCQ has become somewhat better at short queue depths and its deferred writing has improved, too. On the other hand, the HDD recognizes long queue depths but does not process them confidently: there are occasional slowdowns when the queue gets longer.

It is simple with the Western Digital Caviar Black: the company has long been using the same unified firmware for all its products. And this firmware is currently among the best we have seen in a long, long time. The developer has even managed to make deferred writing even more efficient in the E8 version of the Caviar Black.

The power-efficient HDDs have the same but less aggressive firmware. It is clear that these HDDs have a slower request processor and their read/write heads are not so fast (but quieter).

The WD10EARS shows us NCQ but no deferred writing. It is a shame we cannot load the HDD with aligned requests: the result would be interesting considering the 64 megabytes of cache.

Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 ]


Comments currently: 20
Discussion started: 03/08/10 04:10:41 PM
Latest comment: 10/03/16 05:30:12 AM

View comments

Add your Comment