Samsung SSD 845DC EVO/PRO Performance Preview & Exploring IOPS Consistency
by Kristian Vättö on September 3, 2014 8:00 AM ESTPerformance Consistency - Average IOPS
Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal defragmentation. The reason we do not 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 or cleanup routines directly impacts the user experience as inconsistent performance results in application slowdowns.
To test IO consistency, we fill a secure erased SSD with sequential data to ensure that all user accessible LBAs have data associated with them. Next we kick off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. The test is run for just over half an hour and we record instantaneous IOPS every second.
We are also testing drives with added over-provisioning by limiting the LBA range. This gives us a look into the drive’s behavior with varying levels of empty space, which is frankly a more realistic approach for client workloads.
Each of the three graphs has its own purpose. The first one is of the whole duration of the test in log scale. The second and third one zoom into the beginning of steady-state operation (t=1400s) but on different scales: the second one uses log scale for easy comparison whereas the third one uses linear scale for better visualization of differences between drives. Click the dropdown selections below each graph to switch the source data.
For more detailed description of the test and why performance consistency matters, read our original Intel SSD DC S3700 article.
The 845DC PRO is just amazing. While it only has 28% over-provisioning, the 845DC PRO is able to provide 50K IOPS while for instance Intel's SSD DC S3700 is only capable of 35K IOPS, even though both have the same over-provisioning. A part of that can come from the controller and firmware design, but it is obvious that the lower program and erase latencies of V-NAND are behind the performance. It looks like Samsung's heavy investment in 3D NAND technology is really paying off.
The 845DC EVO does very well too despite the slower TLC NAND as it is still able to achieve steady-state performance of ~10K IOPS. The impact of NAND management from higher capacity is evident since the 240GB 845DC EVO performs better than the 960GB version, although I need to run a longer test for the full review to see if the difference evens out.
The PM853T, on the other hand, is a weird case because it is considerably slower than the 845DC EVO. I asked Samsung about this and they told me that there are some differences in garbage collection and wear-leveling algorithms, which causes the performance to be bumpy at first but it should even out after about 3,000 seconds. I will confirm this in the full review.
Facebook
Twitter
RSS
31 Comments
View All Comments
LiviuTM - Wednesday, September 3, 2014 - link
Great article, Kristian.I enjoyed finding more about latency, IOPS and throughput and the relationship between them.
Keep up the good work :)
Chapbass - Wednesday, September 3, 2014 - link
I would like to echo this statement. Some of the heavy technical stuff makes my eyes glaze over at times, but this was so well written that I really got into it. Awesome article, Kristian.romrunning - Wednesday, September 3, 2014 - link
"The only difference between the 845DC EVO and PM853T is the firmware and the PM853T is geared more towards sustained workloads, which results in slightly higher random write speed (15K IOPS vs 14K IOPS)."Chart for PM853T shows 14K for Random Writes, so likely needs to be corrected.
Kristian Vättö - Wednesday, September 3, 2014 - link
Good catch, I was waiting for Samsung to send me the full data sheet for the PM853T but I never got it, so I accidentally left the 845DC EVO specs there. I've now updated it with the specs I have and with some additional commentary.JellyRoll - Wednesday, September 3, 2014 - link
The only issue with calculating performance as listed on the first page is that it assumes that the SSD works perfectly in all aspects. No ECC, no wear leveling, no garbage collection. None of these are true. Even without those factors no SSD will ever behave absolutely perfectly in every aspect at all times....anything but. That is why there is so much variation between vendors. It would be impossible to calculate performance using that method with an SSD in the real world.Kristian Vättö - Wednesday, September 3, 2014 - link
Of course real world is always different because the transfer size and queue depth are constantly changing and no SSD behaves perfectly. I mentioned that it is a hypothetical SSD and obviously no real drive would have a constant latency of 1ms or perfect transfer size scaling. The goal was to demonstrate how the metrics are related and it is easier with concrete, albeit hypothetical, examples.hrrmph - Wednesday, September 3, 2014 - link
I think you nailed it on the theoretical stuff (the relationships between the parameters), and presented it well (easy to understand).This has been bugging me for a while too, although I won't pretend to have gotten it figured out - it's just that I keep getting pickier in my lab notes and shopping specs about things like queue depth for a given size transfer for the specified performance. Leave any condition or parameter out, and the specs seem kinda useless. Leave everything in, and then I wonder which ones are pertinent to my usage scenarios.
Now, your explanation will have me questioning the manufacturer's motives for the selection of each unit of measure chosen for each listed spec. Who says this field of endeavor doesn't lead to obsession? :)
If any of the specs *are* pertinent to my usage scenarios, then I wonder which ones are *most* pertinent for which of my usage scenarios (laptop, versus general desktop, versus high powered workstation).
Any relationships that you discover or methods that you develop for the charts to help explain it better are most welcome. I know this is an over-simplification, but I would guess that most workstation users want to know:
- Is my drive limiting my performance (why did that operation stutter or lag, or why does it take so long - was it the drive)?
- Is there anything I can do about it that I can afford (mainly, what can I replace it with - new controller card, newer, better designed SSDs, better racks, cables, etc.)?
I am pleased that you are helping us out by further dissecting performance consistency / variation. I suspect that although SSDs are an order of magnitude (or more) better than HDDs at many tasks, the "devil is in the details," and that there is a reason that many SSD equipped machines still "hiccup," fairly frequently (although not nearly as often or as bad as HDD equipped machines). I also suspect that drive sub-systems are still one of the most common weaker links that is responsible for such hiccups.
I am particularly interested in the (usually) brutally difficult small file size tests. These tests seem to be able to bring even the best of machines to a crawl, and any device (ie: SSD) that can help performance on those tests seems to be very likely to be noticeable to the end user.
If you do indeed find "let downs" in performance consistency (or any other drive related performance spec), then maybe the manufacturers will work to improve upon those weaknesses until we get "buttery smooth" performance...
...or at least until we can definitively start looking at other sub-systems (compute, memory, I/O, etc.) to solve the hiccups.
My introductory courses were on 8086 computers running DOS. I don't remember them often stopping to think about anything... until I started "hitting" the disks heavily. The more things change, the more I suspect they stay the same ;)
So I keep allocating more of my budget to disks and disk sub-systems than anything else. AT's articles are thus *very* helpful in "aiming" that budget and I hope you have some revelations for us soon that show which products are worth the money.
iwod - Wednesday, September 3, 2014 - link
I have been wondering for a bit, why hasn't Enterprise switched to some other interconnect? Surely they could do PCI-E have have it directly connected to the CPU. ( Assuming they dont need those for GPU or other things ).And I have been Samsung being extremely aggressive with the web hosting market. Where Intel is lacking behind.
FunBunny2 - Wednesday, September 3, 2014 - link
"real" enterprise has been running SAS and FibreChannel for rather a long time. InfiniBand every now and again. To the extent that enterprise buys X,000 drives to parcel out to offices and such, then that's where the SATA drives go. But that's not really enterprise storage. Real enterprise SSD/flash/etc. doesn't have a list price (well, only in the sense that your car did) and I'd wager that not one of the enterprise SSD/flash companies (and no, Intel doesn't count) has ever offered up a sample to AnandTech.rossjudson - Thursday, September 4, 2014 - link
Fusion-io (and others) have been doing precisely this (PCIe connected flash storage) for a number of years. They are currently producing modules with up to 6TB of storage.