Fast SSD for hammering incompressible data?

[david82282]

I'm looking for a fast ~120GB SSD for hammering incompressible data. It will probably get writes of about 100 TB per year (application is finite element analysis). It's fine if it wears out in a year or two. I'm currenlty using a Pyro SE whose SF controller has throttled to 80 GB/s. As I understand it (?), the best SSD for this app would have
- no throttling
- no or very fast compression
- high performance after the drive is full -- fast overwrite or frequent garbage collection? I'm pretty fuzzy on how to understand this one, or find data on it in reviews.
- ideally, 32nm NAND for life?

I'd like to stay under $200 since I'll probably wear it out, and of course avoid the ones with higher failure rates in user reviews.

I see there are some SSDs that are better with incompressible data (Samsung 830, Mushkin Chronos Deluxe), but I can't tell how fast they are once the drive is full.

Any insights appreciated!
David

[Boogerlad]

ocz vertex 4 or the plextor m3 pro

[Christopher]

Could you give us some more information on the application and the workload it generates?

If were speaking strictly about 128GB drives, the Samsung 830 (27nm Toggle), Corsair Performance Pro/Plextor M2P (32nm Toggle), Plextor M3P (24nm Toggle) might be the best drives for this application. If sequential write speed is important, there are practically no drives which can match them at 128GB (in terms of write speed with random data).

But the Crucial M4 256GB has been $220 recently, and that's a great option. The greater size will help on several fronts and it's quite fast at 256GB as well.

[canthearu]

I'm looking for a fast ~120GB SSD for hammering incompressible data. It will probably get writes of about 100 TB per year (application is finite element analysis). It's fine if it wears out in a year or two. I'm currenlty using a Pyro SE whose SF controller has throttled to 80 GB/s.

Have you tried a secure erase and partitioning your patriot SE to only 100gb (of the 120gb space). Then leave the unused space free.

See if that improves your speeds some.

What you are asking for is very very hard on the SSD controller (random I/O on a full SSD) ... and surprisingly, sandforce drives are actually pretty decent at it. I'm wary of offering any other suggestion due to the fear that how you use the drive is not benchmarked by most review sites. Most SSD are benchmarked in a unstressed desktop configuration, with plenty of free space and utilizing TRIM heavily, which will bench quite a lot higher then your work load would have them bench.

[ChinStrap]

If were speaking strictly about 128GB drives, the Samsung 830 (27nm Toggle), Corsair Performance Pro/Plextor M2P (32nm Toggle), Plextor M3P (24nm Toggle) might be the best drives for this application. If sequential write speed is important, there are practically no drives which can match them at 128GB (in terms of write speed with random data).

This is great info, thank you.

[Christopher]

Have you tried a secure erase and partitioning your patriot SE to only 100gb (of the 120gb space). Then leave the unused space free.

See if that improves your speeds some.

What you are asking for is very very hard on the SSD controller (random I/O on a full SSD) ... and surprisingly, sandforce drives are actually pretty decent at it. I'm wary of offering any other suggestion due to the fear that how you use the drive is not benchmarked by most review sites. Most SSD are benchmarked in a unstressed desktop configuration, with plenty of free space and utilizing TRIM heavily, which will bench quite a lot higher then your work load would have them bench.

I don't think we really know whether this is random or not. I tend to think it's more sequential in nature -- but I'd really like to know for certain.

If your definition of a good time is writing a lot of data to a SSD, then finite element analysis sounds like a good time

[canthearu]

I don't think we really know whether this is random or not. I tend to think it's more sequential in nature -- but I'd really like to know for certain.

If your definition of a good time is writing a lot of data to a SSD, then finite element analysis sounds like a good time

Even if the workload is largely sequential, many drives with low overprovisioning will have trouble if you are writing over the top of old data (rather then erasing the old file and writing a new file). My vertex 4 performed quite poorly during endurance testing when I was using the wrong Intel drivers that had disabled TRIM, dispite the sequential load.

[Christopher]

Even if the workload is largely sequential, many drives with low overprovisioning will have trouble if you are writing over the top of old data (rather then erasing the old file and writing a new file). My vertex 4 performed quite poorly during endurance testing when I was using the wrong Intel drivers that had disabled TRIM, dispite the sequential load.

This is true. When I tried the Octane on my laptop without trim it got UGLY... and fast.

If you do have TRIM, the Samsung 830 is able to write like a goddamn banshee.

[david82282]

Could you give us some more information on the application and the workload it generates?

Great questions and info--thanks very much! The specific program is Creo Simulate (formerly Pro/Engineer Mechanica). It solves a large matrix equation, and grabs portions to work on in RAM, while writing what it can't fit to disk. The Pyro SE gave a speed up of ~2x for run time though write speed still appears to be the bottleneck. (I currently have 12GB RAM, am upgrading to 24GB, and building another machine with 32GB.) A similar FEA program, ANSYS, found a 3x-8x speedup with SSDs:
http://www.ansys.com/staticassets/AN...-with-SSDs.pdf

I'm new to SSDs, so not sure if this is the right data to look at, but I ran Perf Mon on all the disk write activity during the middle of a run:





Here are some typical averages for the Perf Mon counters:
% write time: ~55% (I think this means the run times could theoretically be cut in half again, for infinitely fast writes.)
Avg. bytes/write: 1 M (The program typically writes 20-40 1 GB temp files for a medium size problem, that are apparently written in 1 MB chunks?)
Avg. sec/write: 0.013
Avg. queue length: ~0.55 (I'm guessing this means ~550 kB of data is waiting to be written at any given point)
Write bytes/sec: ~45 M (I think this reflects the ~55% duty cycle on ~80 MB/s?)
Writes/sec: 30 (range 1-80) (so it typically writes 30 of those 1 MB chunks per second?)
% read time: 1% (at the end of a run this jumps up to ~100%, but it's quick)


Then I ran AS SSD and CDM just after the run, to see what shape the drive is in (I should probably do 3-4 runs in a row to do recent writes on all free space):




Hmm, now if I only knew what this all means. To start, I'm guessing the 512k or sequential benchmarks are most relevant?

If your definition of a good time is writing a lot of data to a SSD, then finite element analysis sounds like a good time

Too true!

[canthearu]

What is your CPU utilisation percentage? Does it peg 100%, or does it drop below that for significant periods of time.

I'm not convinced you are limited by your SSD at this stage.

At the very least, you are limited by having a 64gig SSD rather then a 120/240gig SSD.

[david82282]

Have you tried a secure erase and partitioning your patriot SE to only 100gb (of the 120gb space). Then leave the unused space free.

See if that improves your speeds some.

What you are asking for is very very hard on the SSD controller (random I/O on a full SSD) ... and surprisingly, sandforce drives are actually pretty decent at it. I'm wary of offering any other suggestion due to the fear that how you use the drive is not benchmarked by most review sites. Most SSD are benchmarked in a unstressed desktop configuration, with plenty of free space and utilizing TRIM heavily, which will bench quite a lot higher then your work load would have them bench.

Thanks for the info! That's helpful to know those benchmarks are for the unstressed condition. Yes, I'd really like to know how a SSD performs when recently ~saturated. I saw one review on AnandTech along those lines, but that part is over my head at the moment.

Oh, this Pyro SE is actually a 60 GB, which I partitioned to 56 GB (~12% free space, assuming 64GB total). I tried a 50 GB partition for more free space, since my current models typically write 20-40 GB per run, but occasionally Creo needed more than 50. In a typical day, I might do a sequence of ~10 runs (checking results between each), and then another batch of ~8 overnight. So it doesn't get a lot of idle time for garbage collection or trim, unless I could force those to happen -- is that possible, or are there particular SSDs that have toolboxes or commands for those on demand or on a fast schedule?

[david82282]

What is your CPU utilisation percentage? Does it peg 100%, or does it drop below that for significant periods of time.

I'm not convinced you are limited by your SSD at this stage.

At the very least, you are limited by having a 64gig SSD rather then a 120/240gig SSD.

Good point and question. The program does put all 4 cores to ~100% at regular points in the run, but at other points the cores are quieter and it seems more limited by disk. But I'm not sure how the CPU% and disk writes correlate to each other -- tomorrow I'll do another Perf Mon with CPU%, over a longer time, to see. Yes, a larger SSD would be good -- I figured I'd try a low $ one to see how much it helps, learn from it, and then get the right one for the job. Thus this thread.

[canthearu]

So it doesn't get a lot of idle time for garbage collection or trim, unless I could force those to happen -- is that possible, or are there particular SSDs that have toolboxes or commands for those on demand or on a fast schedule?

If the temp files are deleted after they are finished ... it generally isn't a problem and most drives recover pretty easily from it.

Drives will ussually never do much erasing during the TRIM command, but it greatly aids the background cleanup process, freeing up erase blocks and making erase operations cheaper.

I have a feeling the samsung 830 will be a pretty good drive for this.

[Christopher]

It should be pointed out that a 60GB PyroSE probably only writes incompressible data at 80MB/s, so if you're getting that, it's probably doing a decent job.

But yeah, the 830 would kill in your application.

[Christopher]

So it looks like the PyroSE is running as fast as it can writing incompressible data. It's not throttled, it's just writing random data. The Patriots aren't using throttling as far as I know.

Could you post some SMART data? In decimal with CrystalDiskInfo? We can look at the current wear on the drive -- we can see the host writes vs. compressed NAND writes. This would help a lot in figuring out the type of workload the drive has been exposed to.

I'm not convinced that moving up to a faster drive would help tremendously, but without testing it myself it would be hard to say for certain. It would definitely help some, maybe even a lot, but probably not 8x times faster.

I looked at the PDF for the ANSYS FEA. In the case where using SSDs offered the most benefit, they were using 4 RAID0 15KRPM HDDs against 4 RAID0 Intel X25-E 64GB. The X25-E 64GBs are exceedingly expensive, but you could get the same level of performance from two fast consumer SSDs (like two Plextor M3Ps or two Samsung 830s in R0).

[david82282]

If the temp files are deleted after they are finished ... it generally isn't a problem and most drives recover pretty easily from it.

Drives will ussually never do much erasing during the TRIM command, but it greatly aids the background cleanup process, freeing up erase blocks and making erase operations cheaper.

I have a feeling the samsung 830 will be a pretty good drive for this.

Yes, temp files are deleted right after each run. Thanks for the rec on the Samsung 830 -- what makes it a particularly good choice?

[david82282]

So it looks like the PyroSE is running as fast as it can writing incompressible data. It's not throttled, it's just writing random data. The Patriots aren't using throttling as far as I know.

Could you post some SMART data? In decimal with CrystalDiskInfo? We can look at the current wear on the drive -- we can see the host writes vs. compressed NAND writes. This would help a lot in figuring out the type of workload the drive has been exposed to.

I'm not convinced that moving up to a faster drive would help tremendously, but without testing it myself it would be hard to say for certain. It would definitely help some, maybe even a lot, but probably not 8x times faster.

I looked at the PDF for the ANSYS FEA. In the case where using SSDs offered the most benefit, they were using 4 RAID0 15KRPM HDDs against 4 RAID0 Intel X25-E 64GB. The X25-E 64GBs are exceedingly expensive, but you could get the same level of performance from two fast consumer SSDs (like two Plextor M3Ps or two Samsung 830s in R0).

Thanks for the info on the Patriot's 80 GB/s and throttling. So is that limit mainly related to the incompressible throughput of the SF controller? The PyroSE does appear to handle very recent over-writes with no problem, as I just wrote 80 GB to it and retested the CDM -- same speeds.



Yes, below is the CDI data. I couldn't find any info on compressed NAND writes, though. (If helpful, I did check the compressibility of those 1GB files by zipping them... only about 2% less.) I'm guessing the SSD Life Left attribute means 99%? That sounds good, although 7920 / (5000*60) = 2.7%, so they appear to be expecting much more than 5k write cycles to it?




Thanks for the info on the Ansys paper, too.

It looks like you two are right about a faster SSD not offering a large additional speedup. Here is a PerfMon plot of CPU % and SSD read and write %, over 10 minutes:



The Cores (all 4 in red) average about ~70%, so an upper limit on speedup from an infinitely fast SSD is 1/.7 or 40% faster. The writes (dark blue) are frequent, but they don't seem to slow the Cores much. (I also did a PerfMon using a HDD -- that graph has long periods of read and write, with quieter Cores averaging ~20%.) The reads (light blue), while short, occur during low CPU activity, so a faster read would probably help more than I realized -- thanks, canthearu, for the CPU% question!

Now going back to the CDM read speeds of ~380 MB/s (instead of ~500), this SATA3 is through an Asus X58 with a Marvell controller, which I have heard are a little weak. My next workstation will be a Z77.

So, I'm thinking this PyroSE may be ok for this workstation, but I'll also need a SSD for the Z77 build. For that, I'm thinking:
- Sequential incompressible reads of at least 500 MB/s
- Sequential incompressible writes as fast as budget allows.
- A fast 120 or slower 240?

All thoughts appreciated!

Thanks,
David