The Intel SSD 600p (512GB) Review
by Billy Tallis on November 22, 2016 10:30 AM ESTAnandTech Storage Bench - The Destroyer
The Destroyer is an extremely long test replicating the access patterns of very IO-intensive desktop usage. A detailed breakdown can be found in this article. Like real-world usage and unlike our Iometer tests, the drives do get the occasional break that allows for some background garbage collection and flushing caches, but those idle times are limited to 25ms so that it doesn't take all week to run the test.
We quantify performance on this test by reporting the drive's average data throughput, a few data points about its latency, and the total energy used by the drive over the course of the test.
The average data rate sustained by the 600p on The Destroyer shows that the drive is almost entirely limited by the speed of the 3D TLC NAND, and it is barely any faster than the Crucial MX300 that uses the same NAND.
The average service time of the 600p is much lower than most TLC SSDs, so the NVMe PCIe interface is providing some latency benefit even when the drive's throughput doesn't need anything faster than SATA. The 600p is still only as good as a mid-range MLC SATA SSD and doesn't come close to the low latency of high-end NVMe drives.
The number of high latency outliers above the 10ms threshold and above 100ms tells two quite different stories. The 600p is as good as most MLC SATA drives at completing most of its operations in under 10ms, but when the drive stalls, it does so as severely as a budget TLC SATA SSD.
Operating a PCIe 3.0 x4 link requires quite a bit more power than a SATA link, so most PCIe SSDs start at a disadvantage in power consumption and make up for it by completing the test fast enough that the total energy used is not higher than is typical for SATA SSD. The 600p doesn't complete The Destroyer any quicker than a SATA SSD and the 40nm fab process used by the SM2260 controller doesn't do it any favors here either.
Facebook
Twitter
RSS
63 Comments
View All Comments
ddriver - Tuesday, November 22, 2016 - link
A fool can dream James, a fool can dream...He also wants to live in a really big house made of cards and bathe in dry water, so his hair don't get wet :D
Kevin G - Wednesday, November 23, 2016 - link
Conceptually a PCIe bridge/NVMe RAID controller could implement additional PCIe lanes on the drive side for RAID5/6 purposes. For example, 16 lanes to the bridge and six 4 lane slots on the other end. There is still the niche in the server space where reliability is king and having removable and redundant media is important. Granted, this niche is likely served better by U.2 for hot swap bays than M.2 but they'd use the same conceptual bridge/RAID chip proposed here.vFunct - Wednesday, November 23, 2016 - link
> However WHY would you want to do that when you could just go get an Intel P3520 2TB drive or for higher speed a P3700 2TB drive.Those are geared towards database applications (and great for it, as I use them), not media stores.
Media stores are far more cost sensitive.
jjj - Tuesday, November 22, 2016 - link
And this is why SSD makers should be forced to list QD1 perf numbers, it's getting ridiculous.powerarmour - Tuesday, November 22, 2016 - link
I hate TLC.Notmyusualid - Tuesday, November 22, 2016 - link
I'll second that.ddriver - Tuesday, November 22, 2016 - link
Then you will love QLCBrokenCrayons - Wednesday, November 23, 2016 - link
I'm not a huge fan either, but I was also reluctant to buy into MLC over much more durable SLC despite the cost and capacity implications. At this point, I'd like to see some of these newer, much more durable solid state memory technologies that are lurking in labs find their way into the wider world. Until then, TLC is cheap and "good enough" for relatively disposable consumer electronics, though I do keep a backup of my family photos and the books I've written...well, several backups since I'd hate to lose those things.bug77 - Tuesday, November 22, 2016 - link
The only thing that comes to mind is: why, intel, why?milli - Tuesday, November 22, 2016 - link
Did you test the MX300 with the original firmware or the new firmware?