Looking Forward

It's great to see that Silicon Motion is continuing to improve on the greatest performance weakness of flash-based SSDs: random read latency. The SM2262 provided a surprising jump in random read performance, surpassing even MLC SSDs. The SM2262EN takes things a bit further, and Intel's Optane SSDs now lead by only a factor of 6 or so. This kind of improvement has the greatest potential to improve real-world performance as perceived by end users, and random reads are the workload where flash-based SSDs are furthest from saturating the SATA or PCIe host interfaces. (The Intel/Micron 64L 3D TLC NAND probably deserves some credit for enabling these improvements, too.)

The SM2262EN is well-tuned to turn in stellar scores on many other benchmarks, and it is near the top of the charts for almost all of our synthetic benchmarks. However, it is clear that Silicon Motion is making some serious tradeoffs to attain these scores. The SM2262EN's performance degrades severely when the drive is full, and this effect seems to be even stronger than for the SM2262 drives we've tested. Silicon Motion has developed the fastest SLC write cache currently available, but once it's full, the situation isn't pretty.

For a 2TB drive like our review sample, I'm not too worried about these performance hits: it's pretty hard in practice to fill a really large SLC cache, and this isn't the easiest drive to fill up to 100% with real data. Our toughest benchmarks are well beyond the range of normal usage patterns, so abysmal scores there don't necessarily mean the drive is bad or unsuitable for power users. What it means is that Silicon Motion needs to be careful not to go too far with their optimization efforts. With the lower capacity drives that will account for the bulk of SM2262EN sales, it will be much easier to bump against the limits of which scenarios the controller can handle well. It may be necessary to use a much higher overprovisioning ratio on the lower capacity models, in order to ensure that they can maintain high performance even under heavy workloads. Products using the SM2262EN will live or die based on how well it can avoid falling into low-performing pits when presented with real-world workloads.

Idle power management seems to be broken on our SM2262EN sample, which is a disappointment because the SM2262 drives currently on the market offer the best trouble-free power management situation out of all the NVMe drives we've tested. Silicon Motion needs to ensure that this bug doesn't make it into retail products.

Consumer SSD prices have been declining for most of the year, in large part spurred by the adoption of 64L 3D TLC by the many brands that do not manufacture their own flash. Last year saw 64L 3D NAND hit the market in a limited number of products from the biggest players in the market, but now that NAND is in use everywhere and in plentiful supply. The downward trend is likely to continue in the near future, so even though the SM2262EN may command some premium over the base SM2262, the product lines that adopt the updated controller will probably do so at or below the current prices.

Looking further forward, we don't have much information about the rest of Silicon Motion's roadmap. We know they're working on PCIe 4.0 support, but this won't be needed in the consumer market anytime soon. They have also developed a new generation of more robust LDPC error correction intended to better support QLC NAND, and this will likely show up in the next generation of controllers from Silicon Motion. A full refresh of Silicon Motion's NVMe controller lineup is probably still at least a year away, so the SM2262EN may need to stay competitive for quite a while. It will probably be paired with 96L 3D NAND as soon as it is available, which may provide further incremental increases to performance and power efficiency.

The SM2262EN may also end up paired with QLC NAND for a very fast and cheap bulk storage drive. Such a drive would definitely benefit from the fast and aggressive SLC caching strategy used by the SM2262EN.

 

Power Management
POST A COMMENT

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. Reply
  • 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.
    Reply
  • 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. Reply
  • 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.
    Reply
  • 29a - Wednesday, August 1, 2018 - link

    I agree. Reply
  • 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"? Reply
  • 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.
    Reply
  • 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? Reply
  • 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. Reply
  • 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. Reply

Log in

Don't have an account? Sign up now