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

  • bji - Monday, March 28, 2011 - link

    You're retarded. Their systems do 'just work' according to the promised features and reliability. Just because they don't promise TRIM support, and apparently don't require it to satisfy the performance that they promise, doesn't mean that their stuff doesn't 'just work'. The fact is that end users do not need to do any of those commands to use their SSD drives as they are intended to be used.

    Not that I should even have to say this, but I don't own a single piece of Apple hardware aside from an old iPod Touch. So please don't accuse me of being a fanboy just because I can't stand ridiculous criticisms like yours. I would defend any company against such drivel.
  • Vidmar - Monday, March 28, 2011 - link

    Wait a minute...
    "Their systems do 'just work' according to the promised features and reliability."
    "I don't own a single piece of Apple hardware aside from an old iPod Touch"

    So how can you quantify the first statement if you don't own any?
  • bji - Monday, March 28, 2011 - link

    So how many Apple devices do I have to own before I can say whether or not they 'just work'? 10? 100? A million? All of them?

    Obviously there is no answer to that question that makes any sense; because the question doesn't make any sense.

    I was not talking about the actual fact of whether or not any particular Apple device 'just works', I was talking about the question of whether or not the claim that Apple products 'just work' is an any way refuted by the original poster's dumb post. I don't need to ever have touched an Apple product to be able to argue about how those comments did not refute any of the claims that Apple may make directly or indirectly about their products.

    Here is a simplified example if this is too hard for you to follow:

    Poster A: Look at these instructions on how to replace the heating elements of my toaster with a miniature nuclear reactor core! The are so long and complicated! I can't believe that my toaster manufacturer claimed that this toaster was easy to use!!!

    Me: That's dumb, the manufacturer never claimed that installing aftermarket parts on your toaster would be easy; that has nothing to do with the ease-of-use of a toaster. By the way I do own an electric razor made by your toaster company but that doesn't mean I'm biased towards them.

    You: How do you know whether or not his toaster is really easy to use if you don't own one?
  • B3an - Tuesday, March 29, 2011 - link

    You call me a retard, yet you dont even have ANY first hand experience with OSX.
    I think you're the retard here.

    It's not just about TRIM, it's with many things about Apple products. Hardware and software. All Apple do is falsely advertise and claim that everything they make just works, and is immune to viruses, even though OSX is the most unsecure major OS around.
    It can also be argued that if Apple are going to use SSD's in there products, then they should atleast fully support TRIM, which is something that is needed for an SSD to perform at it's best.
  • sean.crees - Tuesday, March 29, 2011 - link

    They do fully support TRIM. For SSD's that ship with their products. This isn't just an SSD thing though, they have always been this way with hardware, only fully supporting hardware that they personally sell. It does have it's advantages though. You may not personally like it, but Apples approach to hardware and software does have its advantages over the way it's done in the PC world.
  • marraco - Tuesday, March 29, 2011 - link

    Apple pretends to be user friendlier than Windows, yet each non basic troubleshooting ever takes a boatload of console commands, hex editors, rebooting into console mode, and crap like it.
  • Brian Klug - Monday, March 28, 2011 - link

    I've taken the plunge and am running TRIM (via the hex-edited kext) on my 2011 MBP with Vertex 2. If this drive randomly implodes, I'm sure someone will get a stern emailing about it ;)

  • Anand Lal Shimpi - Monday, March 28, 2011 - link

    I think there's a lot of misunderstanding about what TRIM really does. TRIM simply passes information to the controller - it just says "hey controller, I don't need these LBAs anymore so you can do what you will with them".

    The controller then chooses what to do with those LBAs given its internal policies.

    The alternative would be to use aggressive idle time garbage collection. I'm not personally a fan of this as it does burn up p/e cycles vs. more conservatively running through garbage collection routines when necessary.

    TRIM really does help keep performance high. Until we get filesystems that are NAND-aware, it's the best option we have.

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

    What is a filesystem that is 'NAND-aware' other than one that knows how to tell the underlying device that it's done with a block, i.e., issue a TRIM command?
  • jcompagner - Tuesday, March 29, 2011 - link

    Then please tell me,
    if trim didn't tell the ssd that it doesn't need that block, what can garbage collect do then?

    So i write the drive completely full. then i delete half of it without trim.
    Now i don't do anything, what can then a GC do? Nothing.. because as far as the ssd concern everything is still valid real data.

    Only when i then start writing on places where the ssd thought that was written it knows that it can write there again..

    If you keep your trash out of the the garbage bin then you can empty your bin all the time you want but the garbage is not cleared.

Log in

Don't have an account? Sign up now