I see you have discovered The Register. Welcome!
As the article points out, these drives consume up to ~10W under load. That's actually a lot of power for something with very, very little thermal mass - around 10 grams, and a heat capacity of around 400J/KgC is common for PCBs and chips. 0.4J/gC means that for just one second under full load, if the heat is generated evenly across the entire device, it will heat up 2.5 degrees C. Assuming no cooling, that's 24 seconds until it hits is thermal throttling point.
From the article:
> The amount of activity taking place on the gumstick-sized M.2 form factor means higher temps not only for the storage controller, but for the NAND flash itself.
> NAND, Tanguy explains, is happiest within a relatively narrow temperature band. "NAND flash actually likes to be 'hot' in that 60° to 70° [celcius] range in order to program a cell because when it's that hot, those electrons can move a little bit easier," he explained.
> Go a little too hot — say 80°C — and things become problematic, however. At these temps, you risk the SSD's built-in safety mechanisms forcibly powering down the system to prevent damage. However, before this happens users are likely to see the performance of their drives plummet, as the SSD's controller throttles itself to prevent data loss.
FYI, Tanguy according to his linkedin is the principle product engineer for Micron.
Could ask the same thing about all the extra silicon in GPUs that adds hardware acceleration for video encoding/decoding.
This is a fantasy with questionable benefits at best that don't outweigh the downsides.
Yes. That seems ideal to me. Microsoft, Apple, open source contributors. Today what you have is a closed-source translation layer written by the kinds of people who write PC BIOSes, i.e. the biggest idiots in the software industry. I would be much happier with an OS vendor flash storage stack. For all I know, I am already using something like that from Apple. And I assure you that large-scale server builders like Amazon and Google are already doing it this way.
The largest companies have other alignments that are not often discussed openly.
That seems such a bizarre take. You think it's better that the crappy code is given to you as blackbox firmware with no oversight rather than in the open written to kernels quality standard where it can at least hypothetically be improved?
If you have any experience with high performance networking equipment, you know that pure switching fabric ASICs generates a lot of heat on its own. Hell, even a dumb 5-port gigabit ethernet switch generates a surprising amount of heat, they are always warm to the touch.
I really doubt that handling the FTL layer on the controller adds that much extra power draw. A dumb PCIE <-> NAND switching ASIC will also have cooling problems.
The faster you switch a gate, the more often you have to pay the switching price, which cannot go too low, else the thermal noise would overcome it. So you spend roughly 10x the energy switching a 10 Gbps stream as you use for 1 Gbps stream. Newer, smaller gates consume less energy switching, but not 10x less.
There is also the fact that they are consumer devices and margins have to be high so quality of the product is tailored accordingly.
1) MLC/TLC/QLC work more like 4/8/16-tone grayscale e-paper than flash: e.g. 0x10 = (1,0,1,0), that’s “4 level/bits per cell”. And it’s not a single pulse of 0x10 voltage into a memory cell, more like repetitive pulses from 0b1111 to enough millivolts below 0b1011. Readout is probably more complicated, let alone lifecycle management. Those businesses might be more involved than it’s worth filesystem researchers time.
2) It was often said, at least years ago, that the considerable fraction of heat in NVMe SSDs comes from PCIe serialization/deserialization(SerDes), rather than payload data processing or NAND programming.
If both of above are true, maybe it’s PCIe that should be replaced, with something more like the original PCI?
Shoveling IOPS into a bus is an easily parallelizable problem, while NAND-flash memory has a very high theoretical floor on its capacitance. Any good engineer would optimize the CPU part up to the point where it's only a bit worse than the flash, and stop there because there isn't much gain on going further.
If that's the case, you will see the CPU being the bottleneck on your device, but it's actually the memory that constrains the design.
That is, unless the CPU comes from some off the shelve design that can't be changed due to volume constraints. But I don't think SSDs have that kind of low volume.
Most SSDs (with exceptions like Samsung's) simply use SiliconMotion's IP (https://www.siliconmotion.com/products/client/detail) for their controllers.
> But I don't think SSDs have that kind of low volume.
If a custom design adds a cent or two to the BOM then it doesn't matter, but when you need to verify that the changes works as intented and that the data isn't corrupted (beyond specifications) that's a lot of cents to be saved. Plus, SiliconMotion can request to TSMC to fabricate it at a lower cost per unit (because there is only one pattern to manufacture) than to customise the controllers for each drive.
Speaking about SSD controllers in general: they do use off-the-shelf ARM CPU core designs (eg. Cortex-R series), but those are usually the least important IP blocks in the chip. The ARM CPU cores are mostly handling the control plane rather than the data plane, and the latter is what is performance-critical and power-hungry when pushing many GB/s.