IOMeter – Average Transaction Time (rev 1)
Back with the Kingston SSDNow V Series 40GB review, I revised the layout of these graphs to better show SSD latency and access time. First, I have removed HDD results as they throw the scale too far to tell any meaningful difference in the SSD's you are trying to focus on. Second, I have reduced the queue depth scale down to 4. In practical terms of a running OS, queue depth is how many commands are 'stacked up' on the SSD at that time. An SSD is so fast at servicing requests that typical use will rarely see it increasing past 4. In the cases where it does, there is so much going on that you are more concerned with IOPS and throughput at that point than transaction time. The below charts are meant to show how nimble a given SSD is. Think of it as how well a car handles as opposed to how fast it can go.
Some notes for interpreting results:
- Times measured at QD=1 can serve as a more 'real' value of seek time.
- A 'flatter' line means that drive will scale better and ramp up its IOPS when hit with multiple requests simultaneously.
These new charts are not the
These new charts are not the easiest to read.
Slightly larger text and solid colored bars would help a lot.
I second this. I find them
I second this. I find them very hard to read. The bar charts are okay because they are all in order, but when they wonder around like the line graphs, they’re practically illegible. Add in the mislabeled axies and I’m not sure what I’m supposed to be reading.
Agreed.
Agreed.
Not the easiest graphs to
Not the easiest graphs to read!
Background color hinder very much.
It looks like you mislabeled
It looks like you mislabeled the X axis on the PCPer File Copy Test charts. I’m guessing it’s supposed to be “seconds” rather than “MB/s”.
Agreed. Also, i’m pretty sure
Agreed. Also, i’m pretty sure that for the “IO Meter Average Transaction Time” lower – not higher – should be better.
Thanks for the catch, I’ve
Thanks for the catch, I've re-uploaded corrected versions, and expanded the QD out to 8 on these to more easily see where the drives are headed. Expanding it further would make the lower part of the scale harder to read.
Yeah, I almost went out and
Yeah, I almost went out and bought an ADATA SP610 in 128GB. 🙂 That thing beat everyone!
Got it. Fixed the axis label
Got it. Fixed the axis label on file creation and copy charts. Thanks for reporting this.
Look at how much extra room
Look at how much extra room is available in that 2.5in casing for the 512 and 1tb models! Going with full 16 layer packages and filling up the remaining space with them could yield a 2.5 inch SSD in excess of 3TB. O_O
This tech needs to hurry up and get fully commoditized so Samsung has an incentive to make drives that size and we can actually buy them at reasonable prices. Doing so would put a few more well earned nails in the HDD makers coffins.
hey Allyn when are you
hey Allyn when are you getting the intel 750 pci-e ssd? supposed to be out in Q4 and well… its Q4 now!
Possible error with the YAPT
Possible error with the YAPT chart. Shows queue depth on the bottom when it should be block size(or whatever the correct term would be). Regardless, interesting new benchmark along with a great article.
Fixed, and thanks!
Fixed, and thanks!
I’m wondering, can these
I’m wondering, can these drives perform any faster if connected to 12gb/s SAS ports?
The controller and connector
The controller and connector do not support SAS 12Gbit/sec. Even if connected to an appropriate HBA, the link would fall back to 6Gbit SATA.
As usual I’m late to posting
As usual I’m late to posting comments, but in case anyone notices my post: I have not found any source at Samsung or here where it addresses some sort of “hold-up” protection on the power line in case of a PSU failure. Anyone know?