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.
Bringing SSD Performance to the DIMM form factor
191–200 of 205 posts
Re: Bringing SSD Performance to the DIMM form factor
#192Earlier 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.
Re: Bringing SSD Performance to the DIMM form factor
#193Re: Bringing SSD Performance to the DIMM form factor
#194Earlier 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.
Re: Bringing SSD Performance to the DIMM form factor
#195Re: Bringing SSD Performance to the DIMM form factor
#196Earlier 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.
Re: Bringing SSD Performance to the DIMM form factor
#197I 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?
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
#198Earlier 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…
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
#199Earlier 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.
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
#200Earlier 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?
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".