The Samsung 983 ZET (Z-NAND) SSD Review: How Fast Can Flash Memory Get?by Billy Tallis on February 19, 2019 8:00 AM EST
QD1 Random Read Performance
Drive throughput with a queue depth of one is usually not advertised, but almost every latency or consistency metric reported on a spec sheet is measured at QD1 and usually for 4kB transfers. When the drive only has one command to work on at a time, there's nothing to get in the way of it offering its best-case access latency. Performance at such light loads is absolutely not what most of these drives are made for, but they have to make it through the easy tests before we move on to the more realistic challenges.
The 983 ZET comes even closer to matching the Optane SSD on our random read power efficiency score. Even in this enterprise configuration, the Samsung Phoenix is still a relatively low-power NVMe SSD controller, and the 983 ZET only draws a bit more power overall than the TLC-based 983 DCT. While the Optane SSD may have delivered almost twice the raw performance, it only has a 15-20% advantage in performance-per-Watt here.
|Power Efficiency in kIOPS/W||Average Power in W|
The random read latency stats for the 983 ZET clearly set it apart from the rest of the flash-based SSDs and put it in the same league as the Optane SSD. The Optane SSD's average latency of just under 9µs is still better than the 16µs from the 983 ZET, but the tail latencies for the two are quite similar. Both Z-NAND and 3D XPoint provide better 99.99th percentile latency here than the average latencies of the MLC and TLC drives.
The random read performance of the 983 ZET is clearly optimized specifically for 4kB reads—both smaller and larger transfers take a significant hit to IOPS. By contrast, the Optane SSD's IOPS declines smoothly as the transfer size increases from the minimum of a single 512 byte logical block.
The other flash-based SSDs show fairly low throughput until the transfer sizes get up to around 128kB, but the Z-NAND's smaller page size allows it to exercise parallelism even for smaller transfers: the 960GB 983 ZET has higher throughput for 32kB reads than the TLC-based 983 DCT for 128kB reads.
QD1 Random Write Performance
The Samsung 983 ZET takes the lead for QD1 random write performance, and the Intel Optane SSD doesn't stand out from other flash-based SSDs. Intel's 3D XPoint memory has a far faster write latency than the programming times of NAND flash memory (even Z-NAND), but flash-based SSDs are very good at covering this up with DRAM caches. Thanks to their power loss protection capacitors, enterprise SSDs can safely report writes as complete while the data is still in their RAM, and the writes can be deferred and batched in the background. Intel's Optane SSDs do not have any DRAM and instead performs writes directly without the caching layer (and without the large power loss protection capacitors).
|Power Efficiency in kIOPS/W||Average Power in W|
The Samsung 983 ZET also provides the best power efficiency during our QD1 random write test, but the Optane SSD and the TLC-based 983 DCT come close. In terms of total power, the Optane SSD draws about the same performing random writes as random reads, but all of the flash-based SSDs require much more power for writes than reads. The Samsung 983 ZET requires significantly more power than the 983 DCT, but not quite as much as the Intel P4510 and the other flash-based SSDs that use larger controllers.
The latency stats for the Samsung 983 ZET performing random writes at QD1 are the best in the bunch, but it doesn't stand out by much. The Intel P4510 has high tail latencies, but the rest of these NVMe drives have 99.99th percentile latencies that are no worse than four times their average latency. At low queue depths, almost all of these drives have no problem with QoS.
The Samsung 983 ZET's optimization for 4kB accesses is again apparent, but the performance for smaller writes is not crippled as it is for the Memblaze PBlaze5 and Micron 9100 MAX. Using transfers larger than 4kB doesn't yield any steady-state random write throughput increases all the way up to writing 1MB blocks, so IOPS falls off quickly as transfer size grows.
QD1 Sequential Read Performance
The queue depth 1 sequential read performance of the 983 ZET is lower than the TLC-based 983 DCT: about 2GB/s instead of 2.5GB/s. This puts the 983 ZET more in line with Intel's drives, including the Optane SSD. This is one area where the smaller page size of the Z-NAND is detrimental.
|Power Efficiency in MB/s/W||Average Power in W|
The 983 ZET draws only slightly less power than the 983 DCT, which combined with its 20% worse performance leads to a lower efficiency score. However, both Samsung drives still provide better performance per Watt than the other drives included here, which all have more power-hungry controllers than the Samsung Phoenix.
The 983 ZET's sequential read speed at QD1 is almost at full speed for block sizes of at least 32kB, but there's a slight improvement at 512kB or larger. The 983 DCT and Intel P4510 top out with 256kB transfers, while the Memblaze PBlaze5 delivers poor read speeds without either a large block size or high queue depth.
QD1 Sequential Write Performance
The Samsung 983 ZET excelled at QD1 random writes, but it is hardly any better than the TLC drives for QD1 sequential writes, and the smaller Z-SSD is substantially slower. This is because even at QD1, there's enough data moving to keep the drive at steady state, where the background garbage collection is limited by the slow block erase operations that affect Z-NAND just as much as traditional NAND flash memory. The Optane SSD is almost three times the speed of the larger Z-SSD. It is followed by the PBlaze5 C900, which benefits from a PCIe 3 x8 interface.
|Power Efficiency in MB/s/W||Average Power in W|
Both capacities of the 983 ZET use slightly more power during the sequential write test than the 983 DCT, which leaves the smaller Z-SSD with a significantly worse efficiency score. The larger Z-SSD and the two TLC-based 983 DCTs have the best efficiency scores among the flash-based SSDs, but that's still only two thirds the performance per Watt provided by the Optane SSD.
For sequential writes, the 983 ZET does not penalize sub-4kB transfers in terms of IOPS, but such small writes cannot deliver much throughput. The 983 ZET is close to full steady-state throughput with 8kB transfers, but doesn't actually peak until the transfers are up to 64kB.
Post Your CommentPlease log in or sign up to comment.
View All Comments
jabber - Tuesday, February 19, 2019 - linkI just looked at the price in the specs and stopped reading right there.
Dragonstongue - Tuesday, February 19, 2019 - linkAmen to that LOL
FunBunny2 - Tuesday, February 19, 2019 - linkwell... if one were to run a truly normalized RDBMS, i.e. 5NF and thus substantially smaller footprint compared to the common NoSQL flatfile alternative, this could be quite competitive. but that would require today's developers/coders to stop making apps just like their COBOL granddaddies did.
FreckledTrout - Tuesday, February 19, 2019 - linkI have no idea why you are talking coding and database design principles as it does not apply here at all. To carry your tangent along, if you want to make max use of a SSD's you denormalize the hell out of the database and spread the load over a ton of servers, ie NoSQL.
FunBunny2 - Tuesday, February 19, 2019 - linkwell... that does keep coders employed forever. writing linguine code all day long.
FreckledTrout - Tuesday, February 19, 2019 - linkWell it still is pointless in this conversation about fast SSD's. What spaghetti code has to do with that I have no idea. Sure they can move cloud native way of designing applications using micro services etl al but what the hell that has to do with fast SSD's baffles me.
FunBunny2 - Tuesday, February 19, 2019 - link" What spaghetti code has to do with that I have no idea. "
well... you can write neat code against a 5NF datastore, or mountains of linguine to keep all that mound of redundant bytes from biting you. again, let's get smarter than our granddaddies. or not.
GreenReaper - Wednesday, February 20, 2019 - linkThey have at least encouraged old-school databases to up their game. With parallel queries on the back-end, PostgreSQL can fly now, as long as you give it the right indexes to play with. Like any complex tool, you still have to get familiar with it to use it properly, but it's worth the investment.
FunBunny2 - Wednesday, February 20, 2019 - link"They have at least encouraged old-school databases to up their game. "
well... if you actually look at how these 'alternatives' (NoSql and such) to RDBMS work, you'll see that they're just re-hashes (he he) of simple flat files and IMS. anything xml-ish is just another hierarchical datastore, i.e. IMS. which predates RDBMS (Oracle was the first commercial implementation) by more than a decade. hierarchy and flatfile are the very, very old-school datastores.
PG, while loved because it's Open Source, is buggy as hell. been there, endured that.
anyway. the point of my comments was simply aimed at naming a use-case for these sorts of devices, nothing more, since so many comments questioned why it should exist. which is not to say it's the 'best' implementation for the use-case. but the use-case exists, whether most coders prefer to do transactions in the client, or not. back in your granddaddies' day, terminals (3270 and VT-100) were mostly dumb, and all code existed on the server/mainframe. 'client code' existed in close proximity to the 'database' (VSAM files, mostly), sometimes in the same address space, sometimes just on the same machine, and sometimes on a tethered machine. the point being: with today's innterTubes speed, there's really no advantage to 'doing transactions in the client' other than allowing client-centric coders to avoid learning how to support data integrity declaratively in the datastore. the result, of course, is that data integrity is duplicated both places (client and server) by different folks. there's no way the database folks, DBA and designer, are going to assume that all data coming in over the wire from the client really, really is clean. because it almost never is.
GruffaloOnVacation - Thursday, March 18, 2021 - linkFunBunny2 you sound bitter, and this is the sentiment I see among the old school "database people". May I suggest, with the best of intentions for us all, that instead of sneering at the situation, you attempt to educate those who are willing to learn? I've been working on some SQL in my project at work recently, and so have read a number of articles, and parts of some database books. There was a lot of resentment and sneering at the stoopid programmers there, but no positive programme of action proposed. I'm interested in this subject. Where should I go for resources? Which talks should I watch? What books to read? Let's build something that is as cool as something you described. If it really is THAT good, once it is built - they will come, and they will change!