1 Reply Latest reply on Jan 6, 2010 9:13 AM by Ourasi

    Read speeds @ queue depth one

    redux

      Can anyone please explain why the reads on the mlc drives are comparatively slow to writes at queue depth one?

       

      Could the drives be better optimised for more realistic queue depths that occur with desktop usage patterns? (As opposed to the unrealistic enterprise queue depths at 32 or 64 that performance is often benchmarked at.)

        • 1. Re: Read speeds @ queue depth one
          Ourasi

          If you are using the right tool, you will see that no appload (some coders of popular apps seems to live in the dark ages, and disregard NCQ/Queue Depth) uses QD#1. QD#1 is most used when a singel file is accessed in an NCQ supported environment, with no other tasks/queue waiting, therefore you should disregard MB/S or IOPS on QD#1 as they are utterly useless and completely linear, and focus on access time regarding QD#1, and thats all QD#1 is good for..

           

          A good example of how useless QD#1 is, is to look at appload on Mtron SLC, wich are almost twice as fast as the current performance leaders on QD#1 at ~40mb/s. They get left in the dust at appload, even if the Mtron are a very good SSD considering it's age.

          There is a tremendous technical difference between QD#1 and QD#4+ aswell, not only the few digits difference between them, and QD#4 is the smallest amount one should measure IOPS in benchmarks to simulate real world loads.

           

          Anandtech measured average QD on an Desktop PC to be #6 if I recall correctly. And bare in mind, as described below, you have to use way different settings in IOMeter/AS SSD to get corresponding real world loads. So if Anand is using IOMeter@QD#6, he is doing it wrong..

           

          Here is a snip from the "holy grale" of storage: "Now a few words on the # of Outstanding I/Os parameter. If you  set it to 1, then with the 100% Percent Random/Sequential Distribution we in fact measure a random access time. Value 4 corresponds to a load  of an elementary applications like Windows Calculator. According to StorageReview,  in average on real applications this parameter takes 30-50. The value more than 100 corresponds to high disc load (e.g. in case of defragmentation)." http://ixbtlabs.com/articles/hddide2k1feb/iometer.html

           

          So in short: QD#1=Access time. QD#30-50=appload of moderate load, QD#50-100=appload of moderate/heavy load, and these last two corresponds to apploads of various load in real world according to StorageReview, and they are the closest thing to fact as you can get..