The Intel SSD 320 Review: 25nm G3 is Finally Here
by Anand Lal Shimpi on March 28, 2011 11:08 AM EST- Posted in
- IT Computing
- Storage
- SSDs
- Intel
- Intel SSD 320
It's called the Intel SSD 320, but the part number should give away just what we're looking at here:
This is the long awaited third generation Intel based SSD. This is the G3. And at this point it's around 6 months late.
Back then it was simply called the Postville Refresh on Intel's roadmaps (Postville was the 34nm Intel X25-M G2). It would use 25nm Intel NAND, feature improved performance and full disk encryption - all behind a 3Gbps SATA interface.
When I spoke with Intel about the drive last year, all indications pointed to it being faster than drives based on SandForce's SF-1200 controller. And it is:
| Intel SSD 320 300GB vs. Corsair Force F120 | ||||
| AT Storage Bench 2011 (Heavy) | AT Storage Bench 2011 (Light) | |||
| Corsair Force F120 | 120.1 MB/s | 155.9 MB/s | ||
| Intel SSD 320 300GB | 132.8 MB/s | 161.7 MB/s | ||
Without turning to any real time compression/deduplication techniques, Intel has built a drive that's faster than the SF-1200. You also get that famed Intel SSD reliability:
There's just one issue. The SF-1200 was the king of 2010. This year is shaping up to be all about the SF-2200 and the G3 isn't quite as competitive there. Intel realized this as well and thus we got the Intel SSD 510 to address the high performance market. Intel claims the 510 should have the same failure rate as the 34nm X25-M G2 at ~0.6% per year.
The Intel SSD 320 by comparison is aimed at the mainstream market. Remember that's what the M in X25-M always stood for to begin with. As a result we get lower pricing:
| Intel SSD Comparison | ||||||||||||
| X25-M G2 160GB | Intel SSD 320 40GB | Intel SSD 320 80GB | Intel SSD 320 120GB | Intel SSD 320 160GB | Intel SSD 320 300GB | Intel SSD 320 600GB | SSD 510 120GB | SSD 510 250GB | ||||
| User Capacity | 149GB | 37GB | 74GB | 111GB | 149GB | 279GB | 558GB | 111GB | 232GB | |||
| Random Read Performance | Up to 35K IOPS | Up to 30K IOPS | Up to 38K IOPS | Up to 38K IOPS | Up to 39K IOPS | Up to 39.5K IOPS | Up to 39.5K IOPS | Up to 20K IOPS | Up to 20K IOPS | |||
| Random Write Performance | Up to 8.6K IOPS | Up to 3.7K IOPS | Up to 10K IOPS | Up to 14K IOPS | Up to 21K IOPS | Up to 23K IOPS | Up to 23K IOPS | Up to 8K IOPS | Up to 8K IOPS | |||
| Sequential Read Performance | Up to 250MB/s | Up to 200MB/s | Up to 270MB/s | Up to 400MB/s (6Gbps) | Up to 500MB/s (6Gbps) | |||||||
| Sequential Write Performance | Up to 100MB/s | Up to 45MB/s | Up to 90MB/s | Up to 130MB/s | Up to 165MB/s | Up to 205MB/s | Up to 220MB/s | Up to 210MB/s (6Gbps) | Up to 315MB/s (6Gbps) | |||
| Price | $404 | $89 | $159 | $209 | $289 | $529 | $1069 | $284 | $584 | |||
It's still early in the 25nm ramp, but the 25nm Intel SSD 320 is cheaper than the 34nm Intel SSD 510. The only issue is that OCZ is very competitive with its pricing as well and compared to the Vertex 2, Intel's SSD 320 isn't really any cheaper. Intel likes to maintain its 65% profit margins so even though it makes the NAND and the controller in the 320, we're unlikely to see these drives drop below competitive pricing.
Intel expects the 25nm SSD 320 to be even more reliable than the 510 or X25-M.
The Same Controller
The Intel SSD 320, like the 310 and X25-M before it, uses an Intel branded controller. Opening up the 320 reveals a near identical controller to what we saw in the 34nm X25-M G2 housing:
You'll notice the part number is identical to 2009's X25-M G2 controller. In fact, it's the same controller. Apparently the G2 controller had a number of features on-die, but not implemented in firmware. Things like full disk encryption and NAND redundancy never made it out in G2 but are here in the 320 all thanks to new firmware. And no, G2 owners aren't getting it.
Intel's X25-M G1 Controller
Intel's X25-M G2 Controller
Intel's SSD 320 Controller
Since the controller hasn't changed, the basic architecture of the SSD hasn't changed either. Intel still doesn't store any user data in its external DRAM cache and there's still a 256KB on-die SRAM.
64MB 166MHz SDRAM
Next to the Intel controller is a 64MB 166MHz SDRAM device, now made by Hynix. You'll notice that the DRAM chip is a lot smaller than what we've seen in previous X25-M generations, despite growing in capacity. Intel actually turned to mobile SDRAM for use in the SSD 320 to help save on power. While the X25-M G1 and G2 both used a conventional 3.3V SDRAM device, Intel moved to a 1.8V mobile SDRAM chip with the 320.
Intel X25-M G1: 16MB 166MHz SDRAM
Intel X25-M G2: 32MB 133MHz SDRAM
Intel always prided itself on not storing any user data in its DRAM cache. The external DRAM is only used to cache mapping tables and serve as the controller's scratchpad. In the event of a sudden loss of power, Intel only has to commit whatever data it has in its SRAM to NAND. To minimize the amount of data loss in the event of a sudden power failure, Intel outfitted the SSD 320 with an array of six 470µF capacitors in parallel.
We've seen large capacitors on SSDs before, primarily the enterprise SandForce drives that boast a 0.09F supercap. Intel claims that for its design a single large capacitor isn't necessary given the minimal amount of data that's cached. It further claims that an array of multiple capacitors in parallel allows for much better reliability - if one capacitor fails the array is still useful (vs. a single point of failure in the case of the supercap).
Facebook
Twitter
RSS
194 Comments
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,
Anand
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
Anand,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 xlr8yourmac.com)"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.
Voila!
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.