Intel SSD 750 PCIe SSD Review: NVMe for the Client
by Kristian Vättö on April 2, 2015 12:00 PM ESTRandom Read Performance
One of the major changes in our 2015 test suite is the synthetic Iometer tests we run. In the past we used to test just one or two queue depths, but real world workloads always contain a mix of different queue depths as shown by our Storage Bench traces. To get the full scope in performance, I'm now testing various queue depths starting from one and going all the way to up to 32. I'm not testing every single queue depth, but merely how the throughput scales with the queue depth. I'm using exponential scaling, meaning that the tested queue depths increase in powers of two (i.e. 1, 2, 4, 8...).
Read tests are conducted on a full drive because that is the only way to ensure that the results are valid (testing with an empty drive can substantially inflate the results and in reality the data you are reading is always valid rather than full of zeros). Each queue depth is tested for three minutes and there is no idle time between the tests.
I'm also reporting two metrics now. For the bar graph, I've taken the average of QD1, QD2 and QD4 data rates, which are the most relevant queue depths for client workloads. This allows for easy and quick comparison between drives. In addition to the bar graph, I'm including a line graph, which shows the performance scaling across all queue depths. To keep the line graphs readable, each drive has its own graph, which can be selected from the drop-down menu.
I'm also plotting power for SATA drives and will be doing the same for PCIe drives as soon as I have the system set up properly. Our datalogging multimeter logs power consumption every second, so I report the average for every queue depth to see how the power scales with the queue depth and performance.
Despite having NVMe, the SSD 750 doesn't bring any improvements to low queue depth random read performance. Theoretically NVMe should be able to improve low QD random read performance because it adds less overhead compared to the AHCI software stack, but ultimately it's the NAND performance that's the bottleneck, although 3D NAND will improve that by a bit.
 |
|||||||||
The performance does scale nicely, though, and at queue depth of 32 the SSD 750 is able to hit over 200K IOPS. It's capable of delivering even more than that because unlike AHCI, NVMe can support more than 32 commands in the queue, but since client workloads rarely go above QD32 I see no point in test higher queue depths just for the sake of high numbers.
Random Write Performance
Write performance is tested in the same way as read performance, except that the drive is in a secure erased state and the LBA span is limited to 16GB. We already test performance consistency separately, so a secure erased drive and limited LBA span ensures that the results here represent peak performance rather than sustained performance.
In random write performance the SSD 750 dominates the other drives. It seems Intel's random IO optimization really shows up here because the SM951 doesn't even come close. Obviously the lower latency of NVMe helps tremendously and since the SSD 750 features full power loss protection it can also cache more data in DRAM without the risk of data loss, which yields substantial performance gains.
 |
|||||||||
The SSD 750 also scales very efficiently and doesn't stop scaling until queue depth of 8. Note how big the difference is at queue depths of 1 and 2 -- for any random write centric workload the SSD 750 is an absolute killer.
Facebook
Twitter
RSS
132 Comments
View All Comments
magreen - Thursday, April 2, 2015 - link
darkgreen, are you talking about a G1 without TRIM or a G2 with TRIM support?darkgreen - Friday, April 3, 2015 - link
I had a G1 without TRIM. The Intel fix was based on some ancient shareware (FreeDOS!) that wouldn't work with many modern motherboards and in some cases left drives bricked. It was well reported at the time (see my comment above for a google search that returns articles), but lots of people wound up with X25-Ms that were useless. If you weren't an enterprise customer the Intel response was "tough luck." No refunds, no replacements, nothing. In all fairness I'm sure Intel would love to be able to support consumers, but they probably aren't set up for it in their storage area because it's just not a big area of their business bottom line.magreen - Sunday, April 5, 2015 - link
Yeah, it seems like the G1 owners got screwed. (I have a G2 and G3 and they've both been great. Sorry they screwed the early adopters.)In Anand's words from 2009 when the G2 was released:
"TRIM isn’t yet supported, but the 34nm drives will get a firmware update when Windows 7 launches enabling TRIM. XP and Vista users will get a performance enhancing utility (read: manual TRIM utility). It seems that 50nm users are SOL with regards to TRIM support. Bad form Intel, very bad form."
http://anandtech.com/show/2806
"Overall the G2 is the better drive but it's support for TRIM that will ultimately ensure that. The G1 will degrade in performance over time, the G2 will only lose performance as you fill it with real data. I wonder what else Intel has decided to add to the new firmware...
I hate to say it but this is another example of Intel only delivering what it needs to in order to succeed. There's nothing that keeps the G1 from also having TRIM other than Intel being unwilling to invest the development time to make it happen. I'd be willing to assume that Intel already has TRIM working on the G1 internally and it simply chose not to validate the firmware for public release (an admittedly long process). But from Intel's perspective, why bother?
Even the G1, in its used state, is faster than the fastest Indilinx drive. In 4KB random writes the G1 is even faster than an SLC Indilinx drive. Intel doesn't need to touch the G1, the only thing faster than it is the G2. Still, I do wish that Intel would be generous to its loyal customers that shelled out $600 for the first X25-M. It just seems like the right thing to do. Sigh."
http://www.anandtech.com/show/2829/11
Redstorm - Thursday, April 2, 2015 - link
Could you elaborate on this (although there appears to be an NVMe version too after all) of the SM951. As looking at the numbers if NVMe even slightly improves the SM951 it would make it a better choice, and the form factor being M.2 makes it much more attractive.Kristian Vättö - Thursday, April 2, 2015 - link
Ganesh received an NVMe version of the SM951 inside a NUC and I've also heard from other sources that it exists. No idea of its retail availability, though, as RamCity hadn't heard about it until I told them.eddieobscurant - Thursday, April 2, 2015 - link
if i'm not wrong the nvme version has p/n MZVPV256HDGL-00000 for the 256gb model while the ahci version has p/n MZHPV256HDGL-00000Redstorm - Friday, April 3, 2015 - link
Thanks looks promising , found this with verbage suposidly from RAMCity that they will ship in May.http://translate.google.co.nz/translate?hl=en&...
Redstorm - Friday, April 3, 2015 - link
So no real proof that they exist then.eddieobscurant - Thursday, April 2, 2015 - link
Kristian, there is a DRAM difference between the two models. The 400gb has 1gb DRAM while the 1.2tb model has 2gb. Do you think it plays a big role in terms of performance between the two models.Also is there a way to reduce the overprovision in these drives? I would prefer 80gb more on the 400gb model over less consistency.
When will you review the kingston hyperX predator, and when will samsung release the sm951 nvme? Q3 or sooner?
KAlmquist - Thursday, April 2, 2015 - link
The 400gb model shouldn't need as much DRAM because it has fewer pages to keep track of. But there's no way to know how the 400gb model will perform until Intel sends out samples for review.