5 ms·
>Which is weird.... It isn't weird at all. I would be surprised if it ever succeed in the first place. Cost was way too high. Intel not sharing the tech with
by ksec 8mo ago
>Which is weird....
It isn't weird at all. I would be surprised if it ever succeed in the first place.
Cost was way too high. Intel not sharing the tech with others other than Micron. Micron wasn't committed to it either, and since unused capacity at the Fab was paid by Intel regardless they dont care. No long term solution or strategy to bring cost down. Neither Intel or Micron have a vision on this. No one wanted another Intel only tech lock in. And despite the high price, it barely made any profits per unit compared to NAND and DRAM which was at the time making historic high profits. Once the NAND and DRAM cycle went down again cost / performance on Optane wasn't as attractive. Samsung even made some form of SLC NAND that performs similar to Optane but cheaper, and even they end up stopped developing for it due to lack of interest.
- jauntywundrkind 8mo agoCost was fantastically cheap, if you take into account that Optane is going to live >>10x longer than a SSD. For a lot of bulk storage, yes, you don't have frequently changing data. But for databases or caches, that are under heavy load, optane was not only far faster, but if looking at life-cycle costs, way way less.
- wtallis 8mo agoOptane was in the market during a time when the mainstream trend in the SSD industry was all about sacrificing endurance to get higher capacity. It's been several years, and I'm not seeing a lot of regrets from folks who moved to TLC and QLC NAND, and those products are more popular than ever. The niche that could actually make use of Optane's endurance was small and shrinking, and Intel had no roadmap to significantly improve Optane's $/GB which was unquestionably the technology's biggest weakness.
- raron 8mo ago> I'm not seeing a lot of regrets from folks who moved to TLC and QLC NAND, and those products are more popular than ever. That's interesting. Even TLC has huge limitations, but QLC is basically useless unless you use it as write-once-read-many memory. I wish I have bought a lot of SSDs when you could still buy MLC ones.
- wtallis 8mo ago> QLC is basically useless unless you use it as write-once-read-many memory The market thoroughly disagrees with your stupid exaggeration. QLC is a high-volume mainstream product. It's popular in low-end consumer SSDs, where the main problem is not endurance but sustained performance (especially writing to a mostly-full drive). A Windows PC is hardly a WORM workload.
- fc417fc802 8mo agoSeems like it is though? Most consumer usage does not have much churn. For things like the browser cache that do churn the total volume isn't that high. The comparison here is database and caching workloads in the datacenter that experience high churn at an extremely high sustained volume. Many such workloads exist.
- wtallis 8mo agoThere's a very big difference between a workload where you have to take care to structure your IO to minimize writes so you don't burn out the drive, and a workload that is simply easy enough that you don't have to care about the write endurance because even the crappy drives will last for years.
- fc417fc802 8mo agoOf course. The inferior but cheaper technology is more cost effective in most cases but for certain workloads that won't be the case despite being more affordable per unit upfront. The workloads flash is more cost effective for (ie most of them) either aren't all that write heavy or alternatively leave the drive sitting idle the vast majority of the time. The typical consumer usecase is primarily reads while it mostly sits idle, with the relevant performance metrics largely determined by occasional bursts of activity.
- Dylan16807 8mo agoConsumer usage does not have much churn, but the average desktop is probably doing 5-50 drive writes per year. That's far away from a heavy database load, but it's just as far away from WORM.
- mapt 8mo agoWrite endurance of the drive would be measured in TBW, and TLC flash kept adding enough 3D layers to stay cheap enough, quickly enough, that Optane never really beat their pricing per TBW to make a practical product. I have to wonder if it isn't usable for some kind of specialized AI workflow that would benefit from extremely low latency reads but which is isn't written often, at this point. Perhaps integrated in a GPU board.
- jauntywundrkind 8mo agoThe extra capacity of modern SSD is a good point, especially now that we have 100TB+ SSD. But Optane still offered 100 DWPD (drive writes per day), up to 3.2TB. Thats still just so many more DWPD than flash ssd. A Kioxia CM8V for example will do 12TB at 3 DWPD. The net TBW is still 10x apart. You can get back to high endurance with SLC drives like the Solidigm p7-p5810, but you're back down to 1.6TB and 50 DWPD, so, 1/4 the Intel P5800X endurance, and worse latencies. I highly suspect the drive model here is a homage, and in spite of being much newer and very expensive, the original is still so much better in so many ways. https://www.solidigm.com/content/solidigm/us/en/products/data-center/d7/p5810.html https://www.solidigm.com/content/solidigm/us/en/products/dat... You also end up paying for what I assume is a circa six figure drive, if you are substituting DWPD with more capacity than you need. There's something elegant about being able to keep using your cells, versus overbuying on cells with the intent to be able to rip through them relatively quickly.
- mapt 8mo agoWe don't care about (TBW/TB) at the consumer level, we care about (TBW/$), and 3D TLC was far, far cheaper per TB, so much so that TBW/$ was not a numerical advantage of Optane. That left ONLY the near-RAM-read-latency, which is only highly beneficial on specific workloads. Then they didn't invest in expanding killer app software that could utilize that latency, and didn't drop prices sufficiently to make it highly competitive with big RAMdisks.
- Dylan16807 8mo agoIn 2018, with Optane drives launching around $1.50/GB and TLC flash drives around $0.15/GB, it wasn't that much cheaper. As far as I'm aware Optane had a lot more than 10x the endurance.
- PunchyHamster 8mo agoSo instead of replacing every 5 years you replace every 5 years because if you need that level of performance you're replacing servers every 5 years anyway
- deepsquirrelnet 8mo agoI worked at Micron in the SSD division when Optane (originally called crosspoint “Xpoint”) was being made. In my mind, there was never a real serious push to productize it. But it’s not clear to me whether that was due to unattractive terms of the joint venture or lack of clear product fit. There was certainly a time when it seemed they were shopping for engineers opinions of what to do with it, but I think they quickly determined it would be a much smaller market anyway from ssds and didn’t end up pushing on it too hard. I could be wrong though, it’s a big company and my corner was manufacturing and not product development.
- chrneu 8mo agoI worked at Intel for a while and might be able to explain this. There were/are often projects that come down from management that nobody thinks are worth pursuing. When i say nobody, it might not just be engineers but even say 1 or 2 people in management who just do a shit roll out. There are a lot of layers of Intel and if even one layer in the Intel Sandwich drag their feet it can kill an entire project. I saw it happen a few times in my time there. That one specific node that intel dropped the ball on kind of came back to 2-3 people in one specific department, as an example. Optane was a minute before I got there, but having been excited about it at the time and somewhat following it, that's the vibe I get from Optane. It had a lot of potential but someone screwed it up and it killed the momentum.
- amluto 8mo agoA ways back, I wrote a sort of database that was memory-mapped-file backed (a mistake, but I didn’t know that at the time), and I would have paid top dollar for even a few GB of NVDIMMs that could be put in an ordinary server and could be somewhat straightforwardly mounted as a DAX filesystem. I even tried to do some of the kernel work. But the hardware and firmware was such a mess that it was basically a lost cause. And none of the tech ever seemed to turn into an actual purchasable product. I’m a bit suspicious that Intel never found product-market fit in part because they never had a credible product on the NVDIMM side. Somewhere I still have some actual battery-backed DIMMs (DRAM plus FPGA interposer plus awkward little supercapacitor bundle) in a drawer. They were not made by Intel, but Intel was clearly using them as a stepping stone toward the broader NVDIMM ecosystem. They worked on exactly one SuperMicro board, kind of, and not at all if you booted using UEFI. Rebooting without doing the magic handshake over SMBUS [0] first took something like 15 minutes, which was not good for those nines of availability. [0] You can find my SMBUS host driver for exactly this purpose on the LKML archives. It was never merged, in part, because no one could ever get all the teams involved in the Xeon memory controller to reach any sort of agreement as to who owned the bus or how the OS was supposed to communicate without, say, defeating platform thermal management or causing the refresh interval to get out of sync with the DIMM temperature, thus causing corruption. I’m suspicious that everything involved in Optane development was like this.
- simulator5g 8mo agoIf you're thinking about reliability in terms of 9s you should probably not be depending on a single machine. Reboots could take hours and be fine if your architecture is set up for reliability.
- amluto 8mo agoThings go down and need to come back up. Take a look at almost any major cloud incident in the last 15 years — some combination of goofs results in a bunch of services going down. Then it takes many minutes or hours to come back up. Sure, one can (and should) try to design for fewer failures that result in waiting for things to come up, but one should also design for faster bringup. For the NVDIMM in question, the whole point is for durability after a reboot or power loss. A fifteen minute cycle in which it would write its contents out to nonvolatile storage and then read it back, during which the firmware is too inept to notice that all the data is already loaded is a bug that should have been fixed. (In fairness, this was a pre-production model.) Even ignoring the reboot time, SMBUS was needed to properly identify the device and to access its health-check data. As for my database, it’s not intended for active-active HA setups — it’s intended for use on a small number of high quality machines. It has had zero meaningful data loss incidents in its entire time in production, and it’s extremely fast. But it has some other properties I don’t like and that would cause me to do it differently if I were to start over.