Seems more like a PoC than a product. The real MRAM benefit as I understand it is that you can mix logic IP blocks and NV-RAM into a single SoC, which is very low power, very quick to recover its full logic state from MRAM, so it wakes up and resumes in a few dozen cycles: Energy benfits, not space benefits.
Here an FPGA with a pure MRAM memory chip will save space where U.2 obviously carries over a spinning rust form factor not ideal for solid state storage.
At current premiums I'm not convinced U.2 will ever flourish and the Open Compute guys will probably cook up something more sensible, quite possibly MRAM based, but not U.2 with FPGA, but a proper ASIC or a set of them for aggregation.
You're right, it's an IBM product. I guess what I was trying to express is that I don't see this as a template for widespread adoption, not this controller and not U.2. It is bleeding edge (as is 19TB in a single SSD), but very niche.
Widespread for me means large volume, which is cloud and consumer, not enterprise. We still have a mainframe, we still have p-Series and we have U.2 disks and SSDs where I work.
But we don't have that many.
When I want through the presentation I felt that those hybrid HDDs could now get the cache thay would have requried to make sense (instead of 8GB of SLC being sold at outrageous prices and little value) as part of the normal controller they already need, but those are gone from notebooks and not coming back. 'normal' SSDs could also profit, but SLC chaches seem to work well enough for most cases, so that it would be difficult to compete. And those notebooks typically have a UPS built-in ;-)
Don't get me wrong, I love the technology, but I'm not sure this is the greatest showcase towards mass adoption.
How much MRAM does this use, 1 Gb (128 MB) or more? Or is it even less, since apparently 1 Gb MRAM hasn't even started sampling yet? What is the real benefit of replacing DRAM cache with a very small MRAM cache apart from saving on supercapacitors, but at the very large trade-off of the cache filling much more quickly?
But would you store a map table in MRAM? AFAIK you can reconstruct the map table from the on flash structures: Yes it would take time, but enterprise hardware typically doesn't get powered off until its going to the knackers and for the rare powerfail event the reconstruction time may not be crucial enough to keep it there. I would have thought that MRAM here is used for crucial in-transit data and base data structures required to reconstruct any map.
That's one reason more I don't think this use case is an ideal demonstrator for MRAM, which to my knowledge tried to focus more on really logic embedded SRAM replacement, where complex logic state say in massive DSP or SoC could be persisted very quickly, so sleep/wakeup times could be minimized and the energy expense for the transition reduced to reduce the cost of sleeping. That's IoT, ultra embedded etc. but not high-end ent
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
14 Comments
Back to Article
abufrejoval - Monday, August 6, 2018 - link
Seems more like a PoC than a product. The real MRAM benefit as I understand it is that you can mix logic IP blocks and NV-RAM into a single SoC, which is very low power, very quick to recover its full logic state from MRAM, so it wakes up and resumes in a few dozen cycles: Energy benfits, not space benefits.Here an FPGA with a pure MRAM memory chip will save space where U.2 obviously carries over a spinning rust form factor not ideal for solid state storage.
At current premiums I'm not convinced U.2 will ever flourish and the Open Compute guys will probably cook up something more sensible, quite possibly MRAM based, but not U.2 with FPGA, but a proper ASIC or a set of them for aggregation.
The Hardcard - Monday, August 6, 2018 - link
Not even the “shipping to customers this month” makes it seem like a product?abufrejoval - Tuesday, August 7, 2018 - link
You're right, it's an IBM product. I guess what I was trying to express is that I don't see this as a template for widespread adoption, not this controller and not U.2. It is bleeding edge (as is 19TB in a single SSD), but very niche.Widespread for me means large volume, which is cloud and consumer, not enterprise. We still have a mainframe, we still have p-Series and we have U.2 disks and SSDs where I work.
But we don't have that many.
When I want through the presentation I felt that those hybrid HDDs could now get the cache thay would have requried to make sense (instead of 8GB of SLC being sold at outrageous prices and little value) as part of the normal controller they already need, but those are gone from notebooks and not coming back. 'normal' SSDs could also profit, but SLC chaches seem to work well enough for most cases, so that it would be difficult to compete. And those notebooks typically have a UPS built-in ;-)
Don't get me wrong, I love the technology, but I'm not sure this is the greatest showcase towards mass adoption.
Manch - Tuesday, August 7, 2018 - link
Is it too hard to just type "HDD"?abufrejoval - Tuesday, August 7, 2018 - link
sorry, I read theRegister.co.uk before I look at Anandtech for time zone reasons: It colours off...Ammaross - Tuesday, August 7, 2018 - link
+1 for El Reg. Spinning Rust is the only way to talk about an HDD. :)fteoath64 - Tuesday, August 7, 2018 - link
Noting said about read and write speeds ?. Event preliminary numbers will provide indicative performance compared to normal SSDs.Santoval - Wednesday, August 8, 2018 - link
How much MRAM does this use, 1 Gb (128 MB) or more? Or is it even less, since apparently 1 Gb MRAM hasn't even started sampling yet? What is the real benefit of replacing DRAM cache with a very small MRAM cache apart from saving on supercapacitors, but at the very large trade-off of the cache filling much more quickly?a1exh - Wednesday, August 8, 2018 - link
That was exactly what I was thinking. A traditional map table for a 20TB drive would take approx 32GB of DRAMabufrejoval - Wednesday, August 8, 2018 - link
But would you store a map table in MRAM? AFAIK you can reconstruct the map table from the on flash structures: Yes it would take time, but enterprise hardware typically doesn't get powered off until its going to the knackers and for the rare powerfail event the reconstruction time may not be crucial enough to keep it there. I would have thought that MRAM here is used for crucial in-transit data and base data structures required to reconstruct any map.That's one reason more I don't think this use case is an ideal demonstrator for MRAM, which to my knowledge tried to focus more on really logic embedded SRAM replacement, where complex logic state say in massive DSP or SoC could be persisted very quickly, so sleep/wakeup times could be minimized and the energy expense for the transition reduced to reduce the cost of sleeping. That's IoT, ultra embedded etc. but not high-end ent
abufrejoval - Wednesday, August 8, 2018 - link
erprise where juice rarely it such a determining factor (hit the wrong key, want edit!)phoenix_rizzen - Wednesday, August 8, 2018 - link
Is that 19 TB of physical storage space, with 3x compression on top, for a theoretical storage capability of 57 TB?Or is that 19 TB after 3x compression, meaning there's a little less than 7 TB of physical storage onboard?
The text is a little confusing.
apriest - Wednesday, August 8, 2018 - link
I was wondering the same! It reads more like a tape drive label. :-P