Live data from Hacker News

Bringing SSD Performance to the DIMM form factor

sandisk.com.br

191–200 of 205 posts

Re: Bringing SSD Performance to the DIMM form factor

#191
post #166

Earlier quoted context omitted.

I seem to recall that early Palm devices used run-in-place, but i don't recall if they were able to maintain state if there was a power loss.

The early ones had a capacitor that held enough charge to allow you to change the batteries without losing state.

The Psion hand-helds (at least the 3 and 5 eries) did this too. They were powered from a pair of AA batteries and no state was lost while changing them, though IIRC it was a small button cell that gave power to keep the memory refresh going while there was no power from the AAs or the external power adaptor, not a capacitor.

Re: Bringing SSD Performance to the DIMM form factor

#192

Earlier quoted context omitted.

> Because with all that space available I've changed how I use disk space - why throw stuff away. Funny, I'm the opposite. With all this bandwidth available, why keep stuff?

Because storage availability is under your control but bandwidth+remote storage availability is not. In other words, you could lose your remote stuff + access to it.

I could lose my local stuff too, by having a disk fail. I trust S3's reliability more than my local disk, so it doesn't make sense to keep things locally.

Re: Bringing SSD Performance to the DIMM form factor

#193
I would still say that the real performance bottleneck is ultimately the bandwidth between the CPU and this memory. This suggests that the next stage will be to incorporate heterogenous processors alongside that memory - thus upgrading your computer could then be as simple as plugging in an another combined non-volatile memory/CPU block into a fast inter-connector. Rather reminds me of the the old S100 bus where everything just plugged into the same channel, (which probably dates me quite well).

Re: Bringing SSD Performance to the DIMM form factor

#194
post #166

Earlier quoted context omitted.

The early ones had a capacitor that held enough charge to allow you to change the batteries without losing state.

The Psion hand-helds (at least the 3 and 5 eries) did this too. They were powered from a pair of AA batteries and no state was lost while changing them, though IIRC it was a small button cell that gave power to keep the memory refresh going while there was no power from the AAs or the external power adaptor, not a capacitor.

Yeah, and that button cell didn't last as long as you might think - I remember many an occasion when I'd let mine run flat, and then leave it just a little bit too long before charging it back up again.

Re: Bringing SSD Performance to the DIMM form factor

#196
post #132

Earlier quoted context omitted.

I was just thinking about this the other day. Yes, a memory-mapped-file is different, because the API is still that of a file. The memory mapping is just a behind-the-scenes optimisation.

Only if you want posix compliance across threads and such. If you just want the contents of the file memory mapped nothing stops you from setting up a shared memory segment and mapping it without that filesystem overhead.

Does that work for writes as well? I am not sure if it would work without the OS setting up traps for writes to the pages or explicit flush calls from the app. In the former case, it would be very inefficient, and in the latter, it wouldn't be a clean write-and-forget system.

Re: Bringing SSD Performance to the DIMM form factor

#197

I honestly can't imagine having something in my DIMM slots with this bad of latency and throughput. 150 microsecond reads? Doing a full POST would take forever. What OS and software use - case does this serve?

You'd put a filesystem on it and mount it as a "ramdisk", with the result that you can cut out expensive RAID controllers and/or PCIe SSDs, and can potentially reduce form factor.

E.g. I can get 1U servers with 32 DDR3 slots and 64 cores, but only space for 3x 3.5" drives, or if you double up (but few chassis will then let you use hot swap caddies), 6x 2.5" drives.

You could easily fit 256GB RAM and still have 16 slots free for RAID arrays over those DIMMs.

Re: Bringing SSD Performance to the DIMM form factor

#198

Earlier quoted context omitted.

I am not sure it is even a real project. I tried to find anyone working on it and failed. Nice story though.

It's very much real but I'm not sure if I agree with the basic premise. 'Regular' operating systems have gone through a whole slew of storage changes relatively unscathed, what it is about faster persistent storage that you could not encapsulate the same way we did with memory mapped files I do not understand. Obviously HP is far from stupid (or at least, its scientists are) but for now I'm on the fence if this is go…

There are certainly areas that might change. E.g. if HP's memristor research pays off, with true random access, consider that solutions like Redis suddenly can be written to provide persistence without having to write a log to disk or write dump the data.

And e.g. consider the changes to RDBMS's if you can do guaranteed committed writes of individual bytes. A huge amount of the work on RDBMS's have been around table types that are optimised for per-block read/writes, where the design tradeoffs might be very different if you can do "cheap" random access (though caches will probably still justify some degree of block-wise access).

But with respect to operating systems, I agree that it will take a long time to see any dramatic changes. The current mechanisms would still work: Open a file that maps to a memory region instead of a drive; mmap() it. Your app would just want to know whether or not the file content is instantly persistent on write or not.

I think HP's starting point, though, is that we don't really know. Both in terms of hardware and software. Take this DIMM drive, for example. If you look at current server motherboards, a lot of servers has no need for PCIe slots other than for SSDs. A lot of them will not need drive slots at all if you can stuff that much storage on DIMM slots. Suddenly it becomes viable to put really high performance systems in half depth 1U form factors. For a lot of our larger servers, 50% or more of the server volume is air because current designs are so geared towards front loaded hot-swappable drives. Maybe 75% of the weight of the servers are due to drive bays and larger boxes to accommodate that front-loading. That's a lot of wasted metal, and a lot of wasted rack space. And a lot of wasted electronics for SATA interfaces that could sometime become obsolete.

Re: Bringing SSD Performance to the DIMM form factor

#199

Earlier quoted context omitted.

Because storage availability is under your control but bandwidth+remote storage availability is not. In other words, you could lose your remote stuff + access to it.

I could lose my local stuff too, by having a disk fail. I trust S3's reliability more than my local disk, so it doesn't make sense to keep things locally.

It's not just S3, it's that and your local ISP and the backbone it connects to. All the planets have to be aligned for your remote storage to be available.

Locally, if you're using RAID like everyone else, you just have to trust your local electricity supply and your ability not to rm -rf /.

Remote is fine for backups, though.

Re: Bringing SSD Performance to the DIMM form factor

#200
post #60

Earlier quoted context omitted.

When they work (there is to much cash on the table for them not too), they'll completely change the way we think of volatile and non-volatile memory. Since all memory will be non-volatile. It'll be a huge paradigm shift in storage and IO speed.

.. and possibly give viruses more places to hide?

Viruses are still a thing?

Used to get them regularly on my Windows 3 -> Windows XP/2000 days.

Haven't seen them much in Linux or OS X in the last 15 years.

There might have been one or two. But I doubt you can find 10. And the number of users I've seen reported as affected by one was also laughable, something like 1% of all users of less (half to around 1 million).

The non-hacker media of course always touts this or that trojan that actually needs user intervention to be installed as a "virus".

Post reply on HN