Samsung SSD XP941 Review: The PCIe Era Is Here
by Kristian Vättö on May 15, 2014 12:00 PM ESTPerformance Consistency
Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal defragmentation. The reason we don’t have consistent IO latency with SSD 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 buttons 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.
 |
|||||||||
| Samsung SSD XP941 | Plextor M6e | Samsung SSD 840 Pro | SanDisk Extreme II | Samsung SSD 840 EVO mSATA | |||||
| Default | |||||||||
| 25% Spare Area | |||||||||
The interface has never been the bottleneck when it comes to random write performance, especially in steady-state. Ultimately the NAND performance is the bottleneck, so without faster NAND we aren't going to see any major increases in steady-state performance.
The graphs above and below illustrate this as the XP941 isn't really any faster than the SATA 6Gbps based 840 Pro. Samsung has made some tweaks to their garbage collection algorithms and overall the IO consistency gets a nice bump over the 840 Pro but still, this is something we've already seen with SATA 6Gbps SSDs. I wouldn't say the IO consistency is outstanding because the Plextor M6e does slightly better with the default over-provisioning (both drives have ~7%) but if you increase the over-provisioning the XP941 will show its magic.
 |
|||||||||
| Samsung SSD XP941 | Plextor M6e | Samsung SSD 840 Pro | SanDisk Extreme II | Samsung SSD 840 EVO mSATA | |||||
| Default | |||||||||
| 25% Spare Area | |||||||||
 |
|||||||||
| Samsung SSD XP941 | Plextor M6e | Samsung SSD 840 Pro | SanDisk Extreme II | Samsung SSD 840 EVO mSATA | |||||
| Default | |||||||||
| 25% Spare Area | |||||||||
TRIM Validation
Update 5/20: I got an email from one of our readers suggesting that the TRIM issue might be related to Windows 7 and that Windows 8 should have functioning TRIM for PCIe SSDs. To try this, I installed Windows 8.1 to a secondary drive and ran our regular pre-conditioning (fill with sequential data and torture with 4KB random write for 60 minutes). To measure performance, I had to rely on Iometer as HD Tach didn't work properly under Windows 8. I ran the same 128KB sequential write test that we usually run (QD=1, 100% LBA) but extended the length to 10 minutes to ensure that the results are steady and not affected by burst performance.
| Samsung SSD XP941 512GB - Iometer 128KB Sequential Write (QD1) | ||
| Clean | After TRIM | |
| Samsung SSD XP941 512GB | 607.7 MB/s | 598.9 MB/s |
And TRIM seems to function as it should, so it indeed looks like this is just a Windows 7 limitation, which is excellent news.
------------------------
To test TRIM, I took a secure erased XP941 and filled it with sequential data, followed by a 60-minute torture with 4KB random writes (QD32). After the torture, I TRIM'ed all user-accessible LBAs and ran HD Tach to produce the graph below:
It looks like TRIM isn't functional, although I'm not that surprised. I'm waiting to hear back from Samsung about whether this is a limitation in the operating system because I've heard that Windows doesn't treat PCIe drives the same even if they utilize the same AHCI software stack like the XP941 does. If that's true, we'll need either updates to Windows or some other solution.
In a Mac TRIM support is listed as "yes" when TRIM is enabled for third party drives using TRIM Enabler, though I didn't have the time to verify if it actually works.
Facebook
Twitter
RSS
110 Comments
View All Comments
McTeags - Thursday, May 15, 2014 - link
I think there is a spelling mistake in the first sentence. Did you mean SATA instead of PATA? I don't know all of the tech lingo so maybe I'm mistaken.McTeags - Thursday, May 15, 2014 - link
Please disregard my comment. I googled it...BMNify - Thursday, May 15, 2014 - link
sata-e[serial], sata[serial], pata[parrallel] ,SCSI [several, and chainable to 15+ drives on one cable, we should have used that as generic] ,shugart these are all drive interfaces and there are more too going back in the day....metayoshi - Thursday, May 15, 2014 - link
"It's simply much faster to move electrons around a silicon chip than it is to rotate a heavy metal disk."While SSD performance blows HDDs out of the water, the quoted statement is technically not correct. If you take a single channel NAND part and put it up against today's mechanical HDDs, the HDD will probably blow the NAND part out of the water in everything except for random reads.
What really kills HDD performance isn't the just rotational speed as much as it is the track-to-track seek + rotational latency of a random workload. A sequential workload will reduce the seek and rotational latency so much that the areal density of today's 5 TB HDDs will give you pretty good numbers. In a random workload however, the next block of data you want to read is most likely on a different track, different platter, and different head. Now it has to seek the heads to the correct track, perform a head switch because only 1 head can be on at a time, and then wait for the rotation of the disk for that data block to be under the head.
A NAND part with a low number of channels will give you pretty crappy performance. Just look at the NAND in smartphones and tablets of today, and in the SD cards and USB thumb drives of yesteryear. What really makes SSDs shine is that they have multiple NAND parts on these things, and that they stripe the data across a huge number of channels. Just think RAID 0 with HDDs, except this time, it's done by the SSD controller itself, so the motherboard only needs 1 SATA (or other like PCIe) interface to the SSD. That really put SSDs on the map, and if a single NAND chip can do 40 MB/s writes, think about 16 of them doing it at the same time.
So yes, there's no question that the main advantage of SSDs vs HDDs is an electrical vs mechanical thing. It's just simply not true that reading the electrical signals off of a single NAND part is faster than reading the bits off of a sequential track in an HDD. It's a lot of different things working together.
iwod - Friday, May 16, 2014 - link
I skim read it. Few things i notice, No Power usage testing. But 0.05w idle is pretty amazing. Since the PCI-E supply the power as well i guess they could be much better fine grained? Although Active was 5.6W. So at the same time we want more performance == faster controller while using much lower power. it seems there could be more work to do.I wonder if the relative slow Random I/O were due to Samsung betting its use on NVMe instead of ACHI.
iwod - Friday, May 16, 2014 - link
It also prove my points about Random I/O. We see how Random I/O for xp941 being at the bottom of the chart while getting much better benchmarks results. Seq I/O matters! And It matters a lot. The PCI -E x4 interfaces will once again becomes bottleneck until we move to PCI-E 3.0 Which i hope we do in 2015.Although i have this suspicious feeling intel is delaying or slowing down our progression.
nevertell - Friday, May 16, 2014 - link
Can't you place the bootloader on a hard drive, yet have it load the OS up from the SSD ?rxzlmn - Friday, May 16, 2014 - link
'Boot Support: Mac? Yes. PC? Mostly No.'Uh, a Mac is a PC. On a serious tech site I don't expect lines like that.
Penti - Friday, May 16, 2014 - link
Firmware differences.Haravikk - Friday, May 16, 2014 - link
It still surprises me that PCs can have so many hurdles when it comes to booting from various devices; for years now Macs have been able to boot from just about anything you plug into them (that can store data of course). I have one machine already that uses an internal drive combined with an external USB drive as a Fusion Drive, and it not only boots just fine, but the Fusion setup really helps eliminate the USB performance issues.Anyway, it's good to see PCIe storage properly reaching general release; it's probably going to be a while before I adopt it on PCs, as I'm still finding regular SATA or M.2 flash storage runs just fine for my needs, but having tried Apple's new Mac Pros, the PCIe flash really is awesome. Hopefully the next generation of Mac Pros will have connectors for two, as combined in a RAID-0 or RAID-1 the read performance can be absolutely staggering.