101–110 of 205 posts
How come read latency is 150 µs, while write latency is 5µs, 30 times shorter? Do they mean the latency to start a write operation? IIRC, flash memory is written block by block, with a pretty significant time to write one block.
Earlier quoted context omitted.
That's a bit pedantic, though. The unavoidable tradeoffs are a pretty small part of the total that we're dealing with now.
L1 Cache is an order of magnitude faster than L2 cache and that's still all on the same chip. That's not "a pretty small part". Energy consumption, heat dissipation, all of this becomes a larger problem for smaller structures. It's just easier and less error prone to build larger structures, yields are higher, so costs are lower for larger structures. I'm certain the tradeoffs will change, but it's all limited by som…
The capacities are very odd - you'd expect something in a DIMM format to have a power-of-2 size. I think the market for this could be much bigger if it behaved like a regular RAM DIMM, only slower and nonvolatile; it somewhat reminds me of old machines that used magnetic core RAM. This could be useful for laptops, like a zero-power suspend-to-(NV)RAM. The only thing that is worrying is the endurance of the flash - es…
For comparison, the stated read performance is 800MB/sec or so. Last time I checked - on ca. 8 year old hardware, we could read files from a RAM disk under Linux at a rate of about 6GB/sec. That's with the added overhead of the benchmark software running and going through a filesystem.
What would be the advantage of this comparing to PCIe/M.2 PCIe SSDs? Is it all about reduced latency, i.e. very small reads/writes would benefit?
Earlier quoted context omitted.
L1 Cache is an order of magnitude faster than L2 cache and that's still all on the same chip. That's not "a pretty small part". Energy consumption, heat dissipation, all of this becomes a larger problem for smaller structures. It's just easier and less error prone to build larger structures, yields are higher, so costs are lower for larger structures. I'm certain the tradeoffs will change, but it's all limited by som…
I don’t disagree with you one bit, but I find it funny that you say: “we can't currently break them, so tradeoffs will always exist.” :) (That “currently” is just a weasel word, but this being the Internet I understand why you put it there)
It is highly improbable that this new technology cannot be optimized in any relevant metric by trading off optimality in a different metric (this is what you are actually claiming).
This is pretty cool, especially since the data is persistent. You could put an entire data warehouse onto one or of a couple of these things, update it once a week and get amazing response time. But I thought the main drawback of SSDs was that eventually the individual memory cells will degrade and lose the ability to write new data. I don't see anything about endurance other than a MTBF of 2.5 million hours and the…
2.5 Mhours MTBF equates to 285 years. That's a long time. On any kind of large-scale installation you need redundancy, but if those numbers pan out then you could expect any single SSD to outlast your organisation. Take backups anyway.
I don't quite understand. Does this act like a stick of memory or an SSD? Is it just using the memory controller as a super fast parallel bus? If it does act like normal memory, what happens at reboot?
It doesn't look exceptionally parallel -- the throughput figures are similar to those in PCIe SSDs. 880 MB/s doesn't come close to saturating even a PCIe bus (4 GB/s, for v2 8x), let alone DDR3 (13 GB/s per channel).
And in most servers these days, drives take up a massive amount of physical space. Being able to drop the drives and RAID controller has the potential of massively simplifying some server hardware.
Earlier quoted context omitted.
Spectators may want to archive this HN thread for posterity, because I suspect nacnud will have the last laugh. (Nacnud's comment is currently sitting at about -3 points.) It's unlikely that future technological advancements will give malware authors more tools to work with? That seems unlikely, if history is any indication. Imagine when you have 1TB of non-volatile storage which operates at speeds close to those we…
Also let's not forget HP said it's possible that memristors will also perform computation, which melds RAM, HDD and CPU into one and makes for a potentially wilder environment for viruses.
True, even under this model, you could probably have a virus running "resident" in a core without the OS even being aware of it. Basically, it's be like the MMU was a hypervisor and the OS was just a domU within it, unaware of viral "domains." But those viruses probably wouldn't be able to do much, except waste electricity, because they'd need to either get the IOMMU to allocate them some hardware to do IO, or get the OS (which has such hardware) to agree to do IO on its behalf. (Though now we can get into things like intermittent side-channel attacks, where you can mine bitcoins on one cell for minutes and then only have to get the OS to leak a single packet when you have a (rare) success, which is much simpler than getting a whole stable TCP channel or something.)
Earlier quoted context omitted.
Just because we've had to make tradeoffs so far does not mean these tradeoffs will always exist. Tradeoffs like these are not a natural law.
Tradeoffs like these are not a natural law They are, they're the laws of physics. According to known theories information cannot travel faster than the speed of light, so unless a very very radical new discovery is made sometime in the future, size and speed will basically be inversely proportional to each other.
Just look back at how things were before the discovery of GMR[0]. We had very different tradeoffs then as compared to now.