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.

This is to the X25-M G2 what Vista was to XP. It's a, "don't buy unless you have to" situation.

OCZ/SandForce have to be laughing - Intel is in shambles. First, SSD delays, then Mobo chipset recalls, then Chandra Anand quits, and now this crap.

Sure, their SSD is still reliable and it's not a bad product, but the pricing isn't even that great. Maybe they don't need to implement the SF-2k series algorithm, but some sort of compression engine would be nice. Claiming powerout reliability is like saying, "we just don't know how to make these capacitors hold a charge." Honestly, I don't care if you have to add a backup NiCad battery. Sure Intel has had reliability down, but they've had over a year to work on speed - this is akin to the Western Digital SSD release; of course it's much more attractive, but it's the reliability vs speed situation.

Who knows, maybe Intel's laughing at us just as hard as OCZ is laughing at them.Reply

Okay, maybe a little bit of exaggeration, but this wasn't a strong release and they've had their large share of problems lately - don't you think?

x86 will have a tough time dealing with RISC. I think RISC is just a better technology, since it doesn't have to deal with legacy instructions. That translates to performances and power efficiencies.

While Intel does still have some room to shrink the die, there isn't much room with current technologies. Also, the ARM chips will continue to decrease in die shrinks as well. That being said, there was some evidence that there could be a cheap alternative to Silicon on the horizon, which would allow for smaller theoretical components. (http://www.dailytech.com/Researchers+Claim+Molybde...

The way I see it, this is similar to when Intel moved the mem controller of the chipset and onto the die. They could have done it sooner, but they are good at extracting $$ from their customers. They reached the high clock rate track and had re-think their position.

While Intel may not be in shambles per se, in its current state, Intel has dished out a lot of debt, they haven't done too well with their NVidia relationship, and they're struggling in the mobile space. And I think AMD is still the better choice on the server front, if I recall correctly. This is all going on while their CEO is on the Obama's Job Council, which I still say that was probably not the best decision.

So, for a company that's been ahead for the last few years, they still have some short-term capabilities, but it's the long term that's important. They need to be successful in breaking into and building a new market segment (Mobile/HTPCs/SSDs).Reply

Right now intel has to at very least TRY to hold on to x86 because they only have one competitor in this area, a competitor is severely limited compared to intel, which means huge profits. Intel could easily license the arm architecture and produce an soc that'd blow the everything out of the water. The reason I'm saying this is their manufacturing capabilities are the best in the world which means a LOT for producing microprocessors and currently their cpu's are just a RISC design that translates x86 instructions, so they'd really not even have to hire new engineers. Although then that means a loss in confidence in x86 and could lead to a transition to the arm architecture which they don't control. They probably know x86 isn't going to make it forever, but holding on to it for now is extremely profitable. We'll see how crafty they can get in shoehorning x86 into the mobile arena and that should truly decide how much longer x86 will be around. Intel can easily stand on their manufacturing capabilities and the insanely talented engineers they employ to compete in any up and coming markets, but it's just in their best interest to try and keep x86 dominance for now. Reply