Shedding some light on Intel X 25-V SSD benchmarking curiosities

[idata]

Hi All,

Scott from Intel here. Before we get into the meat of this post, I wanted to let you all know that I'll be doing a similarly technical post once or twice a week either here, or on Intel technology blog here:

http://blogs.intel.com/technology/ http://blogs.intel.com/technology/

(that's me on the top!)

If you guys want to get updates on when I've made a new post, follow the Intel SSD twitter account or become a friend on facebook. I'll try to keep these portals free of junk and just give you guys access to the content. The Twitter account can be found here:

http://twitter.com/intelssd http://twitter.com/intelssd

and the facebook page can be found here:

http://www.facebook.com/pages/Intel-Solid-State-Drive-Official/97164766102 http://www.facebook.com/pages/Intel-Solid-State-Drive-Official/97164766102

Let me know if you have any questions about Intel SSD social media. Anyways. The post.

There have been a solid handful of questions regarding a strange occurrence that takes place while benchmarking read performance across the entire drive capacity of Intel's X 25-V SSD. The drive is specified to achieve 170 MB/s sequential read speeds, but tests show the drive achieving read speeds above 200 MB/s, as seen in the graph below:

"Holy Cow!" - You

How does it do that? Well, as it turns out, the drive's controller is doing something special. The controller has to keep track of where data is actually written in the NAND to be able to grab that data upon request from the host. As such, it also has to know where data is not written. Because accessing NAND takes some time (even if "some time" means "a ridiculously small amount of time"), the controller wants to make those NAND accesses as infrequent as possible. And that's where the secret sauce comes in; If the controller knows that a read request is being made for an area of NAND that has no data, it doesn't read the NAND, but instead reports back zeros. Therefore, the only time spent is the time the controller takes to process the SATA request. This ends up yielding a very fast response rate and speeds in the neighborhood of 250MB/s. So what you'll see, depending on how you have partitioned and written data to your SSD, is an area that performs in the neighborhood of 170MB/s (the area where data actually is) and an area that performs above 200MB/s. Keep in mind that some benchmark tests actually write data before reading. If this is the case, you won't see any difference. So, the take-away is this: be aware of the state of your SSD before hastily interpreting benchmarks. If it is newer, with little data on it, then you'll see an unusually high sequential read performance. If you've been using the drive for some time and have a fairly beefy chunk of data on it, then you'll get sequential read speeds that reflect the actual amount of time it takes to read from NAND.

Same drive almost completely filled:

Drive with most data cleaned again:(Back to the same state as original.)

Feel free to post any questions/comments! I'll do my best to answer!

[idata]

Excellent post, I'm looking forward to more.

I'm surprised that access times can reduce read speeds by 30MB/s, especially as the V drive has less channels that the M drive. (?) Is this phenomenon only relevant to the V drives? Read speeds appear consistent on my G2 – 160GB M drive, regardless of the amount of data on the drive, but then again I use AS SSD benchmark.

How does this affect partition size? I only use a 117GB partition on a 160GB drive. I do this as I don't need the space and from my understanding a smaller partition reduces wear. (?)

Maybe a future article could give some insights into the effect of different raid stripe sizes……

[idata]

Redux,

Good to see you're posting again!

I'll address two of your concerns. First, your confusion about reduced access times. On the Intel X 25-M, we saturate the SATA bus speed (as a result of having more channels), so the SATA bus speed becomes the bottleneck as opposed to the NAND reads. More channels equals faster, not slower. Think about an 8 cylinder engine versus a 4 cylinder engine. Your 300 series is faster than my Prius. Your vespa is faster than my segway. Et cetera.

Second, with regards to your comment about partition sizes. I don't want to get too far into it, but unless you've got an enterprise-level workload, you're better off just using the whole partition.

Hope that helps!!

Weekend soon, wooo!

-Scott

[idata]

Are you planning on saturating SATA 6 with the G3 drives?

[RGiff]

Just would sheed some light on ALIGNMENT. See attached specs.