Samsung Unveils First PCIe 3.0 x4-Based M.2 SSD, Delivering Speeds of Over 2GB/s
Deathspawner writes: Samsung's SM951 is an unassuming gumstick SSD — it has no skulls or other bling — but it's what's underneath that counts: PCIe 3.0 x4 support. With that support, Samsung is able to boast speeds of 2,150MB/s read and 1,550MB/s write. But with such speeds comes an all-too-common caveat: you'll probably have to upgrade your computer to take true advantage of it. For comparison, Samsung says a Gen 2 PCIe x4 slot will limit the SM951 to just 1,600MB/s and 1,350MB/s (or 130K/100K IOPS), respectively. Perhaps now is a bad time to point out a typical Z97 motherboard only has a PCIe 2nd Gen x2 (yes, x2) connection to its M.2 slot, meaning one would need to halve those figures again.
It's curious how many relatively recent high-end PCs from prestige-brands don't have PCIe 3.0 slots. Alienware are a particular offender here - they were very slow adopters, quite possibly because a lot of their customers don't actually think to check for this when speccing up a machine.
That said, it's questionable how much it really matters in the real world at the moment. Performance tests on the latest video cards (which can take advantage of PCIe 3.0) have found very little performance gap between 3.0 and 2.0 (and even 1.0) with the likes of the Nvidia 980. The gap is most apparent at extremely high (150+) framerates - which is unlikely to constrain the average gamer, who probably just turns up the graphical settings until his PC can't sustain his target framerate (probably somewhere in the 40-60fps rate) any more.
OK, finally SSD drives are beginning to show up with the right spec.
Now we only need to get them memory mapped and good OS support for not loading constant data to volatile memory.
"My opinions are my own, and I've got *lots* of them!"
Then max out the RAM and create a RAM drive.
On my 2010 iMac, I have a 16 GB RAM drive that gets between 3 and 4 GB/s and still have 16 GB of RAM available for my apps.
Check this terminal command out before entering it just to be safe.
diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://33554432`
Under Mac OS 10.6.8, and 10.9 the above creates a 17 GB RAM disk.
diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://8388608`
This creates a 4.27 GB RAM disk. Enjoy the speed.
- Zav - Imagine a Beowulf cluster of insensitive clods...
Per my subject: I hear you. I recall, for instance/example, how HDD's going from SATA I to II didn't really "saturate" (or rather take FULL advantage of the theoretical value often extolled) the bus, & only used a FRACTION of what was being said WAS possible... that sticks out in my mind here.
Still - I am looking to buy to replace this current system of mine:
Intel Core I7 920 CPU
4gb DDR3 RAM
WD Velociraptor 10k rpm SATA II HDD
Gigabyte IRAM 4gb DDR3 "True SSD" (not flash-based & I use this for temp ops, print spooling, browser caches, pagefile location, + more)
NVidia GeForce 470 vidcard
* Reasons being what I am seeing from sites I respect's benchmarks:
Video -> http://www.techspot.com/articl...
CPU -> http://anandtech.com/bench/pro...
Disk (articles like this one - Flash based SSD tech seems to be truly "getting there" - especially on Samsung's end from what I've read, as well as early controller firmware issues being solved along with "trim" tech, etc-et al)
Still tough to decide WHEN is the "right time" to buy, due to the points you've made & that yes, I have seen myself... I don't know WHAT or WHO to fully trust (like a lot of things nowadays what-with what I call "spinmaster technology" out there that's been raised to a 'fine art', imo...)
APK
P.S.=> I've learned, the hard way perhaps (seeing what you're noting, lots of hype, no real-world practical gains) by buying every 6 months etc. upgrading components (for no REAL gains, not really, & certainly NOT for the monetary outlay) - however, *IF* those links I put up above are ANY valid indicator (this is the tough part - who can you really trust etc. as to data being put out), then, it's time to buy for me (since I am seeing TRIPLING of results in many tests on CPU, Video, & Disk especially)... apk
And with Cryptowall doing its thing as well? Come on, if you're not laughing when somebody tells you they write 2GB/s to flash memory, you're not awake.
Something that held back PCIe 3 support in many high end systems was the X79 chipset. If you want an E series, Intel's ultra high end desktop, processor, you have to use a different chipset. They don't rev that every generation though. So The X79 came out with the Sandy Bridge-E processors, and then the Ivy Bridge-E runs on the same thing.
There is a new chipset now, the X99, that works with the Haswell-E, but that just launched a few months ago.
Also with the high end processors, they are out of cycle with the normal ones. So the Haswell CPUs launched a good while ago, but the Haswell-E only launched now as Broadwell is launching.
Hence you can have a situation where for things like PCIe and USB the high end stuff is behind.
Because that's just so terrible, right? :p
How long can you sustain these kinds of I/O rates before burning the thing out?
Awesome it is so fast yet like LTE with tiny data caps utility appears to be substantially constrained by limitations on use.
For subset of people with workloads actually needing this kind of performance how useful is this? Reads can be cached by DRAM which is quite cheap.
For those who don't really need it I can understand how it would be nice to have.
The big news here is that this is pretty much the first consumer available SSD that supports NVME! There are some super-expensive pro devices that do NVME but they likely alone cost more than your whole high-end gaming rig.
http://en.wikipedia.org/wiki/NVM_Express
NVME is the interface that replaces AHCI, which was designed for spinning rust devices that can really only read and write one bit at a time. Flash based devices don't have to wait for moving parts and thus can access many things at once.
AHCI was designed for magnetic drives attached to SATA. NVME is explicitly designed to accommodate fast devices directly connected to PCI express. Take a look at the comparison table on the wikipedia page linked above. Multiple, deep, queues and lots of other features to remove bottlenecks that don't' apply to flash based storage.
How useful NVME currently is to consumers, though, is different. Only really new operating systems can boot from NVME devices. (Windows 8.1 or later. Don't know the current state of linux support but I bet at least someone's got a patched version of the kernel and grub if there's not mainline support already) And most most motherboards don't properly support NVME booting yet either. (Ive heard reports that some do with a BIOS/firmware update but it's currently really spotty)
The Techgage article said these are going out to the oems only. I think Samsung did that with their previous gen (PCIe 2.0) ssd. Anyone have any ideas where home system builders might find them?
More boards come with a 16x PCI-E 3.0 port for graphics than a 3.0-capable 4x slot. In fact, the big ones built for multiple graphics cards have 16x slots that reduce to 8x when both are in use or sometimes just the 2nd slot runs at 8x. They're all PCI-E 3.0 though. The problem is, you drop in that SSD in more basic but modern boards and there goes your aftermarket graphics card. You can never add one because you're taking up the only PCI-E slot that isn't 1x or 2.0.
A lot of people are posting how RAM disks are stupid because the file buffer cache already does a better job without the worries about filling the temporary filesystem or synchronizing. I agree with them.
A lot of people are posting about how a RAM disk made huge improvements to their build times. I agree with them too. This is mostly due to typical tools doing lots of file open/close/flush handshakes that have to commit to disk through the filesystem. A RAM disk lacks this latency and source of serialization. The normal file buffer cache is a write-through cache from the perspective of all these little file transactions.
A better solution to address all of these issues is to have a working filesystem on disk for which you enable write-back caching mode. Suddenly, it can buffer writes in RAM and return immediately to allow programs to proceed, while flushing them in the background. You don't need to synchronize anything. The only risk is losing data consistency on an unscheduled crash/poweroff, just as you would with a background rsync or any other asynchronous method. You can even do this at the level of an entire development VM, enabling write-back caching for the VM image file so that the guest OS doesn't even realize there is asynchronous writing going on.
1. These are sequential speeds. They're only relevant when you're dealing with large files. Unless your job is working with video or disk images or other large files, the vast majority of your files are going to be small, and the IOPS matters more. 130k/100k IOPS is really good, but only about a 10%-20% improvement over SATA3 SSDs. It translates into 520/400 MB/s at queued 4k read/writes best case. Current SATA3 drives are already surpassing 400 MB/s queued 4k read/writes.
2. Like car MPG, the units here are inverted from what actually matters. You don't say "gee, I have 5 gallons in the tank I need to use today, how many miles can I drive with it?", which is what MPG tells you. You say "I need to drive 100 miles, how many gallons will it take?" which is gal/100 miles. Yes they're just a mathematical inverse, but using the wrong one means the scaling is not linear. If you've got a 100 mile trip:
A 12.5 MPG vehicle will use 8 gallons
A 25 MPG vehicle will use 4 gallons (a 4 gallon savings for a 12.5 MPG improvement)
A 50 MPG vehicle will use 2 gallons (a 2 gallon savings for a 25 MPG improvement)
A 100 MPG vehicle will use 1 gallon (a 1 gallon savings for a 50 MPG improvement)
See how the fuel saved is inversely proportional to the MPG gain? As you get higher and higher MPG, it matters less and less because MPG is the wrong unit. If you do it in gal/100 miles it's linear. (This is why the rest of the world uses liters / 100 km.)
An 8 gal/100 mile vehicle will use 8 gallons.
A 4 gal/100 mile vehicle uses 4 gallons (a 4 gallon savings for a 4 gal/100 mi improvement)
a 2 gal/100 mile vehicle uses 2 gallons (a 2 gallon savings for a 2 gal/100 mi improvement)
a 1 gal/100 mile vehicle uses 1 gallon (a 1 gallon savings for a 1 gal/100 mi improvement)
The same thing is true for disk speeds. Unless you've got a fixed amount of time and need to transfer as much data as you can in that time, MB/s is the inverse of what you want. The vast majority of use cases are a fixed amount of MB that needs to be read/written, and the time it takes to do that is what you're interested in because that's time you spend twiddling your thumbs. If a game needs to read 1 GB to start up:
A 100 MB/s HDD will read it in 10 sec
a 250 MB/s SATA2 SSD will read it in 4 sec (a 6 sec savings for a 150 MB/s improvement)
A 500 MB/s SATA3 SSD will read it in 2 sec (a 2 sec savings for a 250 MB/s improvement)
A 1 GB/s PCIe SSD will read it in 1 sec (a 1 sec savings for a 500 MB/s improvement)
This 2 GB/s PCIe SSD will read it in 0.5 sec (a 0.5 sec savings for a 1000 MB/s improvement
Again, the actual time savings is inverted from the units we're using to measure. We really should be benchmarking HDDs and SSDs by sec/MB.
A 10 sec/MB HDD will read 1 GB in 10 sec
A 4 sec/MB SATA2 SSD will read it in 4 sec (a 6 sec savings for a 6 sec/MB improvement)
A 2 sec/MB SATA3 SSD will read it in 2 sec (a 2 sec savings for a 2 sec/MB improvement)
A 1 sec/MB PCIe SSD will read it in 1 sec (a 1 sec savings for a 1 sec/MB improvement)
This 0.5 sec/MB PCIe SSD will read it in 0.5 sec (a 0.5 sec savings for a 0.5 sec/MB improvement)
That's nice and linear. You see that the vast majority of your speedup comes from switching from a HDD to a SSD - any SSD, even the old slow first gen ones. The next biggest savings is switching to a SATA3 SSD. Beyond that the extra speed is nice, but don't be mislead by the huge MB/s figures - the speedup from PCIe drives will never be as big as those first two steps from a HDD to a SATA SSD. Manufacturers just report performance in MB/s (instead of sec/MB) because it exaggerates the importance of tiny increases in time saved, and thus helps them sell new and improved (and more expensive) products. Review sites also report in MB/s because if you report in sec/MB, the benchmark graphs are boring and the speedup from these shiny new SSDs is barely perceptible.
A Linux RAM disk (tmpfs) just stores files in the page cache, so there's really no difference. OK, it can also write out those files to the swap partition if you run out of RAM, but you usually shouldn't be using a RAM disk unless you have plenty of RAM.
And that's a big improvement over some old-style RAM disks where you told it you wanted 500MB and it grabbed those 500MB and didn't let anyone else use it.
This matters to me more than your claims of "all modern operating systems taking full advantage of the RAM". If the operating system takes full advantage of the RAM, it may not be to my best benefit.
tl;dr: If you don't know what you're doing (or like me are too lazy to care) with respect to memory management (most Mac users) then the OS is likely a better steward than you. For everyone else, there are RAM drives :)
Why someone would criticize you for using a RAM drive ....doesn't make sense to me.
Make sure everyone's vote counts: Verified Voting
You're right (writes are INCREDIBLY fast): I tried to offset that on my WD Velociraptor using a Promise Ex-8350 128mb ECC RAM caching RAID controller I didn't list earlier which *does* help some (especially on writes via delayed writes I suspect coupled with the disk's iirc 8mb RAM buffer).
On dataprocessing (I literally spent 20++ yrs. in the field as a coder doing SQL database work): ONLY real dataprocessing I do now is hosts file processing using this application I wrote:
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
It's used to import, normalize & deduplicate + validate the data from 12 reputable sites in the security community that produce said data. I do the work on the SSD I noted I have. Not same tech as Flash though.
(That data works for more speed, security, & reliability)
The program's HEAVY on string processing: hence, WHY I figured that a faster CPU would help (file's getting big now, 3,366,444++ known bad sites.
It's taking a LOT longer now due to the size of the file nowadays.
This happened to me before.
I had an AMD DualCore that eventually, around 1++ million records, took 40 minutes to do that job on that number of records - I got the machine I listed, & that SAME DATA took only 15 minutes!
I was hoping for the same increase in speed/decrease in time for the process to finish, but... from what You're saying, there isn't MUCH of a boost (which is why I noted that those benchmarks *might* be deceiving).
I do know, however, that string processing work is HIGHLY CPU INTENSIVE - so, the only way to know, is to test on these high-end rigs nowadays.
APK
P.S.=> Hitting a gamer's forum might solve this: They tend to be helpful & have high end rigs (let them download the app, & process the initial data which is MUCH SMALLER than those millions of hosts file records I've built up here since 1997, by far (maybe 250,000 records, tops))... apk
According to TFA, it's being release to oem's only. I think Samsung did that for their previous gen PCIe 2.0 ssd also. Does anyone have an idea where to look for these, or an idea when they might become available to individual system builders? BTW, the Asus X99 MB's have a slot for these. Probably other brands of X99 MB's too.
FINALLY I haven't needed to build a new computer for a while. But INTEL's next gen (Skylake, due 2015 supposedly) includes PCIe 4.0 support right from the processor/bridge. Skylake + PCIe 3.0/4.0 SSD + displayport 1.3 for 4K monitors (also due 2015) = finally a reason to build a new system Skylake also supports DDR4, so we're finally attacking the problem of getting enough data to the processor fast enough!
Upcoming NUCs have support for these.