Spare Area and Redundant NAND

Intel's controller is a 10-channel architecture and thus drive capacities are still a little wonky compared to the competition. Thanks to 25nm NAND we now have some larger capacities to talk about: 300GB and 600GB.

Intel sent a 300GB version of the 320 for us to take a look at. Internally the drive has 20 physical NAND devices. Each NAND device is 16GB in size and features two 64Gbit 25nm 2-bit MLC NAND die. That works out to be 320GB of NAND for a drive whose rated capacity is 300GB. In Windows you'll see ~279GB of free space, which leaves 12.8% of the total NAND capacity as spare area.

Around half of that spare area is used to keep write amplification low and for wear leveling, both typical uses of spare area. The other half is for surplus NAND arrays, a RAID-like redundancy that Intel is introducing with the SSD 320.

As SandForce realized in the development of its controller, smaller geometry NAND is more prone to failure. We've seen this with the hefty reduction in rated program/erase cycles since the introduction of 50nm NAND. As a result, wear leveling algorithms are very important. With higher densities however comes the risk of huge amounts of data loss should there be a failure in a single NAND die. SandForce combats the problem by striping parity data across all of the NAND in the SSD array, allowing the recovery of up to a full NAND die should a failure take place. Intel's surplus NAND arrays work in a similar manner.

Instead of striping parity data across all NAND devices in the drive, Intel creates a RAID-4 style system. Parity bits for each write are generated and stored in the remaining half of the spare area in the SSD 320's NAND array. There's more than a full NAND die (~20GB on the 300GB drive) worth of parity data on the 320 so it can actually deal with a failure of more than a single 64Gbit (8GB) die.

Sequential Write Cap Gone, but no 6Gbps

The one thing that plagued Intel's X25-M was its limited sequential write performance. While we could make an exception for the G1, near the end of the G2's reign as most-recommended-drive the 100MB/s max sequential write speed started being a burden(especially as competing drives caught up and surpassed its random performance). The 320 fixes that by increasing rated sequential write speed to as high as 220MB/s.

You may remember that with the move to 25nm Intel also increased page size from 4KB to 8KB. On the 320, Intel gives credit to the 8KB page size as a big part of what helped it overcome its sequential write speed limitations. With twice as much data coming in per page read it's possible to have a fully page based mapping system and still increase sequential throughput.

Given that the controller hasn't changed since 2009, the 320 doesn't support 6Gbps SATA. We'll see this limitation manifest itself as a significantly reduced sequential read/write speed in the benchmark section later.

AES-128 Encryption

SandForce introduced full disk encryption starting in 2010 with its SF-1200/SF-1500 controllers. On SandForce drives all data written to NAND is stored in an encrypted form. This encryption only protects you if someone manages to desolder the NAND from your SSD and probes it directly. If you want your drive to remain for your eyes only you'll need to set an ATA password, which on PCs is forced by setting a BIOS password. Do this on a SandForce drive and try to move it to another machine and you'll be faced with an unreadable drive. Your data is already encrypted at line speed and it's only accessible via the ATA password you set.

Intel's SSD 320 enables a similar encryption engine. By default all writes the controller commits to NAND are encrypted using AES-128. The encryption process happens in realtime and doesn't pose a bottleneck to the SSD's performance.

The 320 ships with a 128-bit AES key from the factory, however a new key is randomly generated every time you secure erase the drive. To further secure the drive the BIOS/ATA password method I described above works as well.

A side effect of having all data encrypted on the NAND is that secure erases happen much quicker. You can secure erase a SF drive in under 3 seconds as the controller just throws away the encryption key and generates a new one. Intel's SSD 320 takes a bit longer but it's still very quick at roughly 30 seconds to complete a secure erase on a 300GB drive. Intel is likely also just deleting the encryption key and generating a new one. Without the encryption key, the data stored in the NAND array is meaningless.

The Test


Intel Core i7 965 running at 3.2GHz (Turbo & EIST Disabled)

Intel Core i7 2600K running at 3.4GHz (Turbo & EIST Disabled) - for AT SB 2011, AS SSD & ATTO


Intel DX58SO (Intel X58)

Intel H67 Motherboard


Intel X58 + Marvell SATA 6Gbps PCIe

Intel H67
Chipset Drivers:

Intel + Intel IMSM 8.9

Intel + Intel RST 10.2

Memory: Qimonda DDR3-1333 4 x 1GB (7-7-7-20)
Video Card: eVGA GeForce GTX 285
Video Drivers: NVIDIA ForceWare 190.38 64-bit
Desktop Resolution: 1920 x 1200
OS: Windows 7 x64


The Same Controller Random & Sequential Performance
Comments Locked


View All Comments

  • Cow86 - Monday, March 28, 2011 - link

    Awesome, looking forward to it :)
  • adamantinepiggy - Monday, March 28, 2011 - link

    Hey Anand, your 256GB Micron/Crucial M4 results on the Vantage HDD test seem to reflect an issue I have had with several P67 motherboards. On the 6G/s ports, on certain MB's, with the Intel SATA driver, it's not running at full speed. The only way I fixed it was to revert the the Intel driver back to the Win7 MSAHCI driver and then update again back to the Intel SATA driver. Why? I have no idea, but that drive should bounce up to the 60,000+ in the Vantage HDD test.

    I noticed this issue with both a MSI and a ASUS P67 chipset MB. The 45K HHD is the exact same I got here in the Micron R&D lab before I did the MSAHCI swap and the revert back to Intel driver. The MSAHCI driver does about 55K with that drive. then the change back to the Intel driver suddenly bumps the core to 62Kish. This also affects all the other Vantage scores, but is most significantly seen with the HDD test.
  • Anand Lal Shimpi - Monday, March 28, 2011 - link

    Our Vantage scores are actually taken using a Marvell 6Gbps controller, which is why we get much lower numbers in that test than if we used a 6-series board. I'll be switching over entirely pretty soon but for the sake of comparison to older drives (not to mention owners of Marvell 6Gbps SATA controllers) I kept the older testbed as is.

    Take care,
  • nexox - Monday, March 28, 2011 - link

    """the pricing is actually the same or higher than last gen."""

    Really? The chart in the article says that a 160GB G2 is $404, and a 160GB 320 is $289. Seems like a ~40% decrease to me.
  • softdrinkviking - Monday, March 28, 2011 - link

    i think the implication was that the G2 was 2 generations ago, not last generation.
  • Zhriver - Monday, March 28, 2011 - link

    Slightly offtopic.
    Around the web i see a lot of talk about Intel finally enabling TRIM for raid 0 and 1.
    Has Anandtech looked into this yet?
  • Omid.M - Monday, March 28, 2011 - link


    I read a comment by someone regarding TRIM support in the OS:

    TRIM is an excuse for poorly designed controllers.

    The statement sounded too conclusive to be taken seriously, as I'm sure the reality is more complicated. The discussion was surrounding which 3rd party SSDs to use with OS X.

    Any comments on the validity of the statement?
  • davepermen - Monday, March 28, 2011 - link

    The truth is the reverse: A good controller can negate the need for trim. But trim is still important and should always be there. why, because it's about giving information to an ssd which it can put to good use. Not having that information is just making the life for the drive needlessly difficult.

    trim is the best way to make an os and an ssd work together in harmony, unimportant the controller. it's the way to allow the ssd what parts of the disk are used by the os and what parts aren't. a good ssd can survive without knowing that. but it's still like forcing someone to work blind, or deaf where he's not actually disabled.

    as osx doesn't support trim yet, the argument got reversed (as osx is from apple and thus perfect) => any ssd supporting trim is "cheating". this, of course will change with lion, which will bring trim. then, the argument is an ssd not having trim is stupid, as, again, osx is from apple and thus perfect. /joking.
  • beepboy - Monday, March 28, 2011 - link

    OS X do support TRIM, just gotta do these steps (thanks to

    "Subject: Third-Party TRIM SSD Support in Mac OS X
    Hello Mike. I have good news for those people still waiting for support of TRIM command for third-party Solid State Drives (in OS X). Now we have a support!

    It was tested with Intel SSD 2nd generation and OCZ Vertex and it is fully working. But for launch to work we need an IOAHCIFamily.kext (Kernel Extension) with Plugin inside called IOAHCIBlockStorage.kext where in the directory you can find a binary with the same name. This can be downloaded now from internet. This kernel extension was taken from Mac OS X 10.6.6 (10J3210) that came with MacBook Pro 2011. (not the std OS X build)

    Open it with HEX editor and search for "APPLE SSD". This is verification on "if this Solid State Drive is an Apple or not?" implemented by Apple. Simply change this 9 symbols with first 9 symbols from name of your SSD.
    (FYI - per Viktor's later mail (see below), replacing Apple SSD with all Hex zeroes is another/better option)
    Install this modified kext with kexthelper (don't forget to rebuild cache with button in kexthelper) and reboot.
    This is works on latest Mac OS X 10.6.7 and 10.7 Developer Preview.
    -Viktor D.

    I asked about any proof that trim is really working in OS X, not just the OS reporting it as supported. (Many SSDs have GC support in firmware, which has been a plus for OS X users w/o Trim support.)
    Here's his reply regarding proof of trim working.

    Ok, there are three things:

    1) Apple can do it (just show "yes") through detecting media type of Disk in System Profiler (which is more simple) instead of using for this AHCI driver. And another thing - this is all SSDs, just with different names, which all supports unified commands.

    2) IOAHCIBlockStorage.kext is not something simple. This driver (Input Output Advanced Host Controller Interface Block Storage) manages all IO for SATA Storage Devices, ie. NCQ, R/W operations, TRIM, etc.. How OS checks that TRIM is supported and works in drive? As you can see in my last message - we tested a group of disks, the ones which support TRIM natively and those which produced early that lacked TRIM support. Those disk that supported it, OS recognized. Those which lacked it OS shows "TRIM Support: No" without exception. To check - IOAHCI after detecting that this is not "rotational" disk (reports no spinning speed), it sends the TRIM commands "BuildATATrimCommand" (found inside IOAHCIBlockStoorage) to the SSD. If SSD executes this, on specific address of clusters after trimming will be zeroes like if we had a secure format with zeroes, then IOAHCI reports that command executed, and SSD supports TRIMming. If the command was ignored and not executed, OS reports that this SSD doesn't support TRIM. This command is not a process which can be monitored by Activity Monitor. It is just a command to SSD's controller which will do this work fully automatically without OS intrusion. This is the algorithm to understand "how os checks that TRIM is supported and executed".

    3) Another proof. First what we noted is reverting performance via synthetic test back to original. Another - is using "hdparm" method. Booted in linux, mount SSD with HFS, creates small file in specific place and saves the info about address of sectors that contains that file. In linux TRIM is turned off for HFS. Boot to OS X and delete this file. Back to linux - check the address - and we see only zeros. TRIM is working.
    (In theory any SSD that supports TRIM should work but he later wrote with results of more testing)
    Some more information about activated TRIM tests with other SSDs. These models tested and TRIM verified working:

    Kingston V+ SSDNow Series
    Intel X25-S/M 2nd Gen Series
    Western Digital Silicon Edge Blue Series
    OCZ Agility 2 Series
    OCZ Vertex Series
    -Viktor D."
  • B3an - Monday, March 28, 2011 - link

    All that just to get TRIM working in OSX?

    "It just works" .. yeah right, Apple.

Log in

Don't have an account? Sign up now