The Maxtor behaves in a peculiar manner. It is similar to the other HDDs under low loads, being rather slow at writing (but very fast at reading). As a result, it delivers almost the same performance at high percentages of writes irrespective of whether the queue depth is 64 or 16 requests long. A further increase of the queue does not bring any performance benefits as the HDD has already reached its top performance (it cannot maintain a longer queue).
Seagate’s first SAS disk series behaves much alike to the company’s main opponent then, Maxtor, having a low efficiency of writing and no performance growth at queue depths longer than 64 requests. The graphs are all somewhat lower than in the opponent’s diagram: Seagate wouldn’t have a chance in comparison.
As you know, Maxtor was bought by Seagate and their struggle ended due to the default of one of the combatants. Seagate took to improving the firmware then. As a result, the senior disks of the 15K.5 series are almost as good as the Maxtor Atlas 15KII although still somewhat worse than the latter under mixed loads.
The junior model is radically different and resembles the Hitachi 15K147, drawing nearly horizontal graphs, too. However, the Seagate shows a higher performance growth at longer queue depths than the Hitachi. As the result, the Hitachi speeds up at very long queue depths whereas the Seagate reaches its maximum performance at a queue depth of 64 requests and does not accelerate thereafter.
The next generation of Seagate drives is faster yet, as is especially conspicuous with the 15K.6 series at reading and at mixed loads. They also begin to display a very odd peculiarity of their behavior: they are much faster at a queue depth of 64 requests than at 256 requests. The HDD seems to be not meant for such loads and gets overwhelmed by the flood of requests.
This seems to be the stop to the development of Seagate’s HDD firmware. The HDDs of the newest generation, 15K.7 and NS.2, behave alike to their predecessors, although do not get stifled at a queue depth of 256 requests. They have no performance growth at that queue depth either, though.