The Silicon Motion SM2262EN SSD Controller Preview: Good And Bad Amplified
by Billy Tallis on August 1, 2018 11:45 AM ESTSequential Read Performance
Our first test of sequential read performance uses short bursts of 128MB, issued as 128kB operations with no queuing. The test averages performance across eight bursts for a total of 1GB of data transferred from a drive containing 16GB of data. Between each burst the drive is given enough idle time to keep the overall duty cycle at 20%.
The burst sequential read performance from the Silicon Motion SM2262EN is slightly below what we've measured for earlier SM2262 drives, but it's still well ahead of any competing TLC drive.
Our test of sustained sequential reads uses queue depths from 1 to 32, with the performance and power scores computed as the average of QD1, QD2 and QD4. Each queue depth is tested for up to one minute or 32GB transferred, from a drive containing 64GB of data. This test is run twice: once with the drive prepared by sequentially writing the test data, and again after the random write test has mixed things up, causing fragmentation inside the SSD that isn't visible to the OS. These two scores represent the two extremes of how the drive would perform under real-world usage, where wear leveling and modifications to some existing data will create some internal fragmentation that degrades performance, but usually not to the extent shown here.
The sustained sequential read performance of the SM2262EN is identical to the SM2262 drives we've tested, and tied with the Samsung 960 PRO. The 2TB -EN drive has better performance than the SM2262 drives when reading from a drive with severe internal fragmentation, but there's still a lot of room for improvement here.
 |
|||||||||
| Power Efficiency in MB/s/W | Average Power in W | ||||||||
Power efficiency from the SM2262 drives was already very good on this test, and the SM2262EN brings an incremental improvement. Efficiency when reading from a drive with internal fragmentation is also slightly improved, but overall power consumption in that case is now over 6W, which is pushing it a bit for an M.2 drive that is being fed by only a 3.3V supply.
 |
|||||||||
The SM2262 drives hit their full sequential read at QD2, but the SM2262EN takes a bit longer to get up to its limit. The eventual performance is only a little bit shy of the 3.5GB/s that Silicon Motion's specifications promised.
Sequential Write Performance
Our test of sequential write burst performance is structured identically to the sequential read burst performance test save for the direction of the data transfer. Each burst writes 128MB as 128kB operations issued at QD1, for a total of 1GB of data written to a drive containing 16GB of data.
The burst sequential write speed of the SM2262EN is a substantial jump over what the plain SM2262 provides, but it's not quite enough to put the -EN at the top of the chart. The upcoming Phison E12 holds on to that spot for now, and the Samsung 970 EVO is also still ahead of the SM2262EN.
Our test of sustained sequential writes is structured identically to our sustained sequential read test, save for the direction of the data transfers. Queue depths range from 1 to 32 and each queue depth is tested for up to one minute or 32GB, followed by up to one minute of idle time for the drive to cool off and perform garbage collection. The test is confined to a 64GB span of the drive.
The SM2262EN does manage to take first place on the longer sequential write test, though some of this may be due to its capacity advantage over most of the other drives we have available to compare against. The 2TB 970 EVO is likely quite close to the SM2262EN, given how the 1TB 970 EVO performs.
 |
|||||||||
| Power Efficiency in MB/s/W | Average Power in W | ||||||||
The SM2262EN provides a 50% performance boost over its predecessor while dropping power consumption by a quarter of a Watt relative to the 1TB HP EX920, so it is no surprise to see the efficiency score leap upwards. Silicon Motion is now ahead of the WD Black and the Phison E12, and is almost as efficient as the much slower Toshiba XG5.
 |
|||||||||
The SM2262EN takes a bit longer to reach its full sequential write speed than most drives, saturating only at QD4 or higher. But it would probably still be in first place among TLC drives if its performance stopped increasing at QD2 where it has a slight advantage over the 1TB 970 EVO.
Facebook
Twitter
RSS
28 Comments
View All Comments
DigitalFreak - Wednesday, August 1, 2018 - link
One thing has always confused me about these benchmarks. Does performance get progressively worse as the drive fills up? For example, the ATSB - Light average latency for the drive is 48 mu empty and 330 mu full. Does that mean when the drive is 50% full the latency would be around 189 mu? Or does it run at 48 mu until the drive hits 100% full? Same for the average data rate.Billy Tallis - Wednesday, August 1, 2018 - link
I think there's usually a threshold at which performance drops pretty rapidly because the SLC cache or spare area is no longer large enough. Unfortunately, determining the shape of the curve and where the threshold is (if there is one) is extremely time-consuming, and the tools used for the ATSB tests don't make it easy to test multiple drives in parallel.I did run the Heavy and Light tests on this drive with it 80% full and the results were similar to the 100% full case. But manual overprovisioning like that doesn't necessarily have the same impact that re-tuning the firmware would. A typical variable-size SLC cache won't be significantly larger for an 80% full drive than for a 100% full drive.
And there's still the problem that the ATSB tests don't give the drive any long idle periods to flush the SLC cache. The SLC cache on a full drive might be large enough to handle the Heavy test reasonably well if it gets a realistic amount of idle time to flush the cache mid-test. But that would take the Heavy test from 1.5 hours to a full day.
DigitalFreak - Wednesday, August 1, 2018 - link
Understandable. With the huge performance difference between empty and full with this controller, I was just curious at what percentage used the drive performance tanked. Based on your test we already know that 80% full is just as bad as 100%. Hopefully it's not any lower than that.justaviking - Wednesday, August 1, 2018 - link
I had the exact same question. How full is full?If the performance hit did not occur until 95% full or more, then it would be easily avoidable and acceptable (to me). If it happens at 30% full, it's a deal breaker. Or a linear degredation would also unacceptable to me since the degredation is so extreme.
I STRONGLY ENCOURAGE taking the time to explore the "degradation curve" relative to "fullness" for this drive, since it is so dramatic. It could make a special article of the type AnandTech excels at.
29a - Wednesday, August 1, 2018 - link
I agree.jtd871 - Wednesday, August 1, 2018 - link
How long of a "long idle time" do you need? Are you talking about 1.5h run time for ATSB to 8h or 24h with sufficiently long "long idle times"?Billy Tallis - Wednesday, August 1, 2018 - link
Currently, the ATSB tests cut all idle times down to a maximum of 25ms. I suspect that idle times on the order of seconds would be sufficient, but I don't think we even still have the original traces with the full idle times. In the near future I'll do some SYSmark runs with a mostly-full drive; that's a similar intensity of storage workload to the ATSB light, but with a fairly realistic pacing including idle.I'll also try to compare the power data against the performance test duration for the synthetic tests. That should reveal how long the drive took to return to idle after the writing stopped, and give us a pretty good idea of how quickly the drive can empty the SLC cache and how high of a duty cycle it can sustain for writes at full speed.
Dark_wizzie - Wednesday, August 1, 2018 - link
A larger drive helps mitigate the issues because 1) Larger drives tend to have large SLC cache? Or 2) There is more normal free space for the drive?Billy Tallis - Wednesday, August 1, 2018 - link
Both, in a big way when it's 2TB, and especially when you have a variable-size SLC cache. A mostly-empty 2TB drive can have over 100GB of SLC cache, which is absolutely impossible to fill up with any real-world client workload.mattrparks - Wednesday, August 1, 2018 - link
I wonder if...I think you could get similar results (stellar performance characteristics at low drive usage) by using a larger DRAM read/write cache when the drive mapping table is not taking up as much RAM. With 2GB of DDR4, let's say arbitrarily that 1.5GB of that is used by FTL page mapping tables when the drive is full. What if you found a way in firmware to manage your memory such that when most of the drive FTL is unmapped, that you could use say only 0.5GB for the mapping table and have an extra 1GB available for caching? Many of the synthetic tests could be gamed by keeping that much drive cache. I don't remember your drive testing methodology fully, but perhaps a full power cycle of the drive after the data is written, before the read tests, would make sure that all the performance is indeed SLC speed and not just enormous amounts of caching.