What is needed is a QLC drive which behaves like SLC up to 1/4 filled capacity, then converts some capacity to MLC up to 1/2, then to TLC up to 3/4th, and only when completely full is completely QLC.
Isnt the Intel drive the one with huge SLC cache 665p . I wonder what would be the application that can fill its huge SLC cache. 280 GB of SLC for a 2 TB drive . Actually is better than this one . Probably costs almost the same and has 280 GB of SLC. Imagine that they have to use 1 TB chips for that 320GB drive so it will be close to intel 2TB QLC in BOM cost.
but it casues a lot of rewrites if you convert back and forth. I would love to get hardware storemi solution, like 32 GB of optane that would take all 4k or smaller stuff, 1 TB of nand for everything between 4k and let's say 4MB and 20 TB of HDD for bigger things. that stuff would be as epic as epyc. sssssshd
That many steps of repacking data would kill the overall write endurance. There's also just not that big a performance gap between MLC and TLC, which is why almost no products use MLC anymore. Using a MLC cache instead of SLC makes some sense (see Realtek controllers), but not having four layers of caching.
That's still a ton of write amplification for little to no benefit—possibly even significant harm to performance, because compacting data takes time, and if you're constantly trying to use the least-dense data representation you can get away with, you'll have to do a lot of compaction on a just-in-time basis rather than during idle time.
40k P/E cycles, does not look so bad with images that told me true SLC survived 100k without issues. Gaining ~20x the performance since then is worth it?
Older planar SLC drives were manufactured with comparably big floating gates that were, by nature of their physical size, a lot more durable than modern 3D charge traps. In the name of capacity improvements, we have significant shrinkage so part of that durability loss is due to size and not the number of bit states per cell.
What's the point? If they increase write endurance by 4x but only have 1/3rd the capacity, they are only improving total drive write capacity by 33%. IDK... just doesn't seem worth it to me.
It's not only about endurance, but also sustained write performance. In fact, I'd say mainly performance.
Oh, and check out the temperature range. Both that and power-off data retention time should be additional beneficiaries of reducing the number of bits per cell.
someone have a link to the definition of pseudo-SLC? that is, isn't a cell just a cell? modulo fab node size, of course. IOW, isn't the xLC status a function *only* of the controller?
The memory array is the same for QLC and SLC, but a QLC die requires more peripheral circuitry than a SLC-only die. (Though in practice, the SLC-only dies that are being made today tend to have more peripheral circuitry because they use smaller page and block sizes to optimize for performance over density.)
When you start packing multiple bits per cell, it seems to me that you'd need circuitry that can set and interpret different charge levels.
Also, I remember reading that one reason MLC (or was it TLC?) is slower to write is that the charge needs to be checked and often a cell must be re-written to get the right amount of charge.
The consumer PC market is generally driven by cost to the consumer. Once a technology becomes slightly cheaper to produce (and thus sell), economies of scale drive the cost to consumers even lower, to the point where a superior but less economic technology eventually bites the dust. Also bear in mind that manufacturers are driven by *total* profits, they have little incentive to maintain a product which is individually lucrative (say 90% profit) when they can sell 1000x as many parts at 1%.
Enterprise market is different however. Cost as a parameter vies with reliability, etc.
You can still buy (Enterprise) SLC drives at about $5 per GB. But to be fair, at that price, consumers would be looking at Optane I would imagine.
Cost for the 320GB SLC should be similar to a 1TB TLC drive, which is ~$150 at retail plus the mark-up for industrial grade rather than consumer grade. The Intel Optane 800P was $199 for 118GB, and was only faster for random reads.
So 905p at 480GB is about $600, which is $1.25/GB. If this drive is $150 for a 320GB, thats $0.46/GB. And if it sells for $200, then it's $0.625/GB. So Optane ends up been between 2-2.6X more expensive per GB. But, you get way better and consistent random read and write IO, and no write amplification to worry about, so maybe similar endurance. So depending on your workload, I can definitely see a case for paying more for Optane, e.g., databases.
If you have a workload with really heavy sustained random writes, or if you need super low random read latency, then Optane's performance could be advantageous. But this isn't a Z-NAND or XL-Flash drive that's trying to compete in that space. It's a drive for embedded and industrial use cases where you want to keep it in service for way longer than 5 years.
The SSDs are getting more complex. I wouldn't be surprised if the newer controllers start having 8+ cores to deal with the complex algorithms involved in the multi tiered read/write schemes that seem to be needed now. NVME host side cache -> SSD DRAM cache -> 8x+ nand (slc -> tlc -> qlc). They are going to have a hard time saturating pcie 5.0/6.0 with these slower qlc/tlc solutions. Time to get clever.
Actually, it's going the other direction. Enterprise SSDs are starting to expose the raw flash, and just let the host CPU do all of the management. I forget what the standard is called...
oddly, in a comment further above, you say that the NAND array is supported, in situ, by circuitry (hardwired logic?) to handle R/W to TLC & QLC? it's always seemed most logical (hehe) to me that the controller is the best place to put that control. neither the NAND nor cpu. after all, the signal send to the NAND array is already at the value/voltage of the multi-bit value. why would the NAND array need to do any more with the value than simple SLC? just get/set the cell? a link would suffice. anyone actually know?
You need to do wear-leveling, ECC, bad block relocation, and potentially managing pseudo-SLC buffering. A lot of that can be done at the filesystem level. Putting that level of control in the host CPU can avoid some redundancy, improve QoS, and perhaps benefit energy efficiency.
Here's an idea: put a physical dip switch on the drives, like a backup bios switch on a motherboard, so the user can select SLC or TLC mode. It would be nice to just decide to run your shiny new 2TB drive faster and longer lived at 512GB or 1TB.
Someone who wants a TLC drive will be better off buying a cheaper TLC drive. Someone who needs SLC-level long-term reliability won’t ever use that kind of toyish “feature”, which sounds like a great way to accidentally wipe the entire drive (by moving the switch) while servicing it.
?In the future we might have a Controller (host bus between chips) of embedded controllers (embedded with the flash chips inside each flash package). The niche products are for corporate spec junkies with deep products where other options are being ignored.
"The niche products are for corporate spec junkies with deep products where other options are being ignored."
I'm more of a mind that spec junkies will embrace SCM, esp. for RDBMS installs, and build a linux variant that is truly a single level 'object store' (read up on AS/400). no files, no filesystem interposed, and no tiers (or tears).
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
39 Comments
Back to Article
AndrewJacksonZA - Friday, February 21, 2020 - link
So does "high durrability" mean that it's really, /really/ durable?Alistair - Friday, February 21, 2020 - link
Darn beat me to it :)peevee - Friday, February 21, 2020 - link
What is needed is a QLC drive which behaves like SLC up to 1/4 filled capacity, then converts some capacity to MLC up to 1/2, then to TLC up to 3/4th, and only when completely full is completely QLC.RaduR - Friday, February 21, 2020 - link
Isnt the Intel drive the one with huge SLC cache 665p . I wonder what would be the application that can fill its huge SLC cache. 280 GB of SLC for a 2 TB drive . Actually is better than this one . Probably costs almost the same and has 280 GB of SLC. Imagine that they have to use 1 TB chips for that 320GB drive so it will be close to intel 2TB QLC in BOM cost.29a - Friday, February 21, 2020 - link
I'm pretty sure that's what QLC drives do.29a - Friday, February 21, 2020 - link
Minus the MLC and TLC steps.deil - Friday, February 21, 2020 - link
but it casues a lot of rewrites if you convert back and forth.I would love to get hardware storemi solution,
like 32 GB of optane that would take all 4k or smaller stuff,
1 TB of nand for everything between 4k and let's say 4MB
and 20 TB of HDD for bigger things.
that stuff would be as epic as epyc. sssssshd
29a - Saturday, February 22, 2020 - link
I'm pretty sure it only needs converted once, reads are straight from QLC.Billy Tallis - Friday, February 21, 2020 - link
That many steps of repacking data would kill the overall write endurance. There's also just not that big a performance gap between MLC and TLC, which is why almost no products use MLC anymore. Using a MLC cache instead of SLC makes some sense (see Realtek controllers), but not having four layers of caching.peevee - Friday, February 21, 2020 - link
There isn't really that many steps, just up to 3.Billy Tallis - Friday, February 21, 2020 - link
That's still a ton of write amplification for little to no benefit—possibly even significant harm to performance, because compacting data takes time, and if you're constantly trying to use the least-dense data representation you can get away with, you'll have to do a lot of compaction on a just-in-time basis rather than during idle time.deil - Friday, February 21, 2020 - link
40k P/E cycles, does not look so bad with images that told me true SLC survived 100k without issues. Gaining ~20x the performance since then is worth it?PeachNCream - Friday, February 21, 2020 - link
Older planar SLC drives were manufactured with comparably big floating gates that were, by nature of their physical size, a lot more durable than modern 3D charge traps. In the name of capacity improvements, we have significant shrinkage so part of that durability loss is due to size and not the number of bit states per cell.mode_13h - Saturday, February 22, 2020 - link
No, just means it's capable of handling lots of dur's.thetrashcanisfull - Friday, February 21, 2020 - link
What's the point? If they increase write endurance by 4x but only have 1/3rd the capacity, they are only improving total drive write capacity by 33%. IDK... just doesn't seem worth it to me.mode_13h - Saturday, February 22, 2020 - link
It's not only about endurance, but also sustained write performance. In fact, I'd say mainly performance.Oh, and check out the temperature range. Both that and power-off data retention time should be additional beneficiaries of reducing the number of bits per cell.
FunBunny2 - Friday, February 21, 2020 - link
someone have a link to the definition of pseudo-SLC? that is, isn't a cell just a cell? modulo fab node size, of course. IOW, isn't the xLC status a function *only* of the controller?Billy Tallis - Friday, February 21, 2020 - link
The memory array is the same for QLC and SLC, but a QLC die requires more peripheral circuitry than a SLC-only die. (Though in practice, the SLC-only dies that are being made today tend to have more peripheral circuitry because they use smaller page and block sizes to optimize for performance over density.)FunBunny2 - Friday, February 21, 2020 - link
thanxmode_13h - Saturday, February 22, 2020 - link
When you start packing multiple bits per cell, it seems to me that you'd need circuitry that can set and interpret different charge levels.Also, I remember reading that one reason MLC (or was it TLC?) is slower to write is that the charge needs to be checked and often a cell must be re-written to get the right amount of charge.
Supercell99 - Friday, February 21, 2020 - link
Why don't they just make SLC drives again? Why did they stop? Capacity ?timbotim - Friday, February 21, 2020 - link
The consumer PC market is generally driven by cost to the consumer. Once a technology becomes slightly cheaper to produce (and thus sell), economies of scale drive the cost to consumers even lower, to the point where a superior but less economic technology eventually bites the dust. Also bear in mind that manufacturers are driven by *total* profits, they have little incentive to maintain a product which is individually lucrative (say 90% profit) when they can sell 1000x as many parts at 1%.Enterprise market is different however. Cost as a parameter vies with reliability, etc.
You can still buy (Enterprise) SLC drives at about $5 per GB. But to be fair, at that price, consumers would be looking at Optane I would imagine.
nandnandnand - Friday, February 21, 2020 - link
Depending on the pricing, 3D XPoint could soundly beat this.Billy Tallis - Friday, February 21, 2020 - link
Cost for the 320GB SLC should be similar to a 1TB TLC drive, which is ~$150 at retail plus the mark-up for industrial grade rather than consumer grade. The Intel Optane 800P was $199 for 118GB, and was only faster for random reads.hammer256 - Friday, February 21, 2020 - link
So 905p at 480GB is about $600, which is $1.25/GB. If this drive is $150 for a 320GB, thats $0.46/GB. And if it sells for $200, then it's $0.625/GB. So Optane ends up been between 2-2.6X more expensive per GB. But, you get way better and consistent random read and write IO, and no write amplification to worry about, so maybe similar endurance. So depending on your workload, I can definitely see a case for paying more for Optane, e.g., databases.Billy Tallis - Friday, February 21, 2020 - link
If you have a workload with really heavy sustained random writes, or if you need super low random read latency, then Optane's performance could be advantageous. But this isn't a Z-NAND or XL-Flash drive that's trying to compete in that space. It's a drive for embedded and industrial use cases where you want to keep it in service for way longer than 5 years.Soulkeeper - Saturday, February 22, 2020 - link
The SSDs are getting more complex. I wouldn't be surprised if the newer controllers start having 8+ cores to deal with the complex algorithms involved in the multi tiered read/write schemes that seem to be needed now. NVME host side cache -> SSD DRAM cache -> 8x+ nand (slc -> tlc -> qlc). They are going to have a hard time saturating pcie 5.0/6.0 with these slower qlc/tlc solutions. Time to get clever.mode_13h - Saturday, February 22, 2020 - link
Actually, it's going the other direction. Enterprise SSDs are starting to expose the raw flash, and just let the host CPU do all of the management. I forget what the standard is called...FunBunny2 - Sunday, February 23, 2020 - link
"I forget what the standard is called..."oddly, in a comment further above, you say that the NAND array is supported, in situ, by circuitry (hardwired logic?) to handle R/W to TLC & QLC? it's always seemed most logical (hehe) to me that the controller is the best place to put that control. neither the NAND nor cpu. after all, the signal send to the NAND array is already at the value/voltage of the multi-bit value. why would the NAND array need to do any more with the value than simple SLC? just get/set the cell? a link would suffice. anyone actually know?
mode_13h - Wednesday, February 26, 2020 - link
You need to do wear-leveling, ECC, bad block relocation, and potentially managing pseudo-SLC buffering. A lot of that can be done at the filesystem level. Putting that level of control in the host CPU can avoid some redundancy, improve QoS, and perhaps benefit energy efficiency.MASSAMKULABOX - Monday, February 24, 2020 - link
Host managed Buffers ..iirc .. sounds like SAN type stuffmode_13h - Wednesday, February 26, 2020 - link
I'm pretty sure it's something else. This is about the SSD exposing the NAND array and letting the host manage wear-leveling, etc.Soulkeeper - Saturday, February 22, 2020 - link
Here's an idea: put a physical dip switch on the drives, like a backup bios switch on a motherboard, so the user can select SLC or TLC mode. It would be nice to just decide to run your shiny new 2TB drive faster and longer lived at 512GB or 1TB.shelbystripes - Saturday, February 22, 2020 - link
Someone who wants a TLC drive will be better off buying a cheaper TLC drive. Someone who needs SLC-level long-term reliability won’t ever use that kind of toyish “feature”, which sounds like a great way to accidentally wipe the entire drive (by moving the switch) while servicing it.mode_13h - Saturday, February 22, 2020 - link
On the one hand, I wonder why you need DIP switches for that - couldn't it be configured via software?On the other hand, I wonder why stop at DIP switches. Jumpers FTMFW!
Alexvrb - Sunday, February 23, 2020 - link
I miss jumpers.FunBunny2 - Sunday, February 23, 2020 - link
"I miss jumpers."Twiggy made them famous. You do remember Twiggy, right?
tygrus - Sunday, February 23, 2020 - link
?In the future we might have a Controller (host bus between chips) of embedded controllers (embedded with the flash chips inside each flash package). The niche products are for corporate spec junkies with deep products where other options are being ignored.FunBunny2 - Wednesday, February 26, 2020 - link
"The niche products are for corporate spec junkies with deep products where other options are being ignored."I'm more of a mind that spec junkies will embrace SCM, esp. for RDBMS installs, and build a linux variant that is truly a single level 'object store' (read up on AS/400). no files, no filesystem interposed, and no tiers (or tears).