The Intel SSD 660p SSD Review: QLC NAND Arrives For Consumer SSDs
by Billy Tallis on August 7, 2018 11:00 AM ESTRandom Read Performance
Our first test of random read performance uses very short bursts of operations issued one at a time with no queuing. The drives are given enough idle time between bursts to yield an overall duty cycle of 20%, so thermal throttling is impossible. Each burst consists of a total of 32MB of 4kB random reads, from a 16GB span of the disk. The total data read is 1GB.
The Intel SSD 660p delivers excellent random read performance from its SLC cache, coming in behind only the drives using Silicon Motion's higher-end controllers with Intel/Micron TLC. When reading data from a full drive where background processing is probably still ocurring, the performance is halved but remains slightly ahead of the Intel 600p.
Our sustained random read performance is similar to the random read test from our 2015 test suite: queue depths from 1 to 32 are tested, and the average performance and power efficiency across QD1, QD2 and QD4 are reported as the primary scores. Each queue depth is tested for one minute or 32GB of data transferred, whichever is shorter. After each queue depth is tested, the drive is given up to one minute to cool off so that the higher queue depths are unlikely to be affected by accumulated heat build-up. The individual read operations are again 4kB, and cover a 64GB span of the drive.
On the longer random read test, the 660p maintains its outstanding SLC cache performance that beats anything else currently on the market, but filling the drive it is slower than almost any other NVMe SSD - the exception being the Toshiba RC100 that doesn't use a large enough host memory buffer for the data range this test covers.
 |
|||||||||
| Power Efficiency in MB/s/W | Average Power in W | ||||||||
With the combination of lower power consumption afforded by its small NVMe controller and excellent random read performance, the Intel 660p earns the top efficiency score for this test. When it's slowed down by being full and still grinding away at background cleanup, its efficiency is much worse but still an improvement over the 600p.
 |
|||||||||
At high queue depths the 660p's random read speed begins to fall behind high-end NVMe SSDs, but it isn't significant until well beyond the queue depths that are relevant to real-world client/consumer usage patterns.
Random Write Performance
Our test of random write burst performance is structured similarly to the random read burst test, but each burst is only 4MB and the total test length is 128MB. The 4kB random write operations are distributed over a 16GB span of the drive, and the operations are issued one at a time with no queuing.
The burst random write speed of the Intel SSD 660p is not record-setting, but it is comparable to high-end NVMe SSDs.
As with the sustained random read test, our sustained 4kB random write test runs for up to one minute or 32GB per queue depth, covering a 64GB span of the drive and giving the drive up to 1 minute of idle time between queue depths to allow for write caches to be flushed and for the drive to cool down.
On the longer random write test, the 660p is slower than most high-end NVMe SSDs but still performs much better than the other entry-level NVMe drives or the SATA drive. After filling the drive (and consequently the SLC write cache), the performance drops below the SATA drive but is still more than twice as fast as the Toshiba RC100.
 |
|||||||||
| Power Efficiency in MB/s/W | Average Power in W | ||||||||
Power efficiency when performing random writes to a clean SLC cache is not quite the best we've measured, but it is far ahead of what the other low-end NVMe SSD drives or the Crucial MX500 SATA drive can manage
 |
|||||||||
After QD4 the 660p starts to show signs of filling the SLC write cache, which is a little bit sooner than expected given how large the SLC cache should be for the mostly-empty drive condition. The performance doesn't drop very far, showing that the idle time is enough for the drive to mostly keep up with flushing the SLC cache when the test is writing to the drive with a 50% duty cycle.
Facebook
Twitter
RSS
86 Comments
View All Comments
zodiacfml - Wednesday, August 8, 2018 - link
I think the limiting factor for reliability is the electronics/controller, not the NAND. You just lose drive space with a QLC much sooner with plenty of writes.romrunning - Wednesday, August 8, 2018 - link
Given that you can buy 1TB 2.5" HDD for $40-60 (maybe less for volume purchases), and even this QLC drive is still $0.20/GB, I think it's still going to be quite a while before notebook mfgs replace their "big" HDD with a QLC drive. After all, the first thing the consumer sees is "it's got lots of storage!"evilpaul666 - Wednesday, August 8, 2018 - link
Does the 660p series of drives work with the Intel CAS (Cache Acceleration Software)? I've used the trial version and it works about as well as Optane does for speeding up a mechanical HDD while being quite a lot larger.eddieobscurant - Wednesday, August 8, 2018 - link
Wow,this got a recommended award and the adata 8200 didn't. Another pro-intel marketing from anandtech. Waiting for biased threadripper 2 review.BurntMyBacon - Wednesday, August 8, 2018 - link
The performance of this SSD is quite bipolar. I'm not sure I'd be as generous with the award. Though, I think the decision to give out an award had more to do with the price of the drive and the probable performance for typical consumer workloads than some "pro-intel marketing" bias.danwat1234 - Wednesday, August 8, 2018 - link
The drive is only rated to write to each cell 200 times before it begins to wear out? Ewwww.azazel1024 - Wednesday, August 8, 2018 - link
For some consumer uses, yes 100MiB/sec constant write speed isn't terrible once the SLC cache is exhausted, but it'll probably be a no for me. Granted, SSD prices aren't where I want them to be yet to replace my HDDs for bulk storage. Getting close, but prices still need to come down by about a factor of 3 first.My use case is 2x1GbE between my desktop and my server and at some point sooner rather than later I'd like to go with 2.5GbE or better yet 5GbE. No, I don't run 4k video editing studio or anything like that, but yes I do occasionally throw 50GiB files across my network. Right now my network link is the bottleneck, though as my RAID0 arrays are filling up, it is getting to be disk bound (2x3TB Seagate 7200rpm drive arrays in both machines). And small files it definitely runs in to disk issues.
I'd like the network link to continue to be the limiting factor and not the drives. If I moved to a 2.5GbE link which can push around 270MiB/sec and I start lobbing large files, the drive steady state write limits are going to quickly be reached. And I really don't want to be running an SSD storage array in RAID. That is partly why I want to move to SSDs so I can run a storage pool and be confident that each individual SSD is sufficiently fast to at least saturate 2.5GbE (if I run 5GbE and the drives can't keep up, at least in an SLC cache saturated state, I am okay with that, but I'd like them to at least be able to run 250+ MiB/sec).
Also although rare, I've had to transfer a full back-up of my server or desktop to the other machine when I've managed to do something to kill the file copy (only happened twice over the last 3 years, but it HAS happened. Also why I keep a cold back-up that is updated every month or two on an external HDD). When you are transferring 3TiB or so of data, being limited to 100MiB/sec would really suck. At least right now when that happens I can push an average of 200MiB/sec (accounting for some of it being smaller files which are getting pushed at more like 80-140MiB/sec rather than the 235MiB/sec of large files).
That is a difference from close to 8:30 compared to about 4:15. Ideally I'd be looking at more like 3:30 for 3TiB.
But, then again, looking at price movement, unless I win the lottery, SSD prices are probably going to take at least 4 or more likely 5-6 years before I can drop my HDD array and just replace it with SSDs. Heck, odds are excellent I'll end up replacing my HDD array with a set of even faster 4 or 6TiB HDDs before SSDs are closer enough in price (closer enough to me is paying $1000 or less for 12TB of SSD storage).
That is keeping in mind that with HDDs I'd likely want utilized capacity under 75% and ideally under 67% to keep from utilizing those inner tracks and slowing way down. With SSDs (ignoring the SLC write cache size reductions), write penalties seem to be much less. Or at least the performance (for TLC and MLC) is so much higher than HDDs to start with, that it still remains high enough not to be a serious issue for me.
So an SSD storage pool could probably be up around 80-90% utilized and be okay, where as a HDD array is going to want to be no more than 67-75% utilized. And also in my use case, it should be easy enough to simply slap in another SSD to increase the pool size, with HDDs I'd need to chuck the entire array and get new sets of matched drives.
iwod - Wednesday, August 8, 2018 - link
On Mac, two weeks of normal usage has gotten 1TB of written data. And it does 10-15GB on average per day.100TB endurance is nothing.......
abufrejoval - Wednesday, August 8, 2018 - link
I wonder if underneath the algorithm has already changed to do what I’d call the ‘smart’ thing: Essentially QLC encoding is a way of compression (brings back old memories about “Stacker”) data 4:1 at the cost of write bandwidth.So unless you run out of free space, you first let all data be written in fast SLC mode and then start compressing things into QLC as a background activity. As long as the input isn’t constantly saturated, the compression should reclaim enough SLC mode blocks faster on average after compression than they are filled with new data. The bigger the overall capacity and remaining cache, the longer the burst it can sustain. Of course, once the SSD is completely filled the cache will be whatever they put into the spare area and updates will dwindle down to the ‘native’ QLC write rate of 100MB/s.
In a way this is the perfect storage for stuff like Steam games: Those tend to be hundreds of gigabytes these days, they are very sensitive to random reads (perhaps because the developers don’t know how to tune their data) but their maximum change rate is actually the capacity of your download bandwidth (wish mine was 100MB/s).
But it’s also great for data warehouse databases or quite simply data that is read-mostly, but likes high bandwidth and better latency than spinning disks.
The problem that I see, though, is that the compression pass needs power. So this doesn’t play well with mobile devices that you shut off immediately after slurping massive amounts of data. Worst case would be a backup SSD where you write and unplug.
The specific problem I see for Anandtech and technical writers is that you’re no longer comparing hardware but complex software. And Emil Post proved in 1946, that it’s generally impossible.
And with an MRAM buffer (those other articles) you could even avoid writing things at SLC first, as long as the write bursts do not overflow the buffer and QLC encoding empties it faster on average that it is filled. Should a burst overflow it, it could switch to SLC temporarily.
I think I like it…
And I think I would like it even better, if you could switch the caching and writing strategy at the OS or even application level. I don’t want to have to decide between buying a 2TB QLC, 1TB TLC, a 500GB MLC or 250GB SLC and then find out I need a little more here and a little less there. I have knowledge at the application (usage level), how long-lived my data will be and how it should best be treated: Let’s just use it, because the hardware internally is flexible enough to support at least SLC, TLC and QLC.
That would also make it easier to control the QLC rewrite or compression activity in mobile or portable form factors.
ikjadoon - Thursday, August 9, 2018 - link
Billy, thank you!I posted a reddit comment a long time ago about separating SSD performance by storage size! I might be behind, but this is the first I’ve seen of it. It’s, to me, a much more reliable graph for purchases.
A big shout out. 💪👌