Random 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.

Iometer - 4KB Random Read

While the other SSDs hover at 60-90MB/s for random reads, the SM951 provides a rather noticeable upgrade at 108MB/s. 

Samsung SM951 512GB

Looking at the performance more closely reveals that the SM951 delivers better performance at all queue depths, although obviously the difference is at high queue depths where the SM951 can take advantage of the faster PCIe interface. The SM951 actually does over 150K IOPS when the MB/s is translated into throughput.

 

 

 

Iometer - 4KB Random Write

Random write performance is equally strong. The line graphs shows how the SM951 shifts the whole curve up, implying a performance increase at all queue depths. Especially the performance at queue depths of 1 and 2 are noticeably better than on other drives.

Samsung SM951 512GB
AnandTech Storage Bench - Light Sequential Performance
Comments Locked

128 Comments

View All Comments

  • DanNeely - Tuesday, February 24, 2015 - link

    "In any case, I strongly recommend having a decent amount of airflow inside the case. My system only has two case fans (one front and one rear) and I run it with the side panels off for faster accessibility, so mine isn't an ideal setup for maximum airflow."

    With the space between a pair of PCIe x16 slots appearing to have become the most popular spot to put M2 slots I worry that thermal throttling might end up being worse for a lot of end user systems than on your testbench because it'll be getting broiled by GPUs. OTOH even with a GPU looming overhead, it should be possible to slap an aftermarket heatsink on using thermal tape. My parts box has a few I think would work that I've salvaged from random hardware (single wide GPUs???) over the years; if you've got anything similar lying around I'd be curious if it'd be able to fix the throttling problem.
  • Kristian Vättö - Tuesday, February 24, 2015 - link

    I have a couple Plextor M6e Black Edition drives, which are basically M.2 adapters with an M.2 SSD and a quite massive heatsink. I currently have my hands full because of upcoming NDAs, but I can certainly try to test the SM951 with a heatsink and the case fully assembled before it starts to ship.
  • DanNeely - Tuesday, February 24, 2015 - link

    Ok, I'd definitely be interested in seeing an update when you've got the time. Thanks.
  • Railgun - Tuesday, February 24, 2015 - link

    While I can see it's a case of something is better than nothing, given the mounting options of an M.2 drive, a couple of chips will not get any direct cooling benefit. In fact, they're sitting in a space where virtually zero airflow will be happening.

    The Plextor solution. and any like it is all well and good, but for those that utilize a native M.2 port on any given mobo, they're kind of out of luck. As it turns out, I also have a GPU blocking just above mine for any decent sized passive cooling; 8cm at best. Maybe that's enough, but the two chips on the other side have the potential to simply cook.
  • DanNeely - Tuesday, February 24, 2015 - link

    Depends if it's the flash chips or the ram/controller that're overheating. I think the latter two are on top and heat sinkable.
  • jhoff80 - Tuesday, February 24, 2015 - link

    It'd be even worse too for many of the mini-ITX boards that are putting the M.2 slot underneath the board.

    I mean, something like M.2 is ideal for these smaller cases where cabling can become an issue, so having the slot on the bottom of the board combined with a drive needing airflow sounds like grounds for a disaster.
  • extide - Tuesday, February 24, 2015 - link

    Yeah I bet it's the controller that is being throttled, because IT is overheating, not the actual NAND chips.
  • ZeDestructor - Tuesday, February 24, 2015 - link

    I second this motion. Prefereably as a seperate article so I don't miss it (I only get to AT via RSS nowadays)
  • rpg1966 - Tuesday, February 24, 2015 - link

    Maybe a dumb question, but: the 512GB drive has 4 storage chips (two on the front, two on the back), therefore each chip stores 128GB. If the NAND chips are 64Gbit (8GB), that means there are 16 packages in each chip - is that right?
  • Kristian Vättö - Tuesday, February 24, 2015 - link

    That is correct. Samsung has been using 16-die packages for quite some time now in various products.

Log in

Don't have an account? Sign up now