By: anon2 (anon.delete@this.anon.com), July 31, 2022 10:55 pm
Room: Moderated Discussions
anon3 (not.delete@this.available.example) on July 31, 2022 10:19 pm wrote:
> Mark Roulo (nothanks.delete@this.xxx.com) on July 29, 2022 10:02 am wrote:
>
> > I do wonder if there was a fundamental issue where Intel *had* to price this where they did and
> > couldn't economically make smaller capacity DIMMs or if this was just a business decision.
>
> I think it was very difficult to fabricate. Possibly very difficult. Otherwise why would Micron not
> enjoy having a captive fab customer, or Intel spin it up themselves? If I had to speculate further, I'd
> guess there were some exotic materials involved (as so many NVRAM technologies use), and it was probably
> those that never scaled/cost-reduced/site-transferred as well as the suits were hoping for.
>
> It's a damn shame, Optane boot drives were the absolute fastest. Everyone talks about the low latency, and it's
> great, but the real win was no performance penalty for mixed read-write workloads. Which is exactly what happens
> when you boot a system these days, thanks to all the logging. And that says nothing of updates. I have never
> seen any other kind of system go through an annoying Windows Update faster than an Optane machine.
>
> 3DXPoint will be missed. Even if it never did get cheaper.
I haven't kept up with the state of NAND storage, but I don't understand the problem being solved here. Random or small writes with integrity requirement like logging or system updates is somewhere that NAND shines. Well not NAND per se, but a relatively small battery or cap backed store buffer in front of a log structured FTL solves many problems. It can be acknowledged immediately (with enough space) and it turns random writes into linear ones. So it turns all your store-side operations into a throughput problem at the NAND level. Then getting enough store bandwidth is just about parallelizing enough NAND chips and provisioning enough buffer to pipeline them.
Yes the garbage collection and write amplification problems are very hard, but that's only in the context of absolutely minimizing costs by shrinking free space as much as possible, and only for sustained store traffic at the limits of garbage collection, and limit your erase bandwidth.
The hard problem for NAND is random read latency.
> Mark Roulo (nothanks.delete@this.xxx.com) on July 29, 2022 10:02 am wrote:
>
> > I do wonder if there was a fundamental issue where Intel *had* to price this where they did and
> > couldn't economically make smaller capacity DIMMs or if this was just a business decision.
>
> I think it was very difficult to fabricate. Possibly very difficult. Otherwise why would Micron not
> enjoy having a captive fab customer, or Intel spin it up themselves? If I had to speculate further, I'd
> guess there were some exotic materials involved (as so many NVRAM technologies use), and it was probably
> those that never scaled/cost-reduced/site-transferred as well as the suits were hoping for.
>
> It's a damn shame, Optane boot drives were the absolute fastest. Everyone talks about the low latency, and it's
> great, but the real win was no performance penalty for mixed read-write workloads. Which is exactly what happens
> when you boot a system these days, thanks to all the logging. And that says nothing of updates. I have never
> seen any other kind of system go through an annoying Windows Update faster than an Optane machine.
>
> 3DXPoint will be missed. Even if it never did get cheaper.
I haven't kept up with the state of NAND storage, but I don't understand the problem being solved here. Random or small writes with integrity requirement like logging or system updates is somewhere that NAND shines. Well not NAND per se, but a relatively small battery or cap backed store buffer in front of a log structured FTL solves many problems. It can be acknowledged immediately (with enough space) and it turns random writes into linear ones. So it turns all your store-side operations into a throughput problem at the NAND level. Then getting enough store bandwidth is just about parallelizing enough NAND chips and provisioning enough buffer to pipeline them.
Yes the garbage collection and write amplification problems are very hard, but that's only in the context of absolutely minimizing costs by shrinking free space as much as possible, and only for sustained store traffic at the limits of garbage collection, and limit your erase bandwidth.
The hard problem for NAND is random read latency.
Topic | Posted By | Date |
---|---|---|
RIP Optane/XPoint | Wes Felter | 2022/07/28 07:53 PM |
RIP Optane/XPoint | Rayla | 2022/07/28 08:28 PM |
RIP Optane/XPoint | Doug S | 2022/07/28 09:00 PM |
RIP Optane/XPoint | NoSpammer | 2022/07/29 01:50 AM |
NVDIMM-N | Eric L | 2022/07/29 03:36 AM |
RIP Optane/XPoint | Michael S | 2022/07/29 04:02 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:40 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:43 AM |
RIP Optane/XPoint | Linus Torvalds | 2022/07/29 11:20 AM |
RIP Optane/XPoint | David Hess | 2022/07/29 08:59 PM |
RIP Optane/XPoint | David Hess | 2022/07/30 03:44 PM |
RIP Optane/XPoint | Doug S | 2022/07/30 10:43 PM |
RIP Optane/XPoint | rwessel | 2022/07/31 05:33 AM |
RIP Optane/XPoint | Konrad Schwarz | 2022/08/02 08:06 AM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:24 PM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:26 PM |
RIP Optane/XPoint | Adrian | 2022/08/03 01:19 AM |
RIP Optane/XPoint | anonymou5 | 2022/07/29 12:50 PM |
RIP Optane/XPoint | Gionatan Danti | 2022/07/29 09:09 AM |
RIP Optane/XPoint | Mark Roulo | 2022/07/29 10:02 AM |
RIP Optane/XPoint | dmcq | 2022/07/30 03:42 AM |
RIP Optane/XPoint | anon3 | 2022/07/31 10:19 PM |
RIP Optane/XPoint | anon2 | 2022/07/31 10:55 PM |
RIP Optane/XPoint | Doug S | 2022/08/01 08:37 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 01:33 PM |
RIP Optane/XPoint | NoSpammer | 2022/08/02 03:50 AM |
RIP Optane/XPoint | Doug S | 2022/08/02 09:24 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/02 10:34 AM |
RIP Optane/XPoint | --- | 2022/08/02 10:39 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 03:48 AM |
RIP Optane/XPoint | Michael S | 2022/08/03 06:04 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 08:56 AM |
RIP Optane/XPoint | Adrian | 2022/08/01 02:15 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 06:07 AM |
Losses vs not profitable enough | Mark Roulo | 2022/08/01 10:15 AM |
Losses vs not profitable enough | dmcq | 2022/08/01 11:50 AM |
Losses vs not profitable enough | Gionatan Danti | 2022/08/01 12:34 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 02:47 PM |
RIP Optane/XPoint | Anon | 2022/08/01 03:09 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 03:32 PM |
RIP Optane/XPoint | Groo | 2022/08/01 12:28 PM |
RIP Optane/XPoint | anon3 | 2022/08/01 10:33 PM |
RIP Optane/XPoint | Groo | 2022/08/03 11:15 AM |
RIP Optane/XPoint | --- | 2022/08/03 03:05 PM |
Latency | David Kanter | 2022/07/29 06:35 PM |
Operating system and driver overhead | Eric L | 2022/07/29 03:44 AM |
Operating system and driver overhead | Linus Torvalds | 2022/07/29 10:45 AM |
altrernatives? | Michael S | 2022/07/29 05:17 AM |
altrernatives? | Rayla | 2022/07/29 06:49 AM |