I can't wait to see the programming paradigm of memory vs permanent storage begin to blur in the next 5 or so years. It's going to make some major assumptions about how you program stuff change quite significantly and it's really exciting.
HP is already working on this with what they're calling "The Machine". They're writing a new OS around the new storage technologies with the understanding that it might not make sense to separate RAM from disk pretty soon here. They've also suggested that they'll be porting versions of Linux and Android to this platform.
Of course, all of this is pretty marketing heavy and not a lot of details have been released, so take this with a huge grain of salt. HP's CTO wrote a fluff piece on flattening the storage hierarchy here: http://www8.hp.com/hpnext/posts/end-necessary-evil-collapsin...
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.
I know several researchers there who're working on it. It's for real. It's risky and ambitious, but it's a real, serious project (with tons of sub-research-projects, as you might imagine for something that requires multiple hardware advances and software advances to achieve.)
(source: I'm a cs professor at carnegie mellon, and I was just chatting with some of those researchers at OSDI.)
Cool. I wanted to find someone to talk at https://operatingsystems.io/ about the OS bits (obviously there are lots of bits to it) - its a bit late now for 2 weeks time but if you know anyone appropriate put then in touch for next time... email in profile.
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 going to be a true revolution or just the needle moving a bit further to the right.
Real revolutions in OS tech have for the last decades come from the keyboards of large institutional users and from hordes of smaller ones. Even IBM has pretty much acknowledged that. So we'll see if HP will be able to keep the door locked to someone doing a linux device driver for their new hot hardware or to add a few calls to the kernel that enable an application to use this tech.
The same has happened to infiniband (fast networking for clusters and storage) and tons of other esoteric hardware including shared memory between physically disjoint machines (DSM).
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.
You're right this isn't really a revolution in computing, but a unification. The hardware will be revolutionary, but the changes at the OS level will probably not be.
Still they're merging entire sub-systems that have existed independently for decades and someone has to actually make all the changes to support permanent in-place execution of code and the like that's what I mostly got out of the OS porting news.
Check out stuff from 'Discover 2014'. Discover is HP's tech showcase event. I linked a video below from Day 2 of this years showcase. About halfway through, Martin Fink goes into a bit on how it's supposed to work.
>I tried to find anyone working on it and failed. //
Inventors of anything submitted in patent applications should be named on the application. That is a potential route to finding who in a corp actually invented stuff.
Memristors (long promised and still not quite here) also bring together the ideas of long-term and short-term memory into one and, in future incarnations, even promise to bring computation and storage together.
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.
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".
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 currently enjoy for DDR3 memory. Most average consumers won't use all of that space. It seems entirely plausible that a virus will write itself to some area that is never overwritten. It becomes a latent piece of malware, invisible to any filesystem, but activatable on demand by some other hard-to-detect malware. This two-step scheme would be difficult to detect since the second component does nothing except activate the first component (stored in nonvolatile storage) under some specified criteria.
Or, how about key generation or password input? Remember cperciva's post about how it was extremely difficult or even impossible to zero a memory buffer correctly? Now add in the idea that suddenly "everything is nonvolatile" and you get a perfect storm for security concerns: if a program segfaults or is terminated mid-operation, then suddenly any sensitive data it had spit out into memory might be capturable by other programs. Or, since it's nonvolatile, those secrets will persist "forever" (until they're overwritten, which may be a long, long time if storage is plentiful) and you may inadvertently leak secrets when you sell your memristor-backed storage. Whoever buys it can do some digging and uncover whatever was written into that buffer, if it's truly non-volatile storage.
So, while the future is exciting, underestimating the security implications probably isn't a good idea. We can develop new methodologies to combat the new security concerns, but new security concerns will almost certainly come to fruition. Of course, calling the concerns "new" is somewhat unfair, since new concerns are almost always very old concerns manifesting themselves in new domains, but new domains usually enable malware writers with new toolsets to exploit.
I downvoted nacnud because it's such a generic statement, you could post it to almost any thread. Net neutrality? "Think of the potential for viruses to spread!" iWatch? "Think of the viruses you could have on your watch!" New JS framework? "Think of the attacks it could enable!"
Yeah, of course, everything has security implications and some technologies even more so, but unless one explains them and states how they are specific to the technology being discussed (like you did, for example) then the comment doesn't really add any value.
A new form of persistent storage is an enabler, it may create entirely new forms of attack. Whatever you cook up using Javascript, your watch or (that one is really reaching) Net Neutrality is not of the same degree at all, those are just (very slight) variations on existing themes.
Writable storage using a centralized access method (file system) is hard enough to purge and keep clean, having a memory mapped persistent chunk of storage that is user process level writable creates an entirely new class of problems.
Getting rid of viruses from BIOS flash is hard enough, this expands that concept to all of userspace.
I sincerely hope the 'x' bit will be off for such memory.
I'm with you I got my first 1TB HDD last year thinking it would last a few years. Nearly full now. Why? Because with all that space available I've changed how I use disk space - why throw stuff away. Also that I've moved to a higher grade camera and moved to consuming video stored on HDD rather than from discs.
When we're creating fully immersive 4D environments in place of holiday snaps then I imagine we're going to be using quite a lot of memory waving through our holiday review with friends.
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 /.
The 'enables new opportunities that were previous infeasible' component is more exciting. But generally, I think most of it gets swallowed up in more of the old.
By cutting out the part about speed you've grossly distorted the quote. Yes, people will hang on to lots of data. But for the vast majority of files there is absolutely no need to access them faster then, oh let's say 1gbps with 1ms latency.
I'm sure people will find something to do with it but I'm having a very hard time thinking of situations where you want massive amounts of RAM and also need to be very power conscious or wary of power loss. Certain types of database, perhaps? I wouldn't imagine HPC worries much about power loss. Video game textures don't need to be nonvolatile.
For most purposes you can keep shoving in DRAM and SSDs until you have enough space.
> a virus will write itself to some area that is never overwritten
A simple way to counter this is to tag the memory pages as free/used. If the memory controller reads a page as free, any reads from it can return zeroes without hitting the actual memory bus. Any piece of code that wants to hide will not be part of any active object and its page being marked as used should be considered an allocation error and be easily detectable.
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.
If we keep to the implicitly-shared-by-default UMA/NUMA architecture we've been working with so far. I'd imagine a combined compute-memory-storage unit would be mostly hardware-isolated, with something resembling message-passing semantics for cross-core communication. Something more like FPGA cells, or Erlang processes. (With the likely property that you could have pools of these cells that act like plain memory, for other cells to share and manipulate using handles/segment descriptors/whatever.)
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.)
You can get that today with FRAM, although not at high density. TI do microcontroller eval boards with built in FRAM; you can have your device resume automatically from power loss with all its memory still there.
Traditional memory continues to become cheaper too. Flash is dimes a gigabyte, disk is cents a gig and videotape tenths of a cent per gigabyte. So supercomputers will always be maxing out each level of memory. And you will still need worry about memory hierarchies.
For ordinary computing, maybe a terabyte of flash will finally be enough.
Flash is really closing in on disk, though. If costs continue to halve biannually, and capacities keep rising like they do, they might intersect around 12 - 16TB in five to ten years.
Not really, Flash hit a wall recently and price stopped falling rapidly. Only Samsungs V-NAND has a chance of competing with HDDs on capacity, and its still very costly.
Problem with Flash is the more you pack in same volume the more of it comes out bad, while the rest is fragile ticking bomb.
Replacing slow, but reliable HDD with 100 writes limited flash is not the answer.
Sometime before that, I'm guessing in about 3 years +/- 6 months, the capacity+performance advantages of flash will reach a point where spinning disk doesn't make sense, volumes of flash being ordered start to accelerate, spinning disk volumes plateau, and investments in developing the technology adjust accordingly (more investment in improving flash, less in spinning disk)
I would be willing to wager that new models of laptops in 2020 with spinning disk will be uncommon, and, by 2023, except for niche verticals. basically non-existent. Same for Desktop 2 years later in each category.
2025 will mark the end of consumers buying spinning disk.
I think it will happen much sooner than that. Flash doesn't have to match the price/GB of hard drives, it just has to match at the minimum viable system level. A lot of people could survive with 120GB, and that number goes up drastically when you hit 240GB. When the price of those SSDs reaches the hard drive floor of about $50, hard drives will become a niche product appealing only to those who actually need multiple terabytes.
How is this different than IBM's single store model? Memory and disk are addressed as one with hardware providing the protection needed in case of component or system failure.
Unless your writing at the machine level I really do not see the need for most programmers to ever concern themselves with storage, that should be the work of the underlying machine code and/or OS.
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.
IBM went all the way with this in the AS/400 back in the 80's. Single level store - RAM and disk were unified storage. with no ability for a programmer to tell the difference (RAM was purely and operations problem).
I'm really excited for shared RAM between GPU and CPU. At the moment GPU acceleration is limited by the meagre amount of VRAM on most desktop cards. I would love to be able to do GPU programming with a 32+GB RAM pool.
I doubt that will happen ever, there's always a tradeoff between cost, speed and space (on the die, ...), otherwise we'd all be running machines with 1TB L1 Cache.
Yes they are, because the storage isn't arbitrarily small. There is always the latency of distance to overcome. That includes the centimeters to your main memory. There's always going to be a capacity-latency tradeoff.
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 some physical law and while we can sometimes trade one law against the other, we can't currently break them, so tradeoffs will always exist.
Yeah, but I thought we were talking about RAM vs SSDs. The problem there is not that SSDs are too big physically or that the cable is not short enough.
These caches are currently implemented with SRAM, a technology which uses 6 transistors per bit. Find a different technology (such as memristors) and our entire set of tradeoffs are likely to change.
The laws of physics dictate what the ultimate limits of a techology are; they do not dictate which technologies you actually choose to use.
> The laws of physics dictate what the ultimate limits of a techology are; they do not dictate which technologies you actually choose to use.
I never said so, I agree. I'm just stating that I'm confident that in the future, we'll still have tradeoffs. And I'm certain those will include "fast and small, but expensive" vs. "slow and cumbersome, but cheap".
We already reached the point where it's a problem that the clock signal on a die spreads so slow that it's a significant problem to increase the clock rate. So we're pushing parallel computing and other solutions, but those come with their own set of trades to make.
Well, I can rephrase that "I don't expect fundamental laws of nature to change any time soon." But laws that were assumed to be fundamental have been found to be false in the past, so I don't want to rule that out for the future either.
It is highly probable that we will discover memory that is better than current memory in every relevant metric (I suspect this is what you think you are claiming).
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).
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.
The laws of physics don't dictate what technologies we know, only what their ultimate limits are. Just because our current memory technologies have some limitations that force us to make a tradeoff does not mean this will always be the case.
Just look back at how things were before the discovery of GMR[0]. We had very different tradeoffs then as compared to now.
As long as we care about computational latency, the forces that give rise to caching will continue to hold force. The speed of light places a fundamental limit on the response time from a storage system of a given physical volume, and there are equivalent physical laws on the maximum amount of information that can be stored in that volume.
Which technologies we use for our caches and main storages will change, but we're never going to get around the need for caching.
This is sort of the opposite of the RAM-based battery backed drives [1]. I can see this being immediately useful for things like large database servers: instead of re-priming caches on reboots you just have them already warmed up. You can also suddenly have a whole lot more "RAM" at the cost of its speed.
I do have a hard time picturing what this will look like if it was as fast as traditional RAM. If I can store everything in RAM, from the OS binaries, to the running processes, it certainly has a kind of elegance to it. Lots of microcontrollers already act this way: all your hardware has an address in a single address space, be at a hardware port, ROM, RAM, NVRAM, etc. However, I wonder how the modern UNIX OS will work with a system like this without block devices at all. I wonder if what it'd do is actually just use RAM disks, and years from now we'll still be doing this the way we do double emulation of the TTY. That'd be kind of sad since it means we can never get away from the concept of old block devices.
On the other hand it's damn convenient to be able to just append to a file and not have to worry about reallocating it. This means that perhaps all we'd need is a filesystem that's designed to work over RAM rather than over block devices.
The file system (and associated baggage) exist because of a fundamental disparity between the speed (and nearness to compute) of smaller memories and the convenience (but relative slowness) of larger ones. While SSDs do certainly close this gap, I find it difficult to imagine that this gap will ever entirely close; if anything, physics guarantees that compute units with small, nearby memories will always be far, far faster than more distant memories. You might argue that SSDs are "fast enough" to dispense with the inconvenience that imposes, but I can certainly find things I'd rather do with the performance.
While block devices can go away, the notion of a file will probably continue to remain.
We run clusters of ephemeral linux hosts, and while we use disk, we also have plenty of hosts that run diskless. The disk mount point just becomes a tmpfs mount and the required minimal installation is made on a tmpfs partition which amounts to a trivial amount for hosting busybox and some conf files in /etc. Linux does appear to understand that tmpfs backed filestores are already in memory and do not need to synchronize pages and flush out dirty pages. That whole caching/memory layer for this fake block device is just not used at all.
That's right, we already have a filesystem backed by RAM: tmpfs. Except now it's no longer so tmp. I suppose then yes we don't have to do much in the way of emulating block devices: just run tmpfs or it's later revisions and know that everything is permanent. In that case, this is not much of a leap for the current OS's to support it, which is great. I wonder if this means that theoretically mmap() can become a one liner now.
- Two separate address spaces, one volatile (RAM) and one persistent (SSD). "Writing" to persistent storage is as simple as "mov [src],[dst]".
- One global address space, with a page attribute of "volatile" (true/false). Writing is just as simple as above.
At that point the OS and userspace are free to create whatever abstractions are necessary on top. They don't necessarily need to be filesystems or files per se.
I do wish the iRam had stuck around longer. The 4GB limit makes it practically useless today, but a modern version of the same would be incredibly useful for some workloads.
I couldn't find any when I looked recently, even the one you've linked to is quite old (2009) and has the same 4GB (presumably 32bit) limit. If they were more common and in more realistic sizes I'd love to get my hands on one.
Not that interested, I'm an individual not a company! I meant if they were a product you could get off the shelf I'd be buying one, but I'm not that rich.
"However, I wonder how the modern UNIX OS will work with a system like this without block devices at all."
I don't think that's how it works - I think you get a special driver that presents the fast-storage-in-dimm-slot as a block device. So you still have a block device, it's just faster.
> If I can store everything in RAM, from the OS binaries, to the running processes, it certainly has a kind of elegance to it.
Didn't Palm OS originally work this way? The early devices were too cheap for flash memory for anything more than the base OS, so they just stored everything in battery-backed RAM. If your batteries ran out, your device was wiped and had to be re-synced. Apps were run in-place in RAM. Then they had to hack in a bunch of workarounds when they added flash memory storage.
You can tell SanDisk's performance numbers do not add up and that they are likely misrepresenting the true performance of their device. (Those red asterisks next to the numbers correspond to a footnote that is conveniently missing from the page...) A "read latency of 150usec" translates to maximum possible read IOPS rate of 1/150e-6 = 6.67K (with one outstanding I/O). But they quote a "random read IOPS of 140K". That would only be possible if their DDR3-based DIMM could process 21 concurrent read I/O operations. But to the best of my knowledge, DDR3 is limited to 8 banks/DIMM, so there could not possibly be more than 8 concurrent read I/O at any one time. Far from 21.
So SanDisk is likely quoting a worst case read latency and/or a best case read IOPS. Customers are left to themselves to figure out which of these numbers is most likely to represent the average performance...
But to the best of my knowledge, DDR3 is limited to 8 banks/DIMM, so there could not possibly be more than 8 concurrent read I/O at any one time.
Maybe you can submit more than 8 queued requests to the controller and have them stream back at the full DDR3 data rate. Maybe it's not actually addressable as RAM, it just uses the DDR3 interface as a communication bus.
I appreciate this might not be the right way to look at it, but from a trivia POV, in terms of raw performance, what era of regular memory would be comparable with it? (i.e. "typical desktop memory in 2004", say.)
The read latency is about as slow as the earliest RAM ever used -- tubes of liquid mercury used as acoustic delay lines. (150 us vs. 222 us (microseconds))
According to this table: http://en.wikipedia.org/wiki/CAS_latency its read latency of 150 µs is at least 15,000 times worse than 100 MHz "PC100" SDRAM, which is early 2000s-era.
and a video interview and demo with a SanDisk manager at a computer fair - http://www.youtube.com/watch?v=jarsTLGXx9c
(currently only available for OEM, requires special bios setup)
>The benefit of using a DDR3 interface instead of SATA/SAS or PCIe is lower latency because the SSDs sit closer to the CPU. The memory interface has also been designed with parallelism in mind and can thus take greater advantage of multiple drives without sacrificing performance or latency. SanDisk claims write latency of less then five microseconds, which is lower than what even PCIe SSDs offer (e.g. Intel SSD DC P3700 is rated at 20µs).
But raw flash writes on the order of 1-2 milliseconds, so the 5 microseconds must be the latency to write to a ram cache inside the stick. I wonder what the latency would be for a write larger than the buffer. For that matter, how large is the buffer?
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?
Answer is there in FAQ. Written data is not lost on reboot, so basically you can mount it as a `ramdisk` partition and use that as data directory for your database. I have used this approach in past to speed up large test suite of a web application, except it required restoring from some sort of backup on reboot. Which won't be necessary in this case.
Does this mean you won't have traditional memory available at all (outside of L1-3 cache)?
Or is it able to mix and match between real DDR3 memory and SSD?
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).
I agree, it's not that fast I have 1U servers with lots of RAM slots. Fitting in a RAID 10 is easy enough even in a "modest" 1U server with space for 8 DDR3 slots. We have servers with up to at least 16 DDR3 slots.
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.
Technically it acts like memory. The dev kit comes with a device driver that makes it look like a block device though, which would be analogous to something like NVMe.
Well at the interface level it has to look like memory since it's attached to a memory bus. But that does not mean it looks like a single large DIMM. There is no way in the DRAM protocol to delay a transaction while data is read from the flash chips into the buffer, so you need a protocol on top of the simple memory model.
"nvDIMMs" on the other hand do look like and are as fast as plain memory. Disadvantage is that they are not big.
DDR3 supports 8gbit chips and you can shove 16 onto one DIMM, so 16GB. But that leaves 3 address lines unused for column select. Theoretically they could make a 64GB or 128GB board. Also LRDIMMs can go up to at least 64GB.
DDR4 directly supports 512GB, and also throws away three potential column address bits.
For all of us who are thinking "it's just like RAM, just persistent!", here's some perspectives about what persistent RAM means for OSes and applications: http://lwn.net/Articles/610174/
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 disk-writes-per-day (DWPD), which I had to look up. I have no idea if these are good or bad. I feel like these things will be great if you didn't write new data a lot, or you have deep pockets to replace them when you need to.
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.
I just want to point out that is not how MTBF works. MTBF (and MTTF) are used in a group of components, and cannot be used to estimate lifetime of a single component. This does not say that, on average, each component will last 285 years. This says that, given a group of components (if you bought 2.5M of them, for example) there will be a failure every 2.5 Mhours of operating time (so for 2.5M components, every hour one will fail).
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.
At a guess, they are using MLC (or even TLC) transistor configurations, which effectively packs more bits into on transistor, but is slower to read. Good SLC has read cycles of 20-25 usec.
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 - especially if it's being treated almost like RAM in this application.
Over-provisioning is normal in enterprise SSD. They use extra capacity for re-packing blocks (i.e. garbage-collecting partially erased blocks) and to account for blocks wearing out from use.
It's still way too slow to be treated as RAM. The performance they quote is equivalent to a mid to lower range PCIe SSD.
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.
I also wonder if that 880 is for just one slot filled up. If it is, then I wonder if you can parallelize to 4 slots for ~3.4GB/s.
At that point, I imagine many types of data sets would work A-OK.
Though I wonder how that's scaled for cores, given that in the situation I imagined above, you'd be streaming all that data to just one CPU to get that aggregate bandwidth.
Hmm.
OK what about some other scenarios? Being able to have RAM and Storage on a sliding partition is sort of cool. I wonder if it'd make provisioning VMs any easier. "How much RAM do you want? Set the slider!"
Yes, it is slow. PC133 is "ancient". As I pointed out, even in 8 year old hardware it was trivial to get more than 6 times that performance out of a RAM disk device using filesystem benchmarking tools.
> If it is, then I wonder if you can parallelize to 4 slots for ~3.4GB/s
You probably can, but then you can't run code straight out of it, or read/write data directly as if it is normal RAM. Putting a filesystem on it, RAID'ed over multiple slots will likely work great (especially so since it's easy to get servers with a ton of DIMM slots, and it'll allow much better server density than trying to fit in more drive slots). But treating it as RAM will be slow.
I look forward to the point where 3/4 of business application code will go the trash when we'll have a persistant memory with the latency of actual RAM disk (Memristor !!). Exit all that "copy from RAM to Disk/Network" code.
It will definitely change the way we code and look at code. That's why nowadays I think a good interface to your entities, like the Repository pattern, is a must have.
Only on a low level, right? I have not been thinking about ram and disk in ages. I calculate with variables, I store stuff in a DB or in a file, I access the net via http. Nothing would change if ram increases I think.
Well, if you have plentiful persistent RAM an application could easily "suspend" itself (on shutdown for example), and then resume running at a later point in time. The code would not have to think about this, since the entire state is just snapshotted. It's basically what machines do now when they "hibernate", except more effecient and could even happen if the power got cut.
Additionally I suppose your variables could also be persistent automatically. Though the biggest change I see is that software would never really need to completely close anymore when RAM == Disk. For RAM usage it wouldn't really matter if they were running or not, unless they delete data upon shutdown. To save CPU or other IO usage the application could simply be suspended.
I work on an application that was originally designed to persist transactions to battery backed SRAM. It's still full of "business logic", because that's where all the value is. Copying data around really doesn't consume that much time and effort; performing logical, semantic or administrative transformation on it does.
Is the advantage the low latency because the rest of the specifications seem to be pretty standard for an SSD. Does this require a BIOS patch of some sort?
The RAM slot helps for latency and throughput. SATA 3.0 would restricts this drive's read throughout from 880MB/s to less than 600MB/s, and would increase the write latency (5usec) by at least 1 or 2usec because of the typical CPU->southbridge->PCI express->SATA link it would go through, but here it is CPU->RAM slot. 1-2usec might sound negligible but it's not: it's 20-40% worse latency, so 20-40% fewer write IOPS.
SATA 3.2 (2000MB/s) would help for throughput but not for latency. It is also still quite uncommon even amongst latest generation servers, whereas this SSD is compatible with many current and older generation servers.
Yes it would be very cool to have the entire operating system in SSD. Literally flick the computer on and it's running ;)
Or flick rapidly between Linux and Windows. That makes me think it might be wise to have a manager to do this. E.g. leave the disks accessible between three+ operating systems.
If it behaves like RAM, from the POV of the OS, I'd imagine the advantage to be the large size. There's also the fact that it won't lose its data on power loss.
Of course, if it behaves like a regular SSD, the read speeds still exceed SATA3.0 speed.
> There's also the fact that it won't lose its data on power loss.
Does this mean that for software to take full advantage of this, the software will need to be updated to account for it? For instance, Redis loads data into memory from disk upon starting, but if something like this 400GB SSD is available as memory (and say for instance, 300GB is in use by Redis), wouldn't it make sense for Redis, upon starting, to just "remember" the state of the memory rather than reloading it from disk?
Not really; we already have suspension (to RAM and to disk), this can work just like it. For the userspace software, it'll be like it never stopped running.
In the hypothetical world where this was as fast as real RAM, it would be cool if the OS was smart enough to read mmap'd data onto it and deal with remembering "this file was mmap'd here and hasn't changed since, next time it's mmap'd again we can just reuse it", and instantly you have support for all the software that just uses mmap (comedy MongoDB option?)
That doesn't make any sense. If it just showed up as RAM your system would be so slow it would be unusable. There is no benefit to that. Using this requires a supported motherboard specifically because you do not want it to be used as RAM.
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).
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.
SSDs as RAM + projects like Tachyon are the future of big data processing -- current workflows are still way too slow. I wonder how this will affect Spark.
I am not a silver bullet kind of person, but I think this kind of technology plus things like Spark are potentially the holy grail. Ok, let me rephrase - I've often believed that there was a sort of "ultimate architecture" with distributed cluster computing, distributed programming frameworks, high-speed interconnect, and flash based storage. I think we are getting closer and closer each day. I wish I worked in R&D at any of the companies doing this fundamental research now - I have a feeling they have some amazing things cooked up behind closed doors.
Not yet. I think first we will have SSD as static RAM plus dynamic DIMM RAM as Cache. I wonder when SSD will compete with DIMM regarding maximum number of write operations.
The hope is that a standard will be created soon to support this behaviour. These sorts of things are complicated because it requires support of the chipset vendors. i.e Intel and AMD.
You can't address a specific RAM stick, typically.
Try and boot an OS without knowledge of this, and it'll start using the stick like it uses RAM. It'll take orders of magnitude longer to boot, to the point of impracticality, probably (I haven't calculated).
The OS needs to understand the memory map, and at the minimum exclude use of the stick for "normal" operations.
Then, it needs to expose the stick for access - preferably in a way that is more usable than /proc/mem.
I don't think any current consumer (or enterprise for that matter) conventional motherboard has support for such a large stick. Plus I imagine that this stick will implement some different protocols/whatever to be able to be used directly as a drive
> Flash still has limited write cycles. Its for data you probably wont write more than once an hour, but not virtual memory.
You can write data to SSDs a lot more than once an hour, even virtual memory. The drive's firmware (assuming it does its job) will do wear-leveling and spread the logical writes across different physical locations on the drive.
If you write 20GB of data per day to a modern 480GB SSD you can expect 25 years of service. (Realistically, something else will probably fail before then)
