Final Words

The only data I haven't displayed here is estimated write amplification and estimated drive longevity. I'm still fine tuning the process before I present the data but I can give you, at a high level, what I've seen. As I mentioned in the comments to the V+100 article the three leaders in write amplification (and thus drive longevity) over the long run are: SandForce, Crucial and Intel. Indilinx doesn't do as good of a job of keeping write amplification low over the long haul. The Barefoot+Martini platform addresses the performance issues we've had with the original Barefoot, but it doesn't seem to address worst case write amplification. Thankfully, Barefoot+Martini aren't Indilinx's next-generation SSD platform. The 6Gbps Jet Stream controller is still in development and is designed to go after the high end, Martini simply modernizes Indilinx drives.


Indilinx Barefoot (left) vs. Indilinx Martini (right)

The question ultimately boils down to price. You can already get a 128GB SandForce based drive for $229, and if you're mostly filling your drive with a lot of incompressible data (photos, videos) there's always the C300 for a bit more money. Both options will give you better performance and lower write amplification than what Indilinx offers. What we need is a good value alternative to SandForce. The SF-1200 controller isn't cheap at all, and this is where Indilinx's Barefoot+Martini could come in.

Assuming it's devoid of any typical new SSD teething problems, the Barefoot+Martini based Vertex Plus could be a good way to squeeze an SSD into a budget constrained performance system. I'd still like to see greater than $35 savings compared to SandForce though. We're still a few weeks away from release candidate firmware so I'll reserve final judgment until then. It never hurts to have more competition in the market.

Power Consumption
POST A COMMENT

61 Comments

View All Comments

  • leexgx - Tuesday, November 16, 2010 - link

    i agree 128gb would seem to be the min i would get

    got the 256gb m225 my self before the £100 price increase i have 50gb free on that, i had an corsair s128 before that bit slow at writing but load times was quite fast, main thing that went faster was disk based installs like stream pre load decrypt (when you pre load an steam game its encrypted it has to decrypt Very disk intensive as it has to read and write a lot) as it would make my corsair S128 stall the system for short times as latency's whent up to 1000, m225 system is fully usable when it was decrypting blackops

    apart from jmicron and older samsung first-second gen ssds, you be hard pressed to notice the difference unless you was doing server loads (like if i went from an m225 to an sf-1200 based ssd my pc mite boot up 1 second faster same goes for games and programs)

    only reason you see me replacing this ssd is if i was getting an 512gb version (like i got money to burn :) ) or 2xSF-1200 based ssd's in raid 0 (as GC works good on them)

    the segate XT drives may not seem that good but if your mainly only playing games or opening the same files often you could raid 3-4 of them in RAID 0 and that give you 16gb of cache data to work with
    Reply
  • iamezza - Wednesday, November 17, 2010 - link

    I would consider myself a power user, I spend much of the day on my PC working then later for gaming and I get by just fine with an 80GB SSD. I am currently using less than half capacity. Moving the user files in Windows 7 is a piece of piss, takes about 5mins and then its done, it's just drag and drop onto your storage drive.
    The only thing I can't do is install my games directory onto an SSD even a 128GB wouldn't be enough for that.

    I recently installed a 30GB SSD into my HTPC and it works a treat. Being a HTPC everything apart from the OS goes onto a storage drive so 30GB is more than enough.
    Reply
  • Mugur - Thursday, November 18, 2010 - link

    You are right, regarding this particular case, but I can see from other small drives, like Corsair F40, Intel X25-V 40 GB etc. how the performance scales down... F40 looks almost similar to F120 and we all know with Intel 40 GB that they have half channels so the sequential write is the most affected, not so much other factors. Reply
  • Crucial - Tuesday, November 16, 2010 - link

    All these reviews keep making me happy with my purchase of the 128mb Crucial drive. It seems to be a solid all around performer that still stays towards the top of the heap. Reply
  • Mr Perfect - Tuesday, November 16, 2010 - link

    Not to divert this nifty SSD article, but if the drive manufacturers are so dead set on using round, metric numbers for their bytes, then I think I'm going to start calling them Metric Gigabytes and Imperial Gigabytes. It follows the current naming schemes much better then these ridiculous gibibytes. Who came up with that name anyhow? Reply
  • akedia - Tuesday, November 16, 2010 - link

    *sighs*

    The prefix giga- is metric, while the prefix gibi- is binary. Your phrase "metric gigabyte" is redundant, while your "imperial gigabyte" is nonsensical.

    A Gigabyte is 10^9, or 1,000,000,000, bytes. https://secure.wikimedia.org/wikipedia/en/wiki/Gig...
    A Gibibyte is 2^30, or 1,073,741,824, bytes. https://secure.wikimedia.org/wikipedia/en/wiki/Gib...

    Using the word gigabyte for those nice, round numbers is correct. The problem is operating system manufacturers whose systems display the number in the form of gibibytes. I'm not sure about others, but OS X now correctly displays gigabytes, erasing the apparent (but not actual) discrepancy between the box the drive came in and the system display about the drive.

    In answer to your question about who named them, from the Wikipedia entry for Binary Prefix:

    "The set of binary prefixes that were eventually adopted, now referred to as the "IEC prefixes," were first proposed by the International Union of Pure and Applied Chemistry's (IUPAC) Interdivisional Committee on Nomenclature and Symbols (IDCNS) in 1995. ... The new prefixes kibi (kilobinary), mebi (megabinary) and gibi (gigabinary) were also proposed at the time, and the proposed symbols for the prefixes were kb, Mb and Gb respectively, rather than Ki, Mi and Gi. The proposal was not accepted at the time.

    "The Institute of Electrical and Electronic Engineers (IEEE) began to collaborate with the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) to find acceptable names for binary prefixes. The IEC proposed kibi, mebi, gibi and tebi, with the symbols Ki, Mi, Gi and Ti respectively, in 1996.

    "The names for the new prefixes are derived from the original SI prefixes combined with the term binary, but contracted, by taking the first two letters of the SI prefix and 'bi' from binary. The first letter of each such prefix is therefore identical to the corresponding SI prefixes, except for "K", which is used interchangeably with "k", whereas in SI, only the lower-case k represents 1000."

    That's quite the user name for someone who can't manage a couple of Wikipedia lookups. The right to be outraged comes with the obligation to be informed.
    Reply
  • Mr Perfect - Thursday, November 18, 2010 - link

    Yes, it was supposed to be nonsensical. I apologize for not putting more ;) smilies in my post. Reply
  • Mr Perfect - Thursday, November 18, 2010 - link

    Also, it wasn't just a troll post, since it apparently looks that way. I really AM annoyed at how the whole thing is being handled. Even though a 128Gib SSD really DOES have 128Gib on it, and is sold AS a 128Gib drive, the user space will be far less, depending on controller model. We're using the right units of measure, but people are STILL ending up with less then they thought they where. This was probably our one shot at getting accurate labeling on drives.

    I suppose I should have just said that, rather then try to have some fun with it. :|
    Reply
  • FunBunny2 - Tuesday, November 16, 2010 - link

    The real usecase for SSD is high normal form RDBMS. Let's get a TPC-C test of these things, using flatfile type schemas and BCNF type schemas; both on HDD (pick one for all tests going forward) and the SSD under test. Then we'll know whether they're worth the cost. Reply
  • dbt - Tuesday, November 16, 2010 - link

    Garbage collection - really for the masses? Vendor laims that it will help where TRIM support is not available are confusing me.

    Which filesystems does garbage collection support? I'll bet FAT16/32/64(exfat) are covered, NTFS as well.

    On other filesystems - how does the SSD controller know which blocks are "free" ?

    EXT4/ZFS/<anyother>FS

    ?
    Reply

Log in

Don't have an account? Sign up now