Original Link: https://www.anandtech.com/show/6553/sandisk-ultra-plus-ssd-review-256gb
SanDisk Ultra Plus SSD Review (256GB)
by Anand Lal Shimpi on January 7, 2013 9:00 AM ESTSanDisk is a household name as far as NAND storage is concerned. You can’t walk into an electronics retailer and not be bombarded with SanDisk made CompactFlash and SD cards. Rip open a tablet and you might find a SanDisk solution. Even the new $249 Cortex A15 based Chromebook uses a SanDisk iNAND device on-board. Similar to Intel/Micron, SanDisk and Toshiba jointly develop and manufacture their own NAND.
The brand is well known and its products are prevalent throughout the OEM space, but in retail SanDisk isn’t as strong as some of its competitors. Recently SanDisk has been hoping to change this with the release of several of its own branded SSDs: the SanDisk Ultra (SF-1200) and SanDisk Extreme (SF-2281).
Like many other SSD companies once married to SandForce, SanDisk also looked elsewhere for controllers. And like many of those same companies, SanDisk ended up at the same place: Marvell.
Today SanDisk is announcing the Ultra Plus SSD, based on Marvell’s SS889175 6Gbps SATA/NAND controller. We’re more familiar with the SS889174 as it’s used in drives like Plextor’s M3 and Intel’s SSD 510. The 9175 is apparently a light version of the 9174, with a big focus on reducing power consumption. The controller (or at least its implementation in the Ultra Plus) features four independent NAND channels, perhaps a key to its low power consumption.
Marvell is a lot more affordable to integrate than SandForce, plus you get direct access to firmware source and the ability to develop your own from scratch; SanDisk’s choice here makes obvious sense.
The Ultra Plus uses SanDisk’s own 19nm eX2 ABL MLC NAND. This is 2-bit MLC NAND with a twist: there’s a portion of the NAND array that operates in an SLC or pseudo-SLC mode. SanDisk calls this its nCache, and the firmware can define how much of the NAND is used as an nCache. Given that the drive appears as a binary capacity to the OS, I’m assuming the total space used as the nCache fits within the ~7% spare area the firmware gets by default.
Small file writes are sent to the nCache to keep performance high, and idle time garbage collection likely dumps the nCache out to the much larger MLC array. The nCache was typically used as a way around having to use DRAM for data structure storage, but in the case of the Ultra Plus you get both: nCache + DRAM. I’m not sure there’s enough of an nCache in the Ultra Plus to make a big enough difference to justify the decision in this case.
SanDisk sent us a 256GB Ultra Plus, which was equipped with 128MB of Samsung DDR2-800 DRAM in a single package. There are four SanDisk NAND packages on the extremely small PCB (64GB per package, 8 x 8GB die per package).
The MSRPs SanDisk quoted us seem relatively competitive with other value drives on the market today:
SSD Pricing Comparison - 1/6/13 | |||||
Total System Power | 60/64GB | 120/128GB | 240/250256GB | ||
Corsair Neutron | $120 | ||||
Corsair Neutron GTX | $135 | $230 | |||
Intel SSD 335 | $78 (SSD 330) | $125 (SSD 330) | $180 | ||
Plextor M5 Pro | $125 | $210 | |||
Plextor M5S | $50 | $108 | |||
Samsung SSD 840 | $100 | $180 | |||
Samsung SSD 840 Pro | $100 | $140 | $250 | ||
SanDisk Extreme | $114 | $210 | |||
SanDisk Ultra Plus | $75 | $110 | $220 |
At the lower end of the market it’s tough to be significantly cheaper than the competition without a full process node advantage. SSD prices can be very volatile so you’re more likely to see these prices range a bit depending on supply in the channel and whatever rebates may be offered. These numbers at least tell us where SanDisk is aiming in the market.
Random Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.
Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). I perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.
The Ultra Plus gets off to a good start, doing very well in our low queue depth random read test, bested only by Samsung's SSD 840 Pro out of our list of contenders here.
Random write performance is pretty good but the Ultra Plus doesn't hit any of the insanely high speeds set by most of the modern drives. Note that its performance is equal to the Samsung SSD 830, which was a favorite of ours. Not having a first class showing here isn't a huge problem.
Many of you have asked for random write performance at higher queue depths. What I have below is our 4KB random write test performed at a queue depth of 32 instead of 3. While the vast majority of desktop usage models experience queue depths of 0 - 5, higher depths are possible in heavy I/O (and multi-user) workloads:
We don't see much scaling with higher queue depths, likely a limit of the Marvell SS889175's 4-channel implementation here.
Steady State 4KB Random Write Performance
SanDisk has a completely separate division that handles enterprise drives, but I was curious to see what steady state 4KB random write performance using a 100% LBA span would look like. To find out I borrowed from our Enterprise Storage tests and compared to the results from our OCZ Vector review. Note that many of these drives are enterprise focused and as a result do much better so don't get too turned off by the comparison:
The Ultra Plus fares much better than I expected, nipping at the heels of the Vertex 4. The Vertex 4 used similar Marvell silicon so I'm not too surprised here.
Sequential Read/Write Speed
To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.
Like most drive vendors looking to address the light use client market, SanDisk's sequential read performance is actually really good.
Low queue depth sequential write speed is also quite competitive, both of these will help deliver a pretty decent client experience.
AS-SSD Incompressible Sequential Performance
The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers.
Higher queue depth sequential IO is still very good on the Ultra Plus. There's no penalty to using incompressible data as the controller does no real time data compression/de-duplication.
Performance vs. Transfer Size
ATTO does a good job of showing us how sequential performance varies with transfer size. Most controllers optimize for commonly seen transfer sizes and neglect the rest. The optimization around 4KB, 8KB and 128KB transfers makes sense given that's what most workloads are bound by, but it's always important to understand how a drive performs across the entire gamut.
Ah that's a pretty read curve. Other than Samsung's SSD 840 Pro, none of the other vendors here deliver as good and consistent performance at smaller transfer sizes.
The write curve isn't as impressive. It starts out nicely but does lose out to the higher performers with larger transfer sizes - that 4-channel controller is likely to blame here.
Performance Consistency
In our Intel SSD DC S3700 review I introduced a new method of characterizing performance: looking at the latency of individual operations over time. The S3700 promised a level of performance consistency that was unmatched in the industry, and as a result needed some additional testing to show that. The reason we don't have consistent IO latency with SSDs is because inevitably all controllers have to do some amount of defragmentation or garbage collection in order to continue operating at high speeds. When and how an SSD decides to run its defrag and cleanup routines directly impacts the user experience. Frequent (borderline aggressive) cleanup generally results in more stable performance, while delaying that can result in higher peak performance at the expense of much lower worst case performance. The graphs below tell us a lot about the architecture of these SSDs and how they handle internal defragmentation.
To generate the data below I took a freshly secure erased SSD and filled it with sequential data. This ensures that all user accessible LBAs have data associated with them. Next I kicked off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. I ran the test for just over half an hour, no where near what we run our steady state tests for but enough to give me a good look at drive behavior once all spare area filled up.
I recorded instantaneous IOPS every second for the duration of the test. I then plotted IOPS vs. time and generated the scatter plots below. Each set of graphs features the same scale. The first two sets use a log scale for easy comparison, while the last set of graphs uses a linear scale that tops out at 40K IOPS for better visualization of differences between drives.
The high level testing methodology remains unchanged from our S3700 review. Unlike in previous reviews however, I did vary the percentage of the drive that I filled/tested depending on the amount of spare area I was trying to simulate. The buttons are labeled with the advertised user capacity had the SSD vendor decided to use that specific amount of spare area. If you want to replicate this on your own all you need to do is create a partition smaller than the total capacity of the drive and leave the remaining space unused to simulate a larger amount of spare area. The partitioning step isn't absolutely necessary in every case but it's an easy way to make sure you never exceed your allocated spare area. It's a good idea to do this from the start (e.g. secure erase, partition, then install Windows), but if you are working backwards you can always create the spare area partition, format it to TRIM it, then delete the partition. Finally, this method of creating spare area works on the drives I've tested here but not all controllers may behave the same way.
The first set of graphs shows the performance data over the entire 2000 second test period. In these charts you'll notice an early period of very high performance followed by a sharp dropoff. What you're seeing in that case is the drive alllocating new blocks from its spare area, then eventually using up all free blocks and having to perform a read-modify-write for all subsequent writes (write amplification goes up, performance goes down).
The second set of graphs zooms in to the beginning of steady state operation for the drive (t=1400s). The third set also looks at the beginning of steady state operation but on a linear performance scale. Click the buttons below each graph to switch source data.
Impact of Spare Area | |||||||
Intel SSD DC S3700 200GB | Corsair Neutron 240GB | OCZ Vector 256GB | Samsung SSD 840 Pro 256GB | SanDisk Ultra Plus 256GB | |||
Default | |||||||
25% Spare Area | - |
The Ultra Plus' performance consistency, at least in the default configuration, looks a bit better than Samsung's SSD 840 Pro. The 840 Pro is by no means the gold standard here so that's not saying too much. What is interesting however is that the 840 Pro does much better with an additional 25% spare area compared to the Ultra Plus. SanDisk definitely benefits from more spare area, just not as much as we're used to seeing.
The next set of charts look at the steady state (for most drives) portion of the curve. Here we'll get some better visibility into how everyone will perform over the long run.
Impact of Spare Area | |||||||
Intel SSD DC S3700 200GB | Corsair Neutron 240GB | OCZ Vector 256GB | Samsung SSD 840 Pro 256GB | SanDisk Ultra Plus 256GB | |||
Default | |||||||
25% Spare Area | - |
The final set of graphs abandons the log scale entirely and just looks at a linear scale that tops out at 50K IOPS. We're also only looking at steady state (or close to it) performance here:
Impact of Spare Area | |||||||
Intel SSD DC S3700 200GB | Corsair Neutron 240GB | OCZ Vector 256GB | Samsung SSD 840 Pro 256GB | SanDisk Ultra Plus 256GB | |||
Default | |||||||
25% Spare Area | - |
Here we see just how far performance degrades. Performance clusters around 5K IOPS, which is hardly good for a modern SSD. Increasing spare area helps considerably, but generally speaking this isn't a drive that you're going to want to fill.
AnandTech Storage Bench 2011
Two years ago we introduced our AnandTech Storage Bench, a suite of benchmarks that took traces of real OS/application usage and played them back in a repeatable manner. I assembled the traces myself out of frustration with the majority of what we have today in terms of SSD benchmarks.
Although the AnandTech Storage Bench tests did a good job of characterizing SSD performance, they weren't stressful enough. All of the tests performed less than 10GB of reads/writes and typically involved only 4GB of writes specifically. That's not even enough exceed the spare area on most SSDs. Most canned SSD benchmarks don't even come close to writing a single gigabyte of data, but that doesn't mean that simply writing 4GB is acceptable.
Originally I kept the benchmarks short enough that they wouldn't be a burden to run (~30 minutes) but long enough that they were representative of what a power user might do with their system.
Not too long ago I tweeted that I had created what I referred to as the Mother of All SSD Benchmarks (MOASB). Rather than only writing 4GB of data to the drive, this benchmark writes 106.32GB. It's the load you'd put on a drive after nearly two weeks of constant usage. And it takes a *long* time to run.
1) The MOASB, officially called AnandTech Storage Bench 2011 - Heavy Workload, mainly focuses on the times when your I/O activity is the highest. There is a lot of downloading and application installing that happens during the course of this test. My thinking was that it's during application installs, file copies, downloading and multitasking with all of this that you can really notice performance differences between drives.
2) I tried to cover as many bases as possible with the software I incorporated into this test. There's a lot of photo editing in Photoshop, HTML editing in Dreamweaver, web browsing, game playing/level loading (Starcraft II & WoW are both a part of the test) as well as general use stuff (application installing, virus scanning). I included a large amount of email downloading, document creation and editing as well. To top it all off I even use Visual Studio 2008 to build Chromium during the test.
The test has 2,168,893 read operations and 1,783,447 write operations. The IO breakdown is as follows:
AnandTech Storage Bench 2011 - Heavy Workload IO Breakdown | ||||
IO Size | % of Total | |||
4KB | 28% | |||
16KB | 10% | |||
32KB | 10% | |||
64KB | 4% |
Only 42% of all operations are sequential, the rest range from pseudo to fully random (with most falling in the pseudo-random category). Average queue depth is 4.625 IOs, with 59% of operations taking place in an IO queue of 1.
Many of you have asked for a better way to really characterize performance. Simply looking at IOPS doesn't really say much. As a result I'm going to be presenting Storage Bench 2011 data in a slightly different way. We'll have performance represented as Average MB/s, with higher numbers being better. At the same time I'll be reporting how long the SSD was busy while running this test. These disk busy graphs will show you exactly how much time was shaved off by using a faster drive vs. a slower one during the course of this test. Finally, I will also break out performance into reads, writes and combined. The reason I do this is to help balance out the fact that this test is unusually write intensive, which can often hide the benefits of a drive with good read performance.
There's also a new light workload for 2011. This is a far more reasonable, typical every day use case benchmark. Lots of web browsing, photo editing (but with a greater focus on photo consumption), video playback as well as some application installs and gaming. This test isn't nearly as write intensive as the MOASB but it's still multiple times more write intensive than what we were running in 2010.
As always I don't believe that these two benchmarks alone are enough to characterize the performance of a drive, but hopefully along with the rest of our tests they will help provide a better idea.
The testbed for Storage Bench 2011 has changed as well. We're now using a Sandy Bridge platform with full 6Gbps support for these tests.
AnandTech Storage Bench 2011 - Heavy Workload
We'll start out by looking at average data rate throughout our new heavy workload test:
The Ultra Plus does ok in our heavy workload, hot on the heels of Samsung's SSD 840. By no means is this the fastest drive we've tested, but it's not abysmal either. We're fans of the vanilla 840, and the Ultra Plus performed similarly. Architecturally it's a bit of a concern if Samsung's TLC drive is able to outperform your 2bpc MLC drive though.
The next three charts just represent the same data, but in a different manner. Instead of looking at average data rate, we're looking at how long the disk was busy for during this entire test. Note that disk busy time excludes any and all idles, this is just how long the SSD was busy doing something:
AnandTech Storage Bench 2011 - Light Workload
Our new light workload actually has more write operations than read operations. The split is as follows: 372,630 reads and 459,709 writes. The relatively close read/write ratio does better mimic a typical light workload (although even lighter workloads would be far more read centric).
The I/O breakdown is similar to the heavy workload at small IOs, however you'll notice that there are far fewer large IO transfers:
AnandTech Storage Bench 2011 - Light Workload IO Breakdown | ||||
IO Size | % of Total | |||
4KB | 27% | |||
16KB | 8% | |||
32KB | 6% | |||
64KB | 5% |
Performance doesn't change too much with our lighter workload. The Ultra Plus ends up towards the lower end of the middle of the pack.
TRIM Functionality
Over time SSDs can get into a fairly fragmented state, with pages distributed randomly all over the LBA range. TRIM and the naturally sequential nature of much client IO can help clean this up by forcing blocks to be recycled and as a result become less fragmented. Leaving as much free space as possible on your drive helps keep performance high (20% is a good number to shoot for), but it's always good to see how bad things can get before the GC/TRIM routines have a chance to operate. As always I filled all user addressible LBAs with data, wrote enough random data to the drive to fill the spare area and then some, then ran a single HD Tach pass to visualize how slow things got. Honestly this is just another way of looking at the performance consistency data, but we also use it to verify TRIM functionality:
Worst case performance can definitely suffer, which is exactly what we saw in the performance consistency data earlier. The solution here, as always, is to keep as much free space on the drive as possible.
TRIM is functional as expected.
Power Consumption
Given SanDisk's OEM exposure, power consumption is a big deal. The Ultra Plus does pretty well across the board here. There's excellent power consumption in the 4KB random write test, but the performance is also half of what a lot of the other drives can do. Either way, the Ultra Plus would be fine in a notebook.
Final Words
The Ultra Plus isn't the fastest drive we've ever tested, and most other drives in its price range tend to deliver better performance. Worst case performance consistency isn't great but it's better than Samsung's SSD 840 Pro, so you're going to want to leave at least 25% of the drive free in order to avoid annoying performance variation. The drive's redeeming qualities are basically that it is still a decent performer (way better than a hard drive), and is reasonably low power. The drive PCB itself is very small, potentially paving the way for some interesting, smaller-than-2.5" form factors.
The SanDisk brand likely means something here as well. Any company that has to supply to major OEMs has to have good validation and qualification methods in place, which I'd hope translates into good reliability for the Ultra Plus.
Overall the Ultra Plus is a tough drive to recommend over other similarly priced SSDs simply because it doesn't perform as well as its competitors same price class. If low power is a concern however, the Ultra Plus may fit the bill if you have a niche application. Unlike many SSDs in the past, even though the Ultra Plus isn't the best, it's still better than a hard drive. If you can find one for significantly less than its MSRP and are looking to upgrade a light use system to an SSD, I wouldn't have a problem considering the drive. The trick would be finding an Ultra Plus that's cheaper than the Samsung SSD 840 and the Intel SSD 335, which I'm not sure will happen all that frequently.
Architecturally I'd like to see something more aggressive from SanDisk. Samsung needs another competitor and I believe SanDisk could be that competitor, but it needs to get more aggressive on pursuing performance. SanDisk already has the power side figured out, the question is whether or not it can drive performance up even higher at the same time.
Most of my experiences with SanDisk drives have been in OEM systems, and there I haven't been pleased. OEMs tend to like SanDisk thanks to its very attractive pricing and reliability track record. If the Ultra Plus' controller + firmware combination can make it to SanDisk's OEM client products, I'll be a lot happier.