SSD roundup: Vertex 3 vs M4 vs C300 vs 510 vs 320 vs x25-M vs F120 vs Falcon II

[keiths]

4K Random Read is the most important thing for 97% of users.

So I would recommend the Vertex 3 only if it is the 240GB Version. If not then The M4 C400 128GB would be my best bet.

I've been using fancycache for awhile, it reports that writes are the big-o, not reads, for xp x64 at least.

[Kent10]

I am also waiting for results of the OCZ Vertex 3 Max Iops versions. I wonder how much faster they will be in real world performance. They should be coming out shortly.

[Nizzen]

I am also waiting for results of the OCZ Vertex 3 Max Iops versions. I wonder how much faster they will be in real world performance. They should be coming out shortly.

In real world there is no difference between Vertex 3 vanilla and Max. In benchmark there is a small difference

[Metroid]

I've been using fancycache for awhile, it reports that writes are the big-o, not reads, for xp x64 at least.

Is that cache within the SSD?

I don't see any benefit using cache within an SSD, reason why I don't use cache within the SSD, but it might change in future. This reminds of compressible and incompressible data, Vertex 3 x M4 C400 all over again.

[Ao1]

Even if they are at 64KB (which is a typical pre-Vista cache manager buffer size), it won't change too much. A typical copy can use async I/O, which would essentially turn the 64KB sequential transfers into a QD>1 "randoms".
Well, on an SSD, there is really no sequential after some point, since the NAND gets rearranged and the LBA sequential mapping is hardly ever physically sequential.
Non async 64KB "sequentials" would therefore be essentially random 64KB at the physical level. Or random 4KB with higher QD at physical level.

Totally agree. What I try to explain is that something like AS SSD Benchmark uses multiple 16MiB xfers for the sequential speed test. Multiple xfers of that size are not common. I've only seen single occurrences of xfers in that region with Black Ops, compared to 39,023 occurrences of 4K read xfers, most of which were "sequentially" read over a short duration.

I believe this is why I have not been able to observe xfers speeds above 100MB/s when loading games. i.e. the read transfers consist of multiple small xfers well below 16MiB required to get speeds of 250MB/s that are achievable with AS SSD.

[Khoral]

Can you translate/ explain a bit more by what Marc is talking about when he describes benchmark traces being content with indentifying the type of access without considering content. (Page 6)

Sure

Typiquement si nous avions enregistré les accès effectués par Photoshop dans le traitement par lot et utilisé un tel logiciel, nous aurions pu avoir des écarts allant du simple au double entre les SSD, alors qu’à l’usage il n y a pas de différence. Enfin, ces traces se contentent de répertorier le type d’accès sans prendre en compte leur contenu, ce qui peut avantager les contrôleurs SandForce qui sont alors mis dans un cas favorable si le logiciel génère des données compressibles alors que l’utilisation servant de trace se basait sur des données déjà compressées.

Note : When speaking about "traces", he means PC Mark Vantage traces.

Typically, had we record the access done by Photoshop in the batch processing and used such software (note by me : meaning PC Mark Vantage), we could have had huge gaps between SSDs, where it wouldn't be felt at use. Lastly, these traces just list the access type, without considering their content, which can favour SandForce controllers which are in a favourable case if the software generates compressible data whereas the tracing use based itself on already compressed data.


So, it's already complicated in french xD
I understand it like that : First, he says that with Photoshop, you can have performance gaps when benchmarking, where at use you would see no difference.
Then he says that PC Mark Vantage generates compressible or not data, randomly (not sure about that part, but that's how I understand it). So you can't know with certainty if a SandForce controller is good because it was fed with compressible data, or if it is really good all the time.

About the chips, what do you want me to ask exactly ?

[Ao1]

Hi Khoral, thanks for helping out. Marc seems to be very well informed. That review is one of the best I have read. The trace issue appears to be a subtlety that he has picked up on, but even when translated to English I'm struggling to understand it. It would be great if he could explain it in more detail.

With regards to the chips it's the issue of 25nm having 4kB page size in the Crucial M4. My understanding (or should I say assumption) was that all 25nm had 8kB page sizes.

[johnw]

About the chips, what do you want me to ask exactly ?

Maybe you could ask how they know the page size of the flash chips. Do they have a spec sheet from Micron that gives the page size for those flash chips? Is it possible they got the specs of the 32Gbit 34nm flash chips confused with the 32Gbit 25nm flash chips?

[Khoral]

Ok, understood.

I mailed him, I'll keep you updated when I get some info

[keiths]

Is that cache within the SSD?

I don't see any benefit using cache within an SSD, reason why I don't use cache within the SSD, but it might change in future. This reminds of compressible and incompressible data, Vertex 3 x M4 C400 all over again.

You're sidetracked, the point is it logs activity which shows writes are much bigger than reads. As for your sidetrack, fancycache can cache writes, in doing so consolidates them, which results in fewer writes to the underlying device, an obvious benefit to SDD longevity. As for speed, unless your SDD does 4GB/s, it's also faster.

[Ao1]

Maybe you could ask how they know the page size of the flash chips. Do they have a spec sheet from Micron that gives the page size for those flash chips? Is it possible they got the specs of the 32Gbit 34nm flash chips confused with the 32Gbit 25nm flash chips?

Hi John,

It's intriguing the way performance is coming out at QD 1 with 4k random reads.
• C300 128 is 3% faster than the C300 256
• OCZ V3 120 is 5% faster than the V3 240
• M4 128 is 19.7% faster than the M4 256

At QD 2 and above the larger capacity models become faster. That makes me think it is not an anomaly in the testing, although maybe that could not be excluded when differences are less than 5%.

With the Intel 510 & 320 however there is no significant difference between the different capacity drives at QD1. Above QD 1 and the 120 version of the 510 is faster than the 250. With the 320 it is the other way around.....but here we are comparing different controllers

Ok, understood.

I mailed him, I'll keep you updated when I get some info

Cool thanks. Did you ask him about the trace issue as well?

[Khoral]

I didn't, as I don't think I get it enough to be able to ask a "correct" question xD

And he already answered me o/

So, he says that it's not only the 25nm that include 8 KB page size, but also the capacity of the chips. So you can have 4 KB page size with a 25 nm NAND flash chip.
And when I asked him about how he knows that, he told me that he was able to retrieve some datasheets telling so (as he didn't tell me which or how, I admit that I can't ask for more ^^)

[Metroid]

You're sidetracked, the point is it logs activity which shows writes are much bigger than reads. As for your sidetrack, fancycache can cache writes, in doing so consolidates them, which results in fewer writes to the underlying device, an obvious benefit to SDD longevity.

It seems you use programs that write more than read, not my or many others cases. I do not use cache within an SSD. So the longevity of my SSD will be many times greater than if I was using fancycache.

As for speed, unless your SDD does 4GB/s, it's also faster.

It can't beat memory ram and that is my point.

[keiths]

It seems you use programs that write more than read, not my or many others cases. I do not use cache within an SSD. So the longevity of my SSD will be many times greater than if I was using fancycache.

The use in question is caching of the OS drive, not a specialized use. Write cache reduces the number of writes to the drive, SSDs have limited writes, ergo, yes, will extend the life of SSDs.

> It can't beat memory ram and that is my point.

The point I saw you making was there's no point to using cache with SSD. How fancycache(memory) being faster than SDD makes that point I don't get, or I missed another point you were making.

[Ao1]

^^ A significant portion of I/O activity occurs within the windows file system without touching the storage device.

I think the objective of fancy cache is to better manage the Windows file system cache by using different algorithms to try and keep useful data in cache, thus limiting the requirements to re- read from the device to obtain dropped cache data.

Better cache management can in theory be very beneficial if the storage device is slow or if the cache management program can be specially tweaked for a particular application. I've tried fancy cache with SSD and it made no perceivable performance difference to me.

Windows does an excellent job at managing cache for general use. Of course there will always be situations when a more focused cache management system could do better for a particular task, but it might at the same time also slow things down elsewhere in the process.

SSD's are so fast that it negates the benefit that might be seen with HDD.

I'm surprised you are seeing more writes. Normal I would say it's a 10 to 1 (or less) ratio between reads and writes. Do you do a lot of tasks that write data?

Regarding write caching, don't forget that SSD's also combine writes to reduce wear. This happens within the SSD itself.

My 2c anyways. Maybe there is a better explaination on cache OS/ Cache programes work.

[Khoral]

This could be of some use...

http://translate.google.fr/translate...n&hl=&ie=UTF-8

Maybe that could explain how the V3 end at the top on Anand benches.

[Ao1]

Back on topic

The Micron product sheet states: Page size x8: 4320 bytes (4096 + 224 bytes) This appears to be the same for:
MT29F32G08CBACA/ EACA/ FACA/ XACA/ ECCB & FACB

[Khoral]

Aren't these 34nm ?

[Metroid]

The use in question is caching of the OS drive, not a specialized use. Write cache reduces the number of writes to the drive, SSDs have limited writes, ergo, yes, will extend the life of SSDs.

> It can't beat memory ram and that is my point.

The point I saw you making was there's no point to using cache with SSD. How fancycache(memory) being faster than SDD makes that point I don't get, or I missed another point you were making.

When I asked within an SSD I meant using the SSD as root cache for it, my point was not cache with an SSD and yes it was cache within an SSD, I have or had no idea that fancycache is a memory based cache program, reason I asked about it in the first place.

Well concerning the OS drive about writing more than reading, because if there is nothing much to read it will not do it. As soon as a game + some looped programs are opened then the reads will increase. I don't have time to test to confirm this but many around here can confirm this and I stand by my quote: "4K Random Read is the most important thing for 97% of users."

[Ao1]

This could be of some use...

http://translate.google.fr/translate...n&hl=&ie=UTF-8

Maybe that could explain how the V3 end at the top on Anand benches.

If you only read/ write across a limited span on the SSD you get very good results. Wear levelling can kick in. If you read/ write across the complete span of the SSD it will really struggle. Off the top of my head Intel give specs based on an 8GB span. They also now give data for performance across the full span and IOPs drop like a stone. 300 or 400 from recollection.

If you write lots of small files and then overwrite them I think it also slows things down when compared to over writing larger files.

Benchmarking SSD's is a nightmare.

[Ao1]

Aren't these 34nm ?

I'd guess yes, but I only got to see an extract from the product data sheet from Marc. That kind of info is confidential/ proprietary so its not possible for the public to get that kind of information from Microns web site. I did try

[Khoral]

Same here ^^ Couldn't find anything there.

Benchmarking SSD's is a nightmare.

That's so true. But it makes me ask "Is benchmarking SSDs useful ?" (not in a "who has the biggest e-penis size" use, but more in a 24/7 use)

[keiths]

fancycache is beta, available as a download. Hitting just the cache, 4k random qd1 r/w is 655/555MB/s in crystalmark, which with a 1-2gb cache is 95-99% of the time.

[Ao1]

Same here ^^ Couldn't find anything there.

That's so true. But it makes me ask "Is benchmarking SSDs useful ?" (not in a "who has the biggest e-penis size" use, but more in a 24/7 use)

That is why it is good that Marc ran real life applications and timed them. He is waiting for a mod to activate his account and then he will hopefully join us.

[Marc HFR]

I'd guess yes, but I only got to see an extract from the product data sheet from Marc. That kind of info is confidential/ proprietary so its not possible for the public to get that kind of information from Microns web site. I did try

Hi
in fact it's the datasheet for
MT29F32G08CBACA, MT29F64G08CEACA, MT29F64G08CFACA,
MT29F128G08CXACA, MT29F64G08CECCB, MT29F64G08CFACB

MT29F64G08CFACB is the one on M4 128 GB (at least mine)
MT29F32G08CBACA is the one on Vertex 2 25nm with 32 Gb die, for example here :

http://www.anandtech.com/show/4256/t...review-120gb/3

In the datasheet i could not find something about the process, but since the endurance is rated at 3000 PROGRAM/ERASE cycles, and since above SSD (M4 and Vertex 2 25nm) used 25nm NAND ... we can assume it's 25nm