by Adam Armstrong

Samsung 983 DCT NVMe SSD Review

The Samsung 983 DCT is the company’s latest Data Center SSD. The 983 DCT leverages NVMe interface and comes in two form factors: 2.5” and M.2. The drive is built off of proven Samsung components and its battle proven V-NAND. The drive is specifically geared toward performance but also come end-to-end data protection, more efficient management through the Samsung SSD Toolkit software, and a 5-year warranty.

The company has recently refreshed its data center drives recently with the 983 DCT being the drive that aims for high speed and high responsiveness. Samsung states with will achieve this goal through NVMe technology as well as with its Phoenix controller. For the 2.5” version, the company states that the 983 DCT can hit up to 3,400MB/s sequential speeds, and up to 580,000 IOPS for random throughput. 

As stated, the Samsung 983 DCT comes in both M.2 and 2.5” form factors. For this review we are looking at the 1.92TB, 2.5” form factor. 

Samsung 983 DCT Specifications

Form Factor 2.5”
Capacity 960GB 1.92TB
Interface PCIe Gen 3 x4, NVMe 1.2b
NAND Samsung V-NAND
Controller Samsung Phoenix
Encryption Support AES 256-bit
Performance 
Sequential Read Up to 3.3GB/s Up to 3.4GB/s
Sequential Write Up to 1.3GB/s Up to 2.2GB/s
Random Read (4K, QD32) 440K IOPS 580K IOPS
Random Write (4K, QD32) 46K IOPS 52K IOPS
QoS Read (99.99%, 4KB, QD1) Up to 0.13ms
QoS Write (99.99%, 4KB, QD1) Up to 0.09ms
Power Consumption
Active Read Up to 8.7W
Active Write Up to 10.6W
Idle Up to 4.0W
Endurance
MTBF 2.0 million hours
UBER5 1 sector per 10^17 bits read
Shock 1500G, duration 0.5 ms, Half Sine Wave
Environment
Allowable Voltage 12.0V ± 8%
Operating Temperature 0-70°C
Physical
Dimensions (WxHxD) Max. 100.2 x 69.85 x 6.8 (mm)
Weight Max. 70g
Warranty 5-year or 0.8 DWPD

Performance

Testbed

Our Enterprise SSD reviews leverage a Lenovo ThinkSystem SR850 for application tests and a Dell PowerEdge R740xd for synthetic benchmarks. The ThinkSystem SR850 is a well-equipped quad-CPU platform, offering CPU power well in excess of what's needed to stress high-performance local storage. Synthetic tests that don't require a lot of CPU resources use the more traditional dual-processor server. In both cases, the intent is to showcase local storage in the best light possible that aligns with storage vendor maximum drive specs.

Lenovo ThinkSystem SR850

  • 4 x Intel Platinum 8160 CPU (2.1GHz x 24 Cores)
  • 16 x 32GB DDR4-2666Mhz ECC DRAM
  • 2 x RAID 930-8i 12Gb/s RAID Cards
  • 8 NVMe Bays
  • VMware ESXI 6.5

Dell PowerEdge R740xd

  • 2 x Intel Gold 6130 CPU (2.1GHz x 16 Cores)
  • 16 x 16GB DDR4-2666MHz ECC DRAM
  • 1x PERC 730 2GB 12Gb/s RAID Card
  • Add-in NVMe Adapter
  • Ubuntu-16.04.3-desktop-amd64

Testing Background and Comparables

The StorageReview Enterprise Test Lab provides a flexible architecture for conducting benchmarks of enterprise storage devices in an environment comparable to what administrators encounter in real deployments. The Enterprise Test Lab incorporates a variety of servers, networking, power conditioning, and other network infrastructure that allows our staff to establish real-world conditions to accurately gauge performance during our reviews.

We incorporate these details about the lab environment and protocols into reviews so that IT professionals and those responsible for storage acquisition can understand the conditions under which we have achieved the following results. None of our reviews are paid for or overseen by the manufacturer of equipment we are testing. Additional details about the StorageReview Enterprise Test Lab and an overview of its networking capabilities are available on those respective pages.

Main comparables for this review:

Application Workload Analysis

In order to understand the performance characteristics of enterprise storage devices, it is essential to model the infrastructure and the application workloads found in live-production environments. Our benchmarks for the Samsung 983 DCT are therefore the MySQL OLTP performance via SysBench. For our application workloads, each drive will be running 2-4 identically configured VMs. Note: The 1.92TB model wasn't big enough for our SQL application workload, so it wasn't included in this review.

Sysbench Performance

The next application benchmark consists of a Percona MySQL OLTP database measured via SysBench. This test measures average TPS (Transactions Per Second), average latency, and average 99th percentile latency as well.

Each Sysbench VM is configured with three vDisks: one for boot (~92GB), one with the pre-built database (~447GB), and the third for the database under test (270GB). From a system resource perspective, we configured each VM with 16 vCPUs, 60GB of DRAM and leveraged the LSI Logic SAS SCSI controller.

Sysbench Testing Configuration (per VM)

  • CentOS 6.3 64-bit
  • Percona XtraDB 5.5.30-rel30.1
    • Database Tables: 100
    • Database Size: 10,000,000
    • Database Threads: 32
    • RAM Buffer: 24GB
  • Test Length: 3 hours
    • 2 hours preconditioning 32 threads
    • 1 hour 32 threads

With the Sysbench transactional benchmark, the Samsung 983 DCT (referred to as the Samsung throughout the rest of the performance section) came in last with 6,159.4 TPS.

For Sysbench average latency, again the Samsung came in last with 20.8ms. 

For our worst-case scenario latency (99th percentile) the Samsung stayed in last place with 38.6ms. 

Houdini by SideFX

The Houdini test is specifically designed to evaluate storage performance as it relates to CGI rendering. The test bed for this application is a variant of the core Dell PowerEdge R740xd server type we use in the lab with dual Intel 6130 CPUs and 64GB DRAM. In this case, we installed Ubuntu Desktop (ubuntu-16.04.3-desktop-amd64) running bare metal. Output of the benchmark is measured in seconds to complete, with fewer being better.

The Maelstrom demo represents a section of the rendering pipeline that highlights the performance capabilities of storage by demonstrating its ability to effectively use the swap file as a form of extended memory. The test does not write out the result data or process the points in order to isolate the wall-time effect of the latency impact to the underlying storage component. The test itself is composed of five phases, three of which we run as part of the benchmark, which are as follows:

  1. Loads packed points from disk. This is the time to read from disk. This is single threaded, which may limit overall throughput.
  2. Unpacks the points into a single flat array in order to allow them to be processed. If the points do not have dependency on other points, the working set could be adjusted to stay in-core. This step is multi-threaded.
  3. (Not Run) Process the points.
  4. Repacks them into bucketed blocks suitable for storing back to disk. This step is multi-threaded.
  5. (Not Run) Write the bucketed blocks back out to disk.

With the Houdini test, the Samsung landed in roughly the middle of our non-Optane drives with 2,634.2 seconds.

VDBench Workload Analysis

When it comes to benchmarking storage devices, application testing is best, and synthetic testing comes in second place. While not a perfect representation of actual workloads, synthetic tests do help to baseline storage devices with a repeatability factor that makes it easy to do apples-to-apples comparison between competing solutions. These workloads offer a range of different testing profiles ranging from "four corners" tests, common database transfer size tests, to trace captures from different VDI environments. All of these tests leverage the common vdBench workload generator, with a scripting engine to automate and capture results over a large compute testing cluster. This allows us to repeat the same workloads across a wide range of storage devices, including flash arrays and individual storage devices. Our testing process for these benchmarks fills the entire drive surface with data, then partitions a drive section equal to 25% of the drive capacity to simulate how the drive might respond to application workloads. This is different than full entropy tests which use 100% of the drive and take them into steady state. As a result, these figures will reflect higher-sustained write speeds.

Profiles:

  • 4K Random Read: 100% Read, 128 threads, 0-120% iorate
  • 4K Random Write: 100% Write, 64 threads, 0-120% iorate
  • 64K Sequential Read: 100% Read, 16 threads, 0-120% iorate
  • 64K Sequential Write: 100% Write, 8 threads, 0-120% iorate
  • Synthetic Database: SQL and Oracle
  • VDI Full Clone and Linked Clone Traces

In our first VDBench Workload Analysis, Random 4K Read, the Samsung started off with 82.1μs latency at 59,187 IOPS. The Samsung stayed under 100μs until about 300K IOPS and went on to have the lowest peak performance at 591,839 IOPS at 215.2μs.

In 4K random writes the Samsung trailed all the other drives by a wide margin. It started at 20.2μs at 35,420 IOPS and quickly shot up to 52,822 IOPS at 2.42ms latency for its peak. 

Switching over to sequential work, in our 64K read the Samsung started off with the lowest latency (187.8μs) and maintained a lower latency until about 32K IOPS or 2.1GB/s and peaked with the lowest performance of the group at 36,389 IOPS or 2.27GB/s.

For 64K writes we see yet another poor performance from the Samsung starting at only 67.3μs latency the drive quickly spiked up and peaked at 3,299 IOPS or 206MB/s at a latency of 4.84ms. 

Our next batch of benchmarks focus on SQL workloads. For the first benchmark the Samsung started with the lowest latency at 82μs and 21,107 IOPS. The drive maintained the lowest latency until about 150K IOPS and went on to have the second overall peak performance at 210,323 IOPS with 149.5μs latency.

For SQL 90-10 the Samsung started off strong once more with 18,589 IOPS at a latency of only 82.5μs. The drive stayed below 100μs until just shy of 90K IOPS and went on to stay in second with a peak score of 184,773 IOPS and a latency of 172.3μs.

SQL 80-20 saw the drive slip a bit. While still starting with the lowest latency (86.8μs) the drive had the weakest peak performance of about 132K IOPS and 233μs for latency.

Moving onto Oracle Workloads we see the Samsung start off on the wrong foot. Again the drive enters with the lowest latency (82.7μs) but quickly shoots up and peaks at 95,205 IOPS with 418.9μs latency, well behind the other drives. 

With the Oracle 90-10 the Samsung improved. Starting with 15,515 IOPS and a latency of 82.5μs the drive stayed under 100μs until roughly 72K IOPS and going on to peak 159,976 IOPS at 139.6μs.

Oracle 80-20 had the Samsung maintain sub-100μs latency from 12,687 IOPS until about 60K IOPS with a peak performance of 130,766 IOPS and 166.5μs for latency. 

Next, we move on to our VDI clone test, Full and Linked. For VDI Full Clone Boot, the Samsung started just under 100μs to quickly go over it and land in third with a peak performance of 123,613 IOPS and a latency of 279.4μs.

VDI FC Initial Login had the Samsung start at 3,987 IOPS with 72.7μs. The latency stayed low, in fact it dropped so low that it looks as though it is zero on our charts, until about 12K IOPS where it shoots up rapidly peaking at 15,845 IOPS with a latency of 1.9ms. 

With VDI Monday Login, the Samsung stayed in last starting just under 100μs before jumping up to a peak of 17,810 IOPS with a latency of 895μs.

For the VDI Linked Clone (LC) we start once again with the boot test. Here the Samsung showed its strongest performance in our Clone test running neck and neck with the Memblaze PBlaze5 910. However, the Samsung still came in last with a peak performance of 64,503 IOPS with a latency of 248.8μs.

VDI LC Initial Login had the Samsung start just over 100μs and quickly spike up to a peak of 9,959 IOPS with 799.4μs latency, well behind the other two drives.

Finally the VDI LC Monday Login showed that the Samsung continued on with its poor performance starting over 100μs and quickly spiking up to 10,410 IOPS with 1.52ms latency. 

Conclusion 

The Samsung 983 DCT is the read focused NVMe version of the company’s data center refresh. The 983 DCT comes in two form factors, 2.5” and M.2, as well as two capacities, 960GB and 1.92TB. The 983 DCT is slated as Samsung’s performance data center drive with quoted speeds of up to 3.4GB/s sequential and 580K IOPS random, read in both cases. The drive leverages V-NAND, the NVMe interface, and the company’s Phoenix controller in order to hit these numbers. 

While others in the read-intensive category offer 1 DWPD, the Samsung 983 DCT is a bit lighter at just 0.8 DWPD. With that being the case, it wasn't a huge surprise to see the 983 DCT come in below others in this category that offered a small edge in write performance. In our application workload analysis the Samsung 983 DCT came in last in all three Sysbench tests with 6,159.4 TPS, an average latency of 20.8ms, and a worst-case scenario latency of 38.6ms. Houdini saw the drive land roughly in the middle of the traditional NVMe drives with 2,634.2 seconds. Due to its smaller capacity (1.92TB in this review) we were unable to run our SQL Server Application tests. 

Moving on to VDBench testing the new for the Samsung 983 DCT we get a clearer view towards how the drive reacts to read and write workloads. The drive had decent read performance in 4K with 592K IOPS and in 64K it hit 2.27GB/s. In both cases the Samsung had the lowest latency longer than the other two drives. For Writes it was a stark contrast. 4K write peaked at a measly 53K IOPS and had a latency of 2.42ms. 64K writes saw only a peak of 206MB/s and a latency of 4.84ms. SQL and Oracle saw an improvement in performance and placement for Samsung with the drive typically having the lowest latency the longest. Highlights include 210K IOPS for SQL, 185K IOPS for SQL 90-10, 160K IOPs for Oracle 90-10, and 131K IOPS for Oracle 80-20. With the exception of the VDI Full Clone Boot test, the Samsung showed overall poor performance in our VDI Clone tests.

As the SSD market looks to further segment products, the Samsung 983 DCT comes in as an NVMe product offering 0.8 DWPD, slightly under competing products that focus on the 1 DWPD mark in their read-intensive positioned drives. As such, it wasn't shocking to see lower write performance from the 983 DCT. Instead the drive carries a larger emphasis on read-performance. Here it was able to offer lower initial latency in small and large-block transfers. Overall the 983 DCT will do good work in read-heavy environments that lean toward a more value-oriented NVMe drive.

Samsung 983 DCT

Discuss this review

Sign up for the StorageReview newsletter

Related News and Reviews