Originally Posted by
jchamlin
Oops, sorry for the necro posting. Didn't notice the dates.
Anyway, yes it is TRIM we are worried about. And yes, the X25-E does take a tremendous performance hit as it runs out of pre-erased cells. Anyone that says it doesn't, has not seen our real-life use case (see below). Both MLC and SLC need to first erase, and then write, in order to store data. Just because SLC's block size is typically half that of MLC and that it does it a bit faster, doesn't mean it doesn't take that much of a hit. Pre-erased cells are a giant win for write performance, this having TRIM purge out unused cells and make them pre-erased as a background activity when there's nothing else going on is a big performance win.
I guess it also depends on your use case though. We're software engineers. We work on an enterprise application in MyEclipse with 10000s of source files compiled, and deployed to Tomcat. We can burn through 100G of writes in a week (tested on an ioXtreme which has a meter which shows us how much read/write we do per hour/day/week). We have prototyped the X25-M G1, G2, X25-E, Fusion-io's ioXtreme and ioDrive (the big dog), a few OCZ Vertex drives, software-based RAM drives, and some DDR based SSDs like the i-RAM, HyperDrive5 (the ANS-9010). Our current configuration is 4x 10K WDs in RAID10 (shipped from Dell preconfigured that way in a T3400 chasis). So, I've seen lots of solutions.
The DDR based RAM drive solutions are the fastest. The X25-E and the ioXtreme are the only SSD that are even close. Both start out ALMOST as fast as (but not quite) as the DDR based SSD solutions. But both fall off dramatically as they run out of pre-erased cells. I give Intel and Fusion-io both great credit for their IO controller/driver/hardware architecture for pulling that one off (the i-RAM and ANS-9010 must have some average IO controller logic, I'd like to see an Intel DDR based SSD to see what Intel's controller and DDR's speed could do). Anyway, the X25-E actually slows down, and during a compile and deploy becomes substantially slower than factory new. Depending on the operation, stuff with a lot of small file random reads and writes (i.e. compile and deploy) are about 25-50% slower. That makes it about comparable with our RAID10 mechanical drive solution for build speed. The worse offender was the OCZ, it actually slowed down to be 70-100% slower, and at its worst was way slower than the RAID10 solution.
Anyway, so we've already prototyped every SSD solution we can think of to speed up our enterprise software development. I have high hopes that the next generation of X25-E will be what we're looking for. But I do not think we can wait, so we'll probably go with the DDR-based solution (the 16GB ANS-9010). Unless of course, someone here can propose something we haven't tried yet to get the best compile/build speed out of our development environemnt. Anyone have any bright ideas on what we could try next? (also sorry, don't mean to hijack a necro thread, I'll behave and post a new thread about our use case and ideas, and and post a link to the new thread from here).
Thanks!
-J.C.
Posting Permissions
Reply With Quote
Bookmarks