QLC could be game changing, Toshiba did show off a prototype 100TB QLC SSD at Flash Memory Summit two weeks ago. But a QLC SSD really shouldn't be anything lesser than 1TB in capacity IMHO, otherwise the performance and endurance will be ugly.
Toshiba said they are waiting for 64-layer QLC to come online later this year or early next. I think they are currently at 48-layer. This will get them from 256Gbit to 384Gbit, and when factoring in 4 bits per cell, I suspect the minimum marketable capacity will be 1TB because they will effectively have 512GB per package. Having one NAND die on an SSD is basically making an exotic USB flash drive. Even if the controller is multichannel, the queue depth performance will be terrible.
it would be 512Gb not GB -- thats Gigabit -- so 64GB per die. You would still need 16 of them to make 1TB. (Which is the max of this particular controller)
No, his maths are correct (even if skipping a few steps). He is talking about dies (silicon wafer parts) reaching 512Gb. Each package stacks up to 8 dies in it, making for 512GB per package, hence his post about requiring multiple packages for parallelism and hence requiring at least 1TB for the whole drive (2 packages).
The ITRS report suggests that TLC will be mainstream for another 10-15 years. QLC is more aimed at Worm (write once, read many) applications that are more for CDN type applications and cold storage. The question is if the data for QLC can stay stable for a sufficient length of time for cold storage will be a difficult one
It's not that big of problem. Even if you have to rewrite once 6 months or 12 months. It doesn't matter because those rewrites don't have write amplification.
The ITRS report also sometimes misses the mark and gets blindsided by some developments. NAND industry is looking at ways to increase density and with the step back in XY for 3D NAND, they have been talking about QLC for a while (as cell durability in 3D NAND came back up). Other forms of storage are developing too, like RRAM, coming hopefully next year after over a year of drumming up by intel (Xpoint).
You would prefer to pay a premium for a relatively slow niche SSD product? Frankly for same money or less you'd be as well off tossing a $20 PCIe x1 SSD controller into the system then using a conventional SATA SSD.
I could be wrong, someone could make an inexpensive PCIe SSD but I don't see the sales rate being enough to bring it down near SATA SSD price points. Besides, PCIe slots are usually more precious than SATA ports.
Question from a dummy: this supports 15nm TLC among others. But why do controllers care about the transistor feature size of the memory they're controlling?
For starters, it would be important for determining optimization for wear leveling. Second probably has to do with gate voltage differences and such between the different NANDs.
It's mostly a matter of how robust the error correction is. Most controllers that don't have LDPC or similar won't advertise support for 16/15nm TLC even though they could actually interact with it given the right firmware, because they wouldn't be able to deliver acceptable reliability without stronger error correction. The industry consensus is that LDPC is good enough for 15nm planar TLC and that 3D QLC is expected to be comparable in reliability. Some controllers (eg. Maxiotek 81xx) that don't have LDPC are intended for use with only 3D TLC but planar or 3D MLC.
I've always wondered why the error correction isn't handled on the FLASH itself, rather than in the controller. That way, the die geometry and error correction in use would be irrelevant.
Of course, having it on the controller allows the error correction to be shared, optimizing die area, but is the error correction really that big? An LDPC implementation is probably noise in terms of transistors and die area, and it simply makes more sense to put it at the FLASH package level.
TLC is bad with regards to reliability versus capacity (SLC and MLC are tied in this regard) and things spiral downwards quickly from there on.
Reliability (as in: the voltage interval that describes one cell state) halves for each bit added (so it goes down exponentially) whereas capacity only increases by one bit for each bit added (duh).
Moving from SLC to MLC halves the reliability and doubles the capacity (= same ratio as SLC).
SLC/MLC to TLC means 1/4 the reliability and 3 times the capacity (= 0.75% ratio of SLC or MLC).
SLC/MLC to QLC means 1/8 and 4x (= 0.50% of SLC or MLC).
Things get progressively worse as you move away from MLC (two bits per cell). Stick with SLC if you need absolute performance and go with MLC if you need more capacity.
I wouldn't' buy anything below MLC endurance. I am also not very keen on nand produced below 40nm either. That being said, QLC might have its applications, for data that is going to be stored long term without modifying it, but then again the drop in endurance is approaching a dangerous level. They should focus on other technologies with more potential for density instead of pushing nand this way.
It has been known since the beginning that NAND would evolve into this direction, both Intel and Micron mentioned this when introducing proof-of-concept SSDs. Transition to vertical stacking eases the blow of reduced reliability, but even for home users QLC and beyond has use - there are data rewritten almost never. If QLC proves to be suitable for long term storage, it may even be that missing piece of technology that kills hard drives in mass market. For other scenarios, even in SOHO environment TLC is better suited, think of 5-20 workstation office, with regular daily, or weekly backups, QLC may be too strained even after year, while TLC will still be perfectly fine during expected lifetime of solution.
In enterprise/data center every form of flash and memory technology has it's place, from HDDs, to rampools, and everything in-between, SLC to QLC. Just not every system needs all of them.
> SLC/MLC to QLC means 1/8 and 4x (= 0.50% of SLC or MLC).
It's actually far worse than that, about one magnitude per step just considering the amount of P/E cycles. But the important question is a different one: What will happen if the drive is used as cold storage rather than being constantly powered: If the device is online than it's possible to keep track of bits drifting away and refresh them but what would you do in the cold storage (worst case: WORM) case?
Use of 3d SSD changes things a bit, especially with "DRAMless" SSDs. If you can use a 3d trench in "SLC mode", you can keep a [moving] buffer that takes the endurance abuse [better] and only writes things out to TLC (or QLC) when needed. *Hopefully* this keeps write multiplication from killing your SSD.
I think that QLC really is just a marketing checkbox for this thing. I find the whole idea of software controlled memory silly, and would rather see the thing read and write with nothing but pure hardware and let the software control the overall management. If you are running two ARMs, best guess is that it is all software and that switching from TLC to QLC is little more than a few lines of software (at least if you started out assuming that, stretching from a "no more than TLC" assumption is a different story).
You're mad there are ARM cores on there instead of fixed function hardware? You know that pretty much all SSD controllers use some form of general purpose CPU, most of them Cortex R series. In fact most hard drives use Cortex R series cores as well.
Remember these are not enterprise solutions. Take the typical PC, with an owner that has $100 to spend. That will get a 240GB MLC SSD, but it will get a 480GB TLC. The extra 240GB is a whole lot of room for wear leveling, and just how many years is the owner going to keep using same PC before upgrading to SATA8 or whatever and a much larger SSD at that point in time?
Remember that the most writes an average PC users does, is merely their browser caching what they surf, or the OS itself deciding what it wants to do. Many browsers can have their disk cache turned off, or with DRAM so cheap, disable pagefile too or divert to a ramdrive. Essentially most of the problems with lower write cycles are just badly written applications and OS that didn't keep up with hardware tech advances. It was just plain stupid all along that Windows incessantly writes to HDD, remember back in the day of win95 when you could be typing up an Office doc and the lone HDD would actually time out and sleep after 15 minutes if your autosave interval was longer than that, and this with only 32MB main memory. It's almost shameful how much of a waste modern hardware is.
Sounds great.Very few need even more perf so a budget solution that is a lot faster than SATA is exactly what was needed.Hopefully random perf is decent too.
Hesitantly waxing philosophical if I may, the whole storage thing seems primitive vs best practice in the hard copy paradigm.
Methods like; raid0, raid 5, full backups, a single primary source for a file, all files in same similar storage reqardless of usage or urgency - all seem to have little connection with how a library/office/government... would have organised and secured their records of yore.
We may install an important app on our premium storage, but many of the files may be rarely used or non urgent, but we are too short of unaffordable premium space for apps with files that could profit from relocating to better media. Any kind of manual speed tuning becomes exhausting and fraught, fast.
As a poster here said, all types of storage have some use, somewhere in the server world. It exist there, but it seems a killer mainstream app too - to interpose an overall file controller, which intelligently manages a hierarchical pool of storage resources.
all we want is that we get; prompt, security, ~fireproof, work resumed ~fast after a lesser fail, no zillions of duplicates on premium storage ~as now, files on optimal media given usage patterns,....
It ties in also with the very modern problem of minimising cloud backup storage charges. Duplicates waste $.
To illustrate, a cheap ~8GB pc; raid 0 pair of 128GB nvme, 256g nvme, sata hdd, sata hdd raid, esata for full archives, would offer the ~gamut of media in even stages of strengths and weaknesses.
Let the computer juggle them into something much greater than the sum of the parts.
Vega's HBCC seems a step in this direction - managing a cache pool, which includes storage and nvme.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
25 Comments
Back to Article
revanchrist - Wednesday, August 17, 2016 - link
QLC could be game changing, Toshiba did show off a prototype 100TB QLC SSD at Flash Memory Summit two weeks ago. But a QLC SSD really shouldn't be anything lesser than 1TB in capacity IMHO, otherwise the performance and endurance will be ugly.ImSpartacus - Wednesday, August 17, 2016 - link
Yeah, I don't think you'd see folks do anything less than a TB or maybe a half TB.Samus - Wednesday, August 17, 2016 - link
Toshiba said they are waiting for 64-layer QLC to come online later this year or early next. I think they are currently at 48-layer. This will get them from 256Gbit to 384Gbit, and when factoring in 4 bits per cell, I suspect the minimum marketable capacity will be 1TB because they will effectively have 512GB per package. Having one NAND die on an SSD is basically making an exotic USB flash drive. Even if the controller is multichannel, the queue depth performance will be terrible.extide - Thursday, August 18, 2016 - link
it would be 512Gb not GB -- thats Gigabit -- so 64GB per die. You would still need 16 of them to make 1TB. (Which is the max of this particular controller)frenchy_2001 - Thursday, August 18, 2016 - link
No, his maths are correct (even if skipping a few steps).He is talking about dies (silicon wafer parts) reaching 512Gb.
Each package stacks up to 8 dies in it, making for 512GB per package, hence his post about requiring multiple packages for parallelism and hence requiring at least 1TB for the whole drive (2 packages).
Ian Cutress - Wednesday, August 17, 2016 - link
The ITRS report suggests that TLC will be mainstream for another 10-15 years. QLC is more aimed at Worm (write once, read many) applications that are more for CDN type applications and cold storage. The question is if the data for QLC can stay stable for a sufficient length of time for cold storage will be a difficult oneBlack_ - Thursday, August 18, 2016 - link
It's not that big of problem. Even if you have to rewrite once 6 months or 12 months. It doesn't matter because those rewrites don't have write amplification.frenchy_2001 - Thursday, August 18, 2016 - link
The ITRS report also sometimes misses the mark and gets blindsided by some developments.NAND industry is looking at ways to increase density and with the step back in XY for 3D NAND, they have been talking about QLC for a while (as cell durability in 3D NAND came back up).
Other forms of storage are developing too, like RRAM, coming hopefully next year after over a year of drumming up by intel (Xpoint).
Flunk - Wednesday, August 17, 2016 - link
It's nice to see new PCI-E controllers that can bring down the price of PCI-E drives. This only means good things for consumers.TeXWiller - Thursday, August 18, 2016 - link
I'm too waiting to put those extra PCIe x1 slots into good use in a couple of older machines. 88NV1140 would fit perfectly in that scenario.mindless1 - Sunday, September 4, 2016 - link
You would prefer to pay a premium for a relatively slow niche SSD product? Frankly for same money or less you'd be as well off tossing a $20 PCIe x1 SSD controller into the system then using a conventional SATA SSD.I could be wrong, someone could make an inexpensive PCIe SSD but I don't see the sales rate being enough to bring it down near SATA SSD price points. Besides, PCIe slots are usually more precious than SATA ports.
rpg1966 - Wednesday, August 17, 2016 - link
Question from a dummy: this supports 15nm TLC among others. But why do controllers care about the transistor feature size of the memory they're controlling?Shadow7037932 - Wednesday, August 17, 2016 - link
For starters, it would be important for determining optimization for wear leveling. Second probably has to do with gate voltage differences and such between the different NANDs.Billy Tallis - Wednesday, August 17, 2016 - link
It's mostly a matter of how robust the error correction is. Most controllers that don't have LDPC or similar won't advertise support for 16/15nm TLC even though they could actually interact with it given the right firmware, because they wouldn't be able to deliver acceptable reliability without stronger error correction. The industry consensus is that LDPC is good enough for 15nm planar TLC and that 3D QLC is expected to be comparable in reliability. Some controllers (eg. Maxiotek 81xx) that don't have LDPC are intended for use with only 3D TLC but planar or 3D MLC.TheWrongChristian - Wednesday, August 24, 2016 - link
I've always wondered why the error correction isn't handled on the FLASH itself, rather than in the controller. That way, the die geometry and error correction in use would be irrelevant.Of course, having it on the controller allows the error correction to be shared, optimizing die area, but is the error correction really that big? An LDPC implementation is probably noise in terms of transistors and die area, and it simply makes more sense to put it at the FLASH package level.
What am I missing?
Arnulf - Thursday, August 18, 2016 - link
QLC is the dumbest idea ever.TLC is bad with regards to reliability versus capacity (SLC and MLC are tied in this regard) and things spiral downwards quickly from there on.
Reliability (as in: the voltage interval that describes one cell state) halves for each bit added (so it goes down exponentially) whereas capacity only increases by one bit for each bit added (duh).
Moving from SLC to MLC halves the reliability and doubles the capacity (= same ratio as SLC).
SLC/MLC to TLC means 1/4 the reliability and 3 times the capacity (= 0.75% ratio of SLC or MLC).
SLC/MLC to QLC means 1/8 and 4x (= 0.50% of SLC or MLC).
Things get progressively worse as you move away from MLC (two bits per cell). Stick with SLC if you need absolute performance and go with MLC if you need more capacity.
ddriver - Thursday, August 18, 2016 - link
I wouldn't' buy anything below MLC endurance. I am also not very keen on nand produced below 40nm either. That being said, QLC might have its applications, for data that is going to be stored long term without modifying it, but then again the drop in endurance is approaching a dangerous level. They should focus on other technologies with more potential for density instead of pushing nand this way.Vatharian - Thursday, August 18, 2016 - link
It has been known since the beginning that NAND would evolve into this direction, both Intel and Micron mentioned this when introducing proof-of-concept SSDs. Transition to vertical stacking eases the blow of reduced reliability, but even for home users QLC and beyond has use - there are data rewritten almost never. If QLC proves to be suitable for long term storage, it may even be that missing piece of technology that kills hard drives in mass market. For other scenarios, even in SOHO environment TLC is better suited, think of 5-20 workstation office, with regular daily, or weekly backups, QLC may be too strained even after year, while TLC will still be perfectly fine during expected lifetime of solution.In enterprise/data center every form of flash and memory technology has it's place, from HDDs, to rampools, and everything in-between, SLC to QLC. Just not every system needs all of them.
Daniel Egger - Thursday, August 18, 2016 - link
> SLC/MLC to QLC means 1/8 and 4x (= 0.50% of SLC or MLC).It's actually far worse than that, about one magnitude per step just considering the amount of P/E cycles. But the important question is a different one: What will happen if the drive is used as cold storage rather than being constantly powered: If the device is online than it's possible to keep track of bits drifting away and refresh them but what would you do in the cold storage (worst case: WORM) case?
wumpus - Thursday, August 18, 2016 - link
Use of 3d SSD changes things a bit, especially with "DRAMless" SSDs. If you can use a 3d trench in "SLC mode", you can keep a [moving] buffer that takes the endurance abuse [better] and only writes things out to TLC (or QLC) when needed. *Hopefully* this keeps write multiplication from killing your SSD.I think that QLC really is just a marketing checkbox for this thing. I find the whole idea of software controlled memory silly, and would rather see the thing read and write with nothing but pure hardware and let the software control the overall management. If you are running two ARMs, best guess is that it is all software and that switching from TLC to QLC is little more than a few lines of software (at least if you started out assuming that, stretching from a "no more than TLC" assumption is a different story).
extide - Thursday, August 18, 2016 - link
You're mad there are ARM cores on there instead of fixed function hardware? You know that pretty much all SSD controllers use some form of general purpose CPU, most of them Cortex R series. In fact most hard drives use Cortex R series cores as well.fanofanand - Tuesday, August 23, 2016 - link
Where do you see him being "mad"?mindless1 - Sunday, September 4, 2016 - link
Remember these are not enterprise solutions. Take the typical PC, with an owner that has $100 to spend. That will get a 240GB MLC SSD, but it will get a 480GB TLC. The extra 240GB is a whole lot of room for wear leveling, and just how many years is the owner going to keep using same PC before upgrading to SATA8 or whatever and a much larger SSD at that point in time?Remember that the most writes an average PC users does, is merely their browser caching what they surf, or the OS itself deciding what it wants to do. Many browsers can have their disk cache turned off, or with DRAM so cheap, disable pagefile too or divert to a ramdrive. Essentially most of the problems with lower write cycles are just badly written applications and OS that didn't keep up with hardware tech advances. It was just plain stupid all along that Windows incessantly writes to HDD, remember back in the day of win95 when you could be typing up an Office doc and the lone HDD would actually time out and sleep after 15 minutes if your autosave interval was longer than that, and this with only 32MB main memory. It's almost shameful how much of a waste modern hardware is.
jjj - Thursday, August 18, 2016 - link
Sounds great.Very few need even more perf so a budget solution that is a lot faster than SATA is exactly what was needed.Hopefully random perf is decent too.msroadkill612 - Thursday, September 21, 2017 - link
Hesitantly waxing philosophical if I may, the whole storage thing seems primitive vs best practice in the hard copy paradigm.Methods like; raid0, raid 5, full backups, a single primary source for a file, all files in same similar storage reqardless of usage or urgency - all seem to have little connection with how a library/office/government... would have organised and secured their records of yore.
We may install an important app on our premium storage, but many of the files may be rarely used or non urgent, but we are too short of unaffordable premium space for apps with files that could profit from relocating to better media. Any kind of manual speed tuning becomes exhausting and fraught, fast.
As a poster here said, all types of storage have some use, somewhere in the server world. It exist there, but it seems a killer mainstream app too - to interpose an overall file controller, which intelligently manages a hierarchical pool of storage resources.
all we want is that we get; prompt, security, ~fireproof, work resumed ~fast after a lesser fail, no zillions of duplicates on premium storage ~as now, files on optimal media given usage patterns,....
It ties in also with the very modern problem of minimising cloud backup storage charges. Duplicates waste $.
To illustrate, a cheap ~8GB pc; raid 0 pair of 128GB nvme, 256g nvme, sata hdd, sata hdd raid, esata for full archives, would offer the ~gamut of media in even stages of strengths and weaknesses.
Let the computer juggle them into something much greater than the sum of the parts.
Vega's HBCC seems a step in this direction - managing a cache pool, which includes storage and nvme.