QLC Goes To 8TB: Samsung 870 QVO and Sabrent Rocket Q 8TB SSDs Reviewedby Billy Tallis on December 4, 2020 8:00 AM EST
This test starts with a freshly-erased drive and fills it with 128kB sequential writes at queue depth 32, recording the write speed for each 1GB segment. This test is not representative of any ordinary client/consumer usage pattern, but it does allow us to observe transitions in the drive's behavior as it fills up. This can allow us to estimate the size of any SLC write cache, and get a sense for how much performance remains on the rare occasions where real-world usage keeps writing data after filling the cache.
The Sabrent Rocket Q takes the strategy of providing the largest practical SLC cache size, which in this case is a whopping 2TB. The Samsung 870 QVO takes the opposite (and less common for QLC drives) approach of limiting the SLC cache to just 78GB, the same as on the 2TB and 4TB models.
|Average Throughput for last 16 GB||Overall Average Throughput|
Both drives maintain fairly steady write performance after their caches run out, but the Sabrent Rocket Q's post-cache write speed is twice as high. The post-cache write speed of the Rocket Q is still a bit slower than a TLC SATA drive, and is just a fraction of what's typical for TLC NVMe SSDs.
On paper, Samsung's 92L QLC is capable of a program throughput of 18MB/s per die, and the 8TB 870 QVO has 64 of those dies, for an aggregate theoretical write throughput of over 1GB/s. SLC caching can account for some of the performance loss, but the lack of performance scaling beyond the 2TB model is a controller limitation rather than a NAND limitation. The Rocket Q is affected by a similar limitation, but also benefits from QLC NAND with a considerably higher program throughput of 30MB/s per die.
Working Set Size
Most mainstream SSDs have enough DRAM to store the entire mapping table that translates logical block addresses into physical flash memory addresses. DRAMless drives only have small buffers to cache a portion of this mapping information. Some NVMe SSDs support the Host Memory Buffer feature and can borrow a piece of the host system's DRAM for this cache rather needing lots of on-controller memory.
When accessing a logical block whose mapping is not cached, the drive needs to read the mapping from the full table stored on the flash memory before it can read the user data stored at that logical block. This adds extra latency to read operations and in the worst case may double random read latency.
We can see the effects of the size of any mapping buffer by performing random reads from different sized portions of the drive. When performing random reads from a small slice of the drive, we expect the mappings to all fit in the cache, and when performing random reads from the entire drive, we expect mostly cache misses.
When performing this test on mainstream drives with a full-sized DRAM cache, we expect performance to be generally constant regardless of the working set size, or for performance to drop only slightly as the working set size increases.
The Sabrent Rocket Q's random read performance is unusually unsteady at small working set sizes, but levels out at a bit over 8k IOPS for working set sizes of at least 16GB. Reads scattered across the entire drive do show a substantial drop in performance, due to the limited size of the DRAM buffer on this drive.
The Samsung drive has the full 8GB of DRAM and can keep the entire drive's address mapping mapping table in RAM, so its random read performance does not vary with working set size. However, it's clearly slower than the smaller capacities of the 870 QVO; there's some extra overhead in connecting this much flash to a 4-channel controller.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Beaver M. - Saturday, December 5, 2020 - linkJust imagine it as 4K random on steroids.
Games load MUCH faster and with less or even no stuttering.
Its been proven already. If you want to miss out on this, thats your choice.
Deicidium369 - Sunday, December 6, 2020 - linkProven already is a bit premature. Transferring compressed data to the GPU which then decompresses is going to be an obvious increase in performance - provided it is not left up to developers to implement - like multi GPU being a part of DX12 - but only if it is implemented.
Beaver M. - Monday, December 7, 2020 - linkIts working on consoles already. And of course the devs can choose to use it or not. But since its part of consoles, and most PC games are console ports, its very likely to be very common in the future.
Spunjji - Monday, December 7, 2020 - linkIt's going to affect performance plenty for people who run software that uses it. Your personal attitude to new games and their "political" content doesn't really have any bearing on that.
Oxford Guy - Friday, December 4, 2020 - link"Flash memory prices have been on a downward trajectory for years."
And now, thanks to QLC, quality, too!
Spunjji - Monday, December 7, 2020 - linkHow many posts do you need to make the same point?
Oxford Guy - Monday, December 7, 2020 - linkWhen QLC is no longer being shoved down my throat? 0.
inighthawki - Friday, December 4, 2020 - linkOne additional purpose for high capacity M.2 drives is that they're compatible with the new RTX IO/DirectStorage requirements (NVME drive over PCIe), which will not work on a standard SATA drive. So if you have a lot of large games that you want to be able to take advantage of this feature, you will need higher capacity drives.
And yes for many people 2TB or 4TB will be more than sufficient for this, at least within the next few years until games more commonly adopt the feature. I'm by no means calling this a requirement for anyone, just merely pointing out an upcoming use case.
DigitalFreak - Friday, December 4, 2020 - linkMy 860 EVO 4TB is humming along just fine for now. Still costs the same as what I paid for it a couple of years ago, which is a joke. I'm waiting for DirectStorage before I buy another high capacity drive for games. By that time PCIe 4.0 drives should be more commonplace, and hopefully cheaper.
DigitalFreak - Friday, December 4, 2020 - linkBTW, excellent article Billy.