Controlling Costs with no DRAM and Cheaper Flash

SandForce is a chip company. They don’t make flash, they don’t make PCBs and they definitely don’t make SSDs. As such, they want the bulk of the BOM (Bill Of Materials) cost in an SSD to go to their controllers. By writing less to the flash, there’s less data to track and smaller tables to manage on the fly. The end result is SF promises its partners that they don’t need to use any external DRAMs alongside the SF-1200 or SF-1500. It helps justify SandForce’s higher controller cost than a company like Indilinx.

By writing less to flash SandForce also believes its controllers allow SSD makers to use lower grade flash. Most MLC NAND flash on the market today is built for USB sticks or CF/SD cards. These applications have very minimal write cycle requirements. Toss some of this flash into an SSD and you’ll eventually start losing data.

Intel and other top tier SSD makers tackle this issue by using only the highest grade NAND available on the market. They take it seriously because most users don’t back up and losing your primary drive, especially when it’s supposed to be on more reliable storage, can be catastrophic.

SandForce attempts to internalize the problem in hardware, again driving up the cost/value of its controller. By simply writing less to the flash, a whole new category of cheaper MLC NAND flash can be used. In order to preserve data integrity the controller writes some redundant data to the flash. SandForce calls it similar to RAID-5, although the controller doesn’t generate parity data for every bit written. Instead there’s some element of redundancy, the extent of which SF isn’t interested in delving into at this point. The redundant data is striped across all of the flash in the SSD. SandForce believes it can correct errors at as large as the block level.

There’s ECC and CRC support in the controller as well. The controller has the ability to return correct data even if it comes back with errors from the flash. Presumably it can also mark those flash locations as bad and remember not to use them in the future.

I can’t help but believe the ability to recover corrupt data, DuraWrite technology and AES-128 encryption are somehow related. If SandForce is storing some sort of hash of the majority of data on the SSD, it’s probably not too difficult to duplicate that data, and it’s probably not all that difficult to encrypt it either. By doing the DuraWrite work up front, SandForce probably gets the rest for free (or close to it).

The Secret Sauce: 0.5x Write Amplification Capacities and Hella Overprovisioning
POST A COMMENT

102 Comments

View All Comments

  • fertilizer - Tuesday, January 05, 2010 - link

    First of all, my complements to a great article!
    It provided me with great insight!

    It seems to me that SSD manufacturers are spending a lot of time complying to the world of HDD based Operating Systems.
    Would'nt it be time to get OS's to treat a SSD differently than a HDD?
    Reply
  • j718 - Tuesday, January 05, 2010 - link

    the ocz vertex ex is an slc drive, not mlc as shown in the charts. Reply
  • j718 - Tuesday, January 05, 2010 - link

    whoops, sorry, it's just the anandtech storage bench charts that have the ex mislabeled.
    Reply
  • Donald99 - Monday, January 04, 2010 - link

    Any thoughts on potential energy use in mobile environment? Compared to intel MLC. Still better energy efficiencey than a traditional drive?
    Performance results seem uber.
    Reply
  • cliffa3 - Monday, January 04, 2010 - link

    Anand,

    Great article, will be an interesting technology to watch and see how mature it really is.

    Question on the timeline for the price drop: When you said 'we'll see 160GB down at $225', were you talking about the mid-year refresh or the end of year next-gen?
    Reply
  • MadMan007 - Monday, January 04, 2010 - link

    Is it just me or is it inaccurate to mix GB and GiB when calculating overprovisioning at the bottom of page 5? By my reckoning the overprovisioning should be 6.6% (64GB/60GB, 128GB/120GB) not double that from using (64GB/55.9GiB etc) Reply
  • vol7ron - Monday, January 04, 2010 - link

    Anand, the right column of the table should be marked as GiB.

    The last paragraph should take that into consideration. Either the second column should first be converted into GiB, or if it already is (and hard to believe it is), then you could do direct division from there.

    The new table:
    Adv.(GB) Tot.(GB) Tot.(GiB) User(GiB)
    50 64 59.6 46.6
    100 128 119.2 93.1
    200 256 238.4 186.3
    400 512 476.8 372.5

    The new percentages should be:
    (59.6-46.6) / 59.6 x 100 = 21.8% decrease
    (119.2-93.1) / 119.2 x 100 = 21.9% decrease
    (238.4-186.3) / 238.4 x 100 = 21.9% decrease
    (476.8-372.5) / 476.8 x 100 = 21.9% decrease


    And the second table:
    Adv.(GB) Tot.(GB) Tot.(GiB) User(GiB)
    60 64 59.6 55.9
    120 128 119.2 111.8
    240 256 238.4 223.5
    480 512 476.8 447

    The new percentages should be:
    (59.6-55.9) / 59.6 x 100 = 6.21% decrease
    (119.2-111.8) / 119.2 x 100 = 6.21% decrease
    (238.4-223.5) / 238.4 x 100 = 6.25% decrease
    (476.8-447) / 476.8 x 100 = 6.25% decrease


    Note, I did not use significant figures, so all numbers are approximated, yet suitable - the theoretical value may be slightly different.


    vol7ron
    Reply
  • vol7ron - Monday, January 04, 2010 - link

    Anand, the right column of the table should be marked as GiB.

    The last paragraph should take that into consideration. Either the second column should first be converted into GiB, or if it already is (and hard to believe it is), then you could do direct division from there.

    The new table:
    Adv.(GB) Tot.(GB) Tot.(GiB) User(GiB)
    50 64 59.6 46.6
    100 128 119.2 93.1
    200 256 238.4 186.3
    400 512 476.8 372.5

    The new percentages should be:
    (59.6-46.6) / 59.6 x 100 = 21.8% decrease
    (119.2-93.1) / 119.2 x 100 = 21.9% decrease
    (238.4-186.3) / 238.4 x 100 = 21.9% decrease
    (476.8-372.5) / 476.8 x 100 = 21.9% decrease


    And the second table:
    Adv.(GB) Tot.(GB) Tot.(GiB) User(GiB)
    60 64 59.6 55.9
    120 128 119.2 111.8
    240 256 238.4 223.5
    480 512 476.8 447

    The new percentages should be:
    (59.6-55.9) / 59.6 x 100 = 6.21% decrease
    (119.2-111.8) / 119.2 x 100 = 6.21% decrease
    (238.4-223.5) / 238.4 x 100 = 6.25% decrease
    (476.8-447) / 476.8 x 100 = 6.25% decrease


    Note, I did not use significant figures, so all numbers are approximated, yet suitable - the theoretical value may be slightly different.


    vol7ron
    Reply
  • Guspaz - Sunday, January 03, 2010 - link

    Your pricing estimates for Intel's refreshes worry me, and I worry that you're out of touch with SSD pricing.

    Intel's G2 x25-m 160GB drive currently sells for $500-550, so claims that Intel will be selling 600GB drives at the same price point raise some eyebrows.
    Reply
  • kunedog - Monday, January 04, 2010 - link

    I couldn't help but roll my eyes a little when I saw that Anand was again making Intel SSD pricing predictions. Even the G1 X-25Ms skyrocketed above his predictions for the G2s:
    http://www.anandtech.com/storage/showdoc.aspx?i=36...">http://www.anandtech.com/storage/showdoc.aspx?i=36...

    And the G1s are still higher at Newegg (the G2s are still a LOT higher). Anand has never acknowledged the stratospheric X-25M G2 pricing and how dead wrong his predictions were. He's kept us updated on negative aspects like the firmware bugs, slow stock/availability of G2s, and lack of TRIM for G1s, but never pricing.
    Reply

Log in

Don't have an account? Sign up now