Inside the Vertex 2 Pro

This time there were no stickers telling me that I’d love this SSD, just a brown ESD bag and a plain looking SSD inside.

Pop the top off and you are greeted with a 90mF capacitor. Its duty is to deliver enough power to the controller to commit any buffered data to flash if there’s ever a sudden loss of power.

I asked SandForce why they needed such a large capacitor as Intel can get away with much smaller caps. It actually has to do with the amount of data buffered. Intel’s X25-M buffers somewhere in the low hundreds of KB of data (with a 512KB L2 cache I’m guessing it’s somewhere below that). The SF controllers buffer a couple of megabytes of data, hence the much larger capacitor.

SandForce did point out that the capacitor is a feature of the SF-1500 design, despite OCZ’s use of it on the Vertex 2 Pro.

That brings us to the controller used in the Vertex 2 Pro. Ultimately SandForce is going to have two controllers - the SF-1200 and the SF-1500. Currently the two controllers have a unified firmware and feature set, which is why both OCZ and SF refer to the Vertex 2 Pro as being somewhere in between a 1200 and a 1500. It’s a SF-1200 controller with the firmware of the SF-1500 as far as I can tell. The final shipping version with be a full fledged SF-1500.

The cost of the Vertex 2 Pro is going to be high. Higher than Intel’s X25-M and any other consumer level SSD on the market today. OCZ is targeting it at the very high end desktop/workstation user or perhaps even entry level enterprise customer.

We won’t see the Vertex 2 Pro available in the channel until March. But this isn’t the only SandForced based SSD we’ll get from OCZ though. At some point in the future we’ll have an SF-1200 based SSD that’s priced around the same level as the top-bin Indilinx based Vertex drives. It’s too early to talk about timing on that one though.

Capacities and Hella Overprovisioning The OCZ Toolbox
Comments Locked


View All Comments

  • blowfish - Friday, January 1, 2010 - link

    80GB? You really need that much? I'm not sure how much space current games take up, but you'd hope that if they shared the same engine, you could have several games installed in significantly less space than the sum of their separate installs. On my XP machines, my OS plus programs partitions are all less than 10GB, so I reckon 40GB is the sweet spot for me and it would be nice to see fast drives of that capacity at a reasonable price. At least some laptop makers recognise the need for two drive slots. Using a single large SSD for everything, including data, seems like extravagant overkill.
  • Gasaraki88 - Monday, January 4, 2010 - link

    Just as a FYI, Conan take 30GB. That's one game. Most new games are around 6GB. WoW takes like 13GB. 80GB runs out real fast.
  • DOOMHAMMADOOM - Friday, January 1, 2010 - link

    I wouldn't go below 160 GB for a SSD. The games in just my Steam folder alone go to 170 GB total. Games are big these days. The thought of putting Windows and a few programs and games onto an 80GB hard drive is not something I would want to do.
  • Swivelguy2 - Thursday, December 31, 2009 - link

    This is very interesting. Putting more processing power closer to the data is what has improved the performance of these SSDs over current offerings. That makes me wonder: what if we used the bigger, faster CPU on the other side of the SATA cable to similarly compress data before storing it on an X25-M? Could that possible increase the effective capacity of the drive while addressing the X25-M's major shortcoming in sequential write speed? Also, compressing/decompressing on the CPU instead of in the drive sends less through SATA, relieving the effects of the 3 GB/s ceiling.

    Also, could doing processing on the data (on either end of SATA) add more latency to retrieving a single file? From the random r/w performance, apparently not, but would a simple HDTune show an increase in access time, or might it be apparent in the "seat of the pants" experience?

    Happy new year, everyone!
  • jacobdrj - Friday, January 1, 2010 - link

    The race to the true 'Isolinear Chip' from Star Trek is afoot...
  • Fox5 - Thursday, December 31, 2009 - link

    This really does look like something that should have been solved with smarter file systems, and not smarter controllers imo. (though some would disagree)

    Reiser4 does support gzip compression of the file system though, and it's a big win for performance. I don't know if NTFS's compression is too, but I know in the past it had a negative impact, but I don't see why it wouldn't perform better if there was more cpu performance.
  • blagishnessosity - Thursday, December 31, 2009 - link

    I've wondered this myself. It would be an interesting experiment. There are (NTFS, Btrfs, ZFS and Reiser4). In windows, I suppose this could be tested by just right clicking all your files and checking "compress" and then running your benchmarks as usual. In linux, this would be interesting to test with btrfs's SSD mode paired with a low-overhead io scheduler like noop or deadline.

    What interests me the most though is SSD performance on a as they theoretically should never have random reads or writes. In the linux realm, there are several log-based filesystems (JFFS2, UBIFS, LogFS, NILFS2) though none seem to perform ideally in real world usage. Hopefully that'll change in the future :-)
  • blagishnessosity - Thursday, December 31, 2009 - link

    There are">several filesystems that support transparent compression (NTFS, Btrfs, ZFS and Reiser4).

    What interests me the most though is SSD performance on a">Log-based filesystem as they theoretically should never have random reads or writes.

    (note to web admin: the comment wysiwig does not appear to work for me)
  • themelon - Thursday, December 31, 2009 - link

    Note that ZFS now also has native DeDupe support as of build 128">

  • grover3606 - Saturday, November 13, 2010 - link

    Is the used performance with trim enabled?

Log in

Don't have an account? Sign up now