Effective uses for a RAMdisk in OS X?

[xizar]

Tooling around on NewEgg, I discovered that I could dump 16gigs of RAM in my "aging" iMac for about 40USD, so I figured I'd go for it.

I'm aware that "zomg 4gig only lolz" and "wtf 64bit n00b" seem to be prevailing sentiments when asking if one should use 64bit software or upgrading RAM past a certain point, so I hope to avoid that.

My question is, basically, are there good uses for a RAMdisk under OS X? Back in days of yore (before hard drives), I used to use them in DOS to load up games and the OS and stuff, but I *hope* that, with so much memory, the OS should never need to be touched.

I've been doing reading and learned that some people like to put their Minecraft data on a RAMdisk, and seen some benefit from that.

Are there other scenarios (out side of manipulation of very large multimedia files) where I can make good use of the doubled RAM, either in general or in the form of a RAMdisk?

What about under Bootcamp? At the moment, I have Win7's swapfile disabled, and never had an issue with it. Can I pimp some of that RAM into a swapfile?

Thanks for your time and constructive input.

 

[AlanShutko]

Well, on OS X I haven't found any reason to use any of the RAM as a ram disk. OS X is quite good at using extra ram as a disk cache, so I just let it manage things. (I have a 27" iMac with 16GB.)

I love that I can have as much running at once and still never hit swap. It makes it a lot easier to leave programs running because you'll need them tomorrow or something. Although, even without leaving them running, the fact that they're in cache will still cause them to load faster.

The main reason you'd want to move stuff to disk cache is if you have a particular program that's accessing things in a way that doesn't cache well and it's committing the files to "disk" often. Minecraft seems to be one of those programs. Photoshop is not... It does better if you just let it use RAM as RAM.

Windows under bootcamp is another matter. It SHOULD be caching things as well, but with the legacy of programs stuck under 32-bit land, it seems things aren't as good. I am using a 7GB RAM disk for Skyrim under Windows. I just copy the whole thing into the RAM disk on boot, and let the program run from there.

 

[xizar]

While I don't play Skyrim, I do play Fallout New Vegas (still), so knowing that it helps with that is good to know. Unfortunately, my setup is rather modded (graphics and shaders and stuff), so my FO:NV folder is 13gigs.

I rather doubt it would be prudent to go with a 13gig RAMDisk and 3 gigs of RAM.

Borderlands, however, is only ... Borderlands is also 13gigs.

Crap.

Oh well, thanks very much for your input.

Also, I'm not sure if you're aware, but there's a (well vetted and trusted) program out that will allow Skyrim to take advantage of more memory than just the 2 (or 4?) gigs the default executable allows. I use the Fallout version and it makes a difference.

You can search SkyrimNexus for it (or use the link below if you trust me not to rickroll you.

http://skyrimnexus.com/downloads/file.php?id=1013

 

[brdeveloper]

If you have large Java projects under Eclipse, building/deploying your app is pretty fast with a ramdisked workspace.

Basically, if you have an application which makes use of HUGE i/o, a ramdisk is a good option. OSX's virtual memory should be enough, but in practice, it isn't.

Sorry for reviving this topic, but I'm doing some research on this subject...

 

[switon]

RE: really...

Wow,

I would have thought that with today's OSes and fast memory, RAMdisks were a thing of the past. Maybe a RAMdisk might still be useful to load a boot kernel image to run while updating the full kernel, but I wouldn't have thought that too many apps would actually benefit from this. Very interesting.

Thanks,
Switon

 

[djdawson]

I realize this is a bit of an old thread, but one use I've had for a RAMdisk is to use it as a destination drive for capturing high speed network data with tools such as "tcpdump" and Wireshark. For doing protocol analysis at high speeds this can allow these utilities to keep up.

 

[freejazz-man]

thanks for that tip dawson, it's definitely something I'm going to keep in mind for the future

 

[aratio]

Temporary compile files

I think a good use for RAM disk is also to use it as temporary storage for header files (since they can be accessed several times in the compile process) and temporarily generated object files.

 

[Isamilis]

Just to share what I've tried recently. I have 8GB / 128GB SSD MBA 2012 with ML 10.8.3. I made RAM Disk for:
- 1 GB for user's cache folder
- extra 3 GB for storing and running VM image of my Win XP Parallels Desktop with 512mb allocated for RAM

What I found is:

• overall system temp is cooler. I am still looking, what is the real factor, but this is noticeable especially when running XP in Parallels. The temp is also *slightly* cooler for casual tasks (watching moving, browsing, online radio, etc)
• install XP SP3 took only around 10 minutes up to completion of Parallel Tools installation in XP
• there is no significant speed difference, running VM under RAM Disk versus SSD, only it feels cooler (the temp is kept normal, around 49-55 celcius)
• Running aperture and safari seems slightly faster. I'm not sure, how much faster
• Battery consumption is also reduced. I can watch movie using mplayerx - 2 hours with only small fraction lowered of battery level.
• All safari cache are cleared automatically when restarting the OSX. This is including Top Sites as well. You don't have to clean cache folder manually (like using Onyx or Yasu)

I knew, this may not be as scientific as expected. But for now, I think the benefit is worthy.

Thanks.

 

[Mr. Retrofire]

Are there other scenarios (out side of manipulation of very large multimedia files) where I can make good use of the doubled RAM, either in general or in the form of a RAMdisk?

I use RAM disks for compression benchmarks (compression software development). I use (compress) a copy of the latest Linux kernel source code (just an example). This folder contains hundreds of subfolders, and thousands of files. The compression program must open/read/close each file. This is very time consuming if the folder is on a HDD or SSD.

 

[simie]

I personally use a ramdisk for photoshop and put its scratch disk in the ramdisk thus speeding up operations. I have been running this config for years and find it very reliable.

 

[startergo]

I know it is an old thread but did not want to duplicate it. I have plenty of ram 128GB and I wold like to use some of it. I am thinking of creating a raid ram disks for VM disks. Any advice how to create it? Any other scenarios for my RAM to do some usefull work?

 

[chown33]

I know it is an old thread but did not want to duplicate it. I have plenty of ram 128GB and I wold like to use some of it. I am thinking of creating a raid ram disks for VM disks. Any advice how to create it? Any other scenarios for my RAM to do some usefull work?

Can you explain exactly what you hope to gain with a RAID ram-disk, as distinct from a simple non-RAID ram-disk?


To me, a RAID ram-disk makes no sense at all, because the storage medium (RAM) conflicts with the reasons for using RAID.

The main reasons for using RAID at all are:

1. Speed - data is striped across multiple drives, which can be accessed separately (overlapped, in parallel).
2. Reliability - data is duplicated across multiple drives, so if one drive fails no data is lost.​

Neither of these reasons make any sense for RAM-disks.

Speed makes no sense, because RAM can't be accessed in parallel, since there aren't multiple separately accessible RAM banks. Thus, striping in the hope of having overlapping or parallel access is belied by the nature of the RAM itself.

Reliability makes no sense, either, because RAM-disks are inherently volatile. If power drops, their data disappears. There's no reason for data duplication, because the RAM itself isn't persistent. There are no "drives" whose persistent data needs duplication, because there is no persistent data in the first place.

If there's some other reason for applying RAID to RAM-disk storage, please explain what it is.

 

[startergo]

Can you explain exactly what you hope to gain with a RAID ram-disk, as distinct from a simple non-RAID ram-disk?


To me, a RAID ram-disk makes no sense at all, because the storage medium (RAM) conflicts with the reasons for using RAID.

The main reasons for using RAID at all are:

1. Speed - data is striped across multiple drives, which can be accessed separately (overlapped, in parallel).
2. Reliability - data is duplicated across multiple drives, so if one drive fails no data is lost.​

Neither of these reasons make any sense for RAM-disks.

Speed makes no sense, because RAM can't be accessed in parallel, since there aren't multiple separately accessible RAM banks. Thus, striping in the hope of having overlapping or parallel access is belied by the nature of the RAM itself.

Reliability makes no sense, either, because RAM-disks are inherently volatile. If power drops, their data disappears. There's no reason for data duplication, because the RAM itself isn't persistent. There are no "drives" whose persistent data needs duplication, because there is no persistent data in the first place.

If there's some other reason for applying RAID to RAM-disk storage, please explain what it is.

Actually you answered part of my question. I just wanted to increase speed but apparently it is not possible.
1. So if I want to use ramdisk for a VM drive how can I automate backup and restore of the hard drive from ram to disk and vice versa upon shutdown and reboot? (Automator script of some sort?). What is the maximum size of the ram drive I can create?
2. What else can I put my big ram to useful work with ram disk?

 

[chown33]

Actually you answered part of my question. I just wanted to increase speed but apparently it is not possible.
1. So if I want to use ramdisk for a VM drive how can I automate backup and restore of the hard drive from ram to disk and vice versa upon shutdown and reboot? (Automator script of some sort?). What is the maximum size of the ram drive I can create?
2. What else can I put my big ram to useful work with ram disk?

I assume you mean "Virtual Machine" when you write "VM". I want to make sure I understand exactly what you're trying to do. Because another possible meaning is "Virtual Memory", which would be quite pointless to use a ram-disk for.

What parts of a Virtual Machine are you hoping to speed up? Which virtualizer are you using? For which virtualized OS? What is the virtualized system being used for?

A Virtual Machine normally resides on storage backed by a hard drive or SSD with a file-system. The file-system itself will automatically use available RAM to cache disk operations, so I'm not sure how much practical benefit you'd get by using a ram-disk in place of a real disk (rotating or SS), since a real disk automatically provides the desired persistence. If you force the virtualized file-system entirely into cache, then you get RAM speeds automatically backed by persistent storage.

A disk-image will also be backed by persistent storage (rotating or SS), and may alter how Mac OS decides to cache things in RAM.

I don't have an exact answer about max size, but I'd think that the software you're using to make the RAM-disk would tell you that in its user manual. Since you haven't identified what you're using, I can't look it up in the manual.

If you're looking for specific things to try, then a number of cases are described earlier in the thread. For example, I liked the idea of using it in developing compression algorithms, as a way to isolate and minimize file-system costs. Of course, that requires one to be developing compression algorithms.

If you can't think of a way to put large amounts of RAM to direct use, I recommend not worrying about it. Mac OS will cache things in RAM as it needs to, using as much available RAM as you have. So if your Mac runs long enough, it may eventually use a substantial part of the RAM. Again, it's hard to be precise about this, since you didn't provide details on your OS version.

 

[startergo]

I assume you mean "Virtual Machine" when you write "VM". I want to make sure I understand exactly what you're trying to do. Because another possible meaning is "Virtual Memory", which would be quite pointless to use a ram-disk for.

What parts of a Virtual Machine are you hoping to speed up? Which virtualizer are you using? For which virtualized OS? What is the virtualized system being used for?

A Virtual Machine normally resides on storage backed by a hard drive or SSD with a file-system. The file-system itself will automatically use available RAM to cache disk operations, so I'm not sure how much practical benefit you'd get by using a ram-disk in place of a real disk (rotating or SS), since a real disk automatically provides the desired persistence. If you force the virtualized file-system entirely into cache, then you get RAM speeds automatically backed by persistent storage.

A disk-image will also be backed by persistent storage (rotating or SS), and may alter how Mac OS decides to cache things in RAM.

I don't have an exact answer about max size, but I'd think that the software you're using to make the RAM-disk would tell you that in its user manual. Since you haven't identified what you're using, I can't look it up in the manual.

If you're looking for specific things to try, then a number of cases are described earlier in the thread. For example, I liked the idea of using it in developing compression algorithms, as a way to isolate and minimize file-system costs. Of course, that requires one to be developing compression algorithms.

If you can't think of a way to put large amounts of RAM to direct use, I recommend not worrying about it. Mac OS will cache things in RAM as it needs to, using as much available RAM as you have. So if your Mac runs long enough, it may eventually use a substantial part of the RAM. Again, it's hard to be precise about this, since you didn't provide details on your OS version.

Yes VM is virtual machine and there is actually an Apple script to Mount an APFS ramdisk I just don't know the max size which can be set:
https://gist.github.com/jasisk/a1c35e337edb3585585201b9763a3e99
BTW I am not worrying about the RAM being scarce, but not being used at all. The RAM disk provides a means of usage of the unused RAM.

 

[chown33]

Yes VM is virtual machine and there is actually an Apple script to Mount an APFS ramdisk I just don't know the max size which can be set:
https://gist.github.com/jasisk/a1c35e337edb3585585201b9763a3e99
BTW I am not worrying about the RAM being scarce, but not being used at all. The RAM disk provides a means of usage of the unused RAM.

Well, that's just a series of bash commands that uses 'hdiutil', which is built into Mac OS. I checked the man page for hdiutil, and its companion 'man hdid', and neither one listed an upper limit for RAM-disk size.

Since hdiutil is essentially just the cmd-line tool to access the system framework for managing all disk-images, my first guess is that RAM-disks have similar size limits as disk-based disk-images, which is effectively only limited by the space on the underlying media. For RAM, I'd assume it's limited only by your available RAM space.

A cautious approach would be to plug in increasing numbers to the command that makes the RAM-disk, and see how big it gets. I'd be sure to try mounting and writing to it, to ensure it actually works.

Or you could throw caution to the wind and go straight to a big number like 64 GB (half your RAM space). If that works, it should be big enough to play around with.

The value to change in the referenced script is SIZE:

SIZE=1024
DISKNAME=ramdisk
MOUNTPATH="$HOME/mnt"
DISK="$(basename $(hdiutil attach -nomount "ram://$(( ${SIZE} * 1024 * 1024 / 512 )))"
diskutil partitionDisk "${DISK}" GPT APFS %noformat% R
newfs_apfs -v "${DISKNAME} "${DISK}s1"
diskutil mount -mointPoint "${MOUNTPATH}" "${DISKNAME}"

The multiplication by "1024 * 1024" means SIZE is measured in units of MB. So 64GB in units of MB would be roughly 64000 (technically, it's 65536, but close enough for playing). So change the 1st line to this:

SIZE=64000

then try it and see what happens. If it works, edit in a bigger number and reboot. If it fails, edit in a smaller number and try again.


Since the RAM-disk is essentially a disk-image, the only way I can think of to make it persistent is to copy it entirely to persisent storage, such as a dmg file (disk-image). That file will be the same size as the RAM-disk, so it will take some time to write it all to disk, even if only a small amount of the RAM-disk is actually being used. Even the 'dd' cmd will ultimately be limited to the speed that your persistent backing-storage can complete writes. Compression before writing may be worthwhile,

You'd also need to restore the RAM-disk's contents, which might also be dd-able, but will likely need some trial runs. That would be limited by the read speed of the persistent backing storage.

 

[startergo]

Well, that's just a series of bash commands that uses 'hdiutil', which is built into Mac OS. I checked the man page for hdiutil, and its companion 'man hdid', and neither one listed an upper limit for RAM-disk size.

Since hdiutil is essentially just the cmd-line tool to access the system framework for managing all disk-images, my first guess is that RAM-disks have similar size limits as disk-based disk-images, which is effectively only limited by the space on the underlying media. For RAM, I'd assume it's limited only by your available RAM space.

A cautious approach would be to plug in increasing numbers to the command that makes the RAM-disk, and see how big it gets. I'd be sure to try mounting and writing to it, to ensure it actually works.

Or you could throw caution to the wind and go straight to a big number like 64 GB (half your RAM space). If that works, it should be big enough to play around with.

The value to change in the referenced script is SIZE:

SIZE=1024
DISKNAME=ramdisk
MOUNTPATH="$HOME/mnt"
DISK="$(basename $(hdiutil attach -nomount "ram://$(( ${SIZE} * 1024 * 1024 / 512 )))"
diskutil partitionDisk "${DISK}" GPT APFS %noformat% R
newfs_apfs -v "${DISKNAME} "${DISK}s1"
diskutil mount -mointPoint "${MOUNTPATH}" "${DISKNAME}"

The multiplication by "1024 * 1024" means SIZE is measured in units of MB. So 64GB in units of MB would be roughly 64000 (technically, it's 65536, but close enough for playing). So change the 1st line to this:

SIZE=64000

then try it and see what happens. If it works, edit in a bigger number and reboot. If it fails, edit in a smaller number and try again.


Since the RAM-disk is essentially a disk-image, the only way I can think of to make it persistent is to copy it entirely to persisent storage, such as a dmg file (disk-image). That file will be the same size as the RAM-disk, so it will take some time to write it all to disk, even if only a small amount of the RAM-disk is actually being used. Even the 'dd' cmd will ultimately be limited to the speed that your persistent backing-storage can complete writes. Compression before writing may be worthwhile,

You'd also need to restore the RAM-disk's contents, which might also be dd-able, but will likely need some trial runs. That would be limited by the read speed of the persistent backing storage.

Actually I found a script which creates a raid of 2 4GB disk (8GB raid) I will try it and post the speed results. I will have to modify it for APFS:

do shell script ”
if ! test -e /Volumes/\”Users SpeedDisk\” ; then
diskutil erasevolume HFS+ r1 `
hdiutil attach -nomount ram://$((4*1024*2048))`
diskutil erasevolume HFS+ r2 `
hdiutil attach -nomount ram://$((4*1024*2048))`
diskutil createRAID Stripe \”Users SpeedDisk\” HFS+ /Volumes/r1 /Volumes/r2;
fi
mkdir /Volumes/\”Users SpeedDisk\”/\”Download\” ;
rm -rf ~/Library/Caches;
mkdir /Volumes/\”Users SpeedDisk\”/\”Users Caches\”;
ln -s /Volumes/\”Users SpeedDisk\”/\”Users Caches\” ~/Library/Caches;

 

[chown33]

Actually I found a script which creates a raid of 2 4GB disk (8GB raid) I will try it and post the speed results. I will have to modify it for APFS:

do shell script ”
if ! test -e /Volumes/\”Users SpeedDisk\” ; then
diskutil erasevolume HFS+ r1 `
hdiutil attach -nomount ram://$((4*1024*2048))`
diskutil erasevolume HFS+ r2 `
hdiutil attach -nomount ram://$((4*1024*2048))`
diskutil createRAID Stripe \”Users SpeedDisk\” HFS+ /Volumes/r1 /Volumes/r2;
fi
mkdir /Volumes/\”Users SpeedDisk\”/\”Download\” ;
rm -rf ~/Library/Caches;
mkdir /Volumes/\”Users SpeedDisk\”/\”Users Caches\”;
ln -s /Volumes/\”Users SpeedDisk\”/\”Users Caches\” ~/Library/Caches;

I'll be interested to see the results.

My sense is there won't be any significant difference for the RAID vs. a straight-up same-sized ram-disk, all else being equal. If anything, I'd expect to see a small cost for the RAID, due to the extra overhead involved in striping. That overhead is negligible when overall speed is dominated by seeks and writes to spinning metal platters, but as the raw speed of the medium increases, previously negligible management costs can come to dominate.

 

[startergo]

I'll be interested to see the results.

My sense is there won't be any significant difference for the RAID vs. a straight-up same-sized ram-disk, all else being equal. If anything, I'd expect to see a small cost for the RAID, due to the extra overhead involved in striping. That overhead is negligible when overall speed is dominated by seeks and writes to spinning metal platters, but as the raw speed of the medium increases, previously negligible management costs can come to dominate.

Could not run the raid script but here is the performance of the 28GB single RAM disk :

 

[chown33]

Could not run the raid script but here is the performance of the 28GB single RAM disk :

That seems pretty snappy. Do you know how it compares to other systems?

 

[startergo]

That seems pretty snappy. Do you know how it compares to other systems?

Hi,

Yesterday I did install my new Lycom DT-120 with its SM951 512GB (NVMe) M.2 PCIe.
I've to admit, it's fast! Moving from a SSD SATA II to a PCIe SSD it is a different world!

With the raise of the SSD it change my way of working but in the meantime the size of the files just boom!
After working/testing with a RAM disk to improve my way of working with all the pros and cons, I found the best of the two worlds! Secure and efficient!

Here is how i did proceed to install my card and the SSD on my MacPro running over El Capitan.
my SIP was already deactivated, before anything I suggest you to deactivate the SIP if you are going to do the same

1. Install your card on the Slot 3 or 4 of your MacPro
2. Download the NVMe driver here
3. Copy the kext file NVMeGeneric.kext into /Library/Extensions
4. cmd + i on the Extensions folder and update the permission by clicking on "apply to enclosed items"
   
5. Reboot my computer
6. Open the terminal and enter the following command line: "
7. sudo kextload /Library/Extensions/NVMeGeneric.kext"
8. A popup window should appear asking you to reinitialise the new detected support.
9. Do it
10. Happy!

You can reactivate SIP after

Bench

​

However, the system information software doesn't seems to recognise the PCI card or the NVMe support.
When I click on NVMEExpress tab i have this message
This computer doesn't contain any NVMExpress devices. If you installed NVMExpress devices, make sure they are connected properly and powered on.

PCI tab
There was an error while gathering PCI device information.

Do you know why? is it a limitation of El capitan?

Other quick question because I don't find the answer. How can I activate the TRIM and where can I see the TRIM support confirmation?
The SSD is displayed as an external support which is strange with Disk utility.

Thanks!

One example
[doublepost=1540486458][/doublepost]

I'm making this thread to put together some general info on the blade SSDs that can be used in the Mac Pro. NVMe SSDs can be used as a boot drive in the Mac Pro 5,1 and 6,1 with the latest firmware installed (140.0.0.0.0 for MP5,1). Note that blade SSDs installed in a Mac Pro 5,1 are limited to ~1,500 MB/s unless installed on a PCIe switch card in slot 1 or 2 such as a HighPoint 7101 or Amfeltec Squid that converts the Mac Pro PCIe 2.0 x16 to the PCIe 3.0 x4 needed for full throughput. Also note that 3rd party SSDs have varying compatibility with the Mac and not all listed below may be fully compatible.

Apple SSDs: Proprietary Apple PCIe adapter needed for Mac Pro 5,1 & older. No adapter needed for Mac Pro 6,1.

SSUAX: Based on Samsung XP941 with UAX controller (S4LN053X01): AHCI
2D MLC
Available in 128GB, 256GB, 512GB, and 1TB
PCIe 2.0 x2 (128GB, 256GB, 512GB) & PCIe 2.0 x4 (1TB)
Speeds: ~1,000 MB/s read, ~800 MB/s write
Compatibility status: Good

SSUBX: Based on Samsung SM951 with UBX controller (S4LN058A01): AHCI
2D MLC
Available in 128GB, 256GB, 512GB, and 1TB
PCIe 3.0 x4
Speeds: ~1,500 MB/s read, ~1,425 MB/s write
Compatibility status: Good

SSPOLARIS: Based on Samsung SM961 or PM961 with Polaris controller (S4LP077X01): NVMe
2D & 3D MLC or TLC
Available in 24GB, 32GB, 128GB, 256GB, 512GB, 1TB, and 2TB
PCIe 3.0 x4
Speeds: ~2,700 MB/s read, ~2,350 MB/s write
Compatibility status: Good

Good article on Apple blade SSDs: The Ultimate Guide to Apple’s Proprietary SSDs

Samsung SSDs: M.2 PCIe adapter needed for Mac Pro 5,1. M.2 to proprietary Apple adapter needed for Mac Pro 6,1.

XP941: UAX controller (S4LN053X01): AHCI
2D MLC
Available in 128GB, 256GB, and 512GB
PCIe 2.0 x2 (128GB, 256GB, 512GB) & PCIe 2.0 x4 (1TB)
Speeds: ~1,000 MB/s read, ~800 MB/s write
Datasheet
Compatibility status: Good

SM951: UBX controller (S4LN058A01): Both AHCI and NVMe versions
2D MLC
Available in 128GB, 256GB, and 512GB
PCIe 3.0 x4
Speeds: ~1,500 MB/s read, ~1,425 MB/s write
Datasheet (AHCI), Datasheet (NVMe)
Compatibility status (AHCI): Good
Compatibility status: (NVMe):

950 PRO: UBX controller (S4LN058A01): NVMe
3D MLC
Available in 256GB and 512GB
PCIe 3.0 x4
Speeds: ~2,500 MB/s read, ~1,500 MB/s write
Datasheet
Compatibility status: (NVMe): Issues/not compatible

PM961: Polaris controller (S4LP077X01): NVMe
3D TLC
Available in 128GB, 256GB, 512GB, and 1TB
PCIe 3.0 x4
Speeds: ~3,000 MB/s read, ~1,500 MB/s write
Datasheet
Compatibility status: Good

960 EVO: Polaris controller (S4LP077X01): NVMe
3D TLC
Available in 250GB, 500GB, and 1TB
PCIe 3.0 x4
Speeds: up to 3,200 MB/s read, up to 1,900 MB/s write
Datasheet
Compatibility status:

SM961: Polaris controller (S4LP077X01): NVMe
2D & 3D MLC
Available in 128GB, 256GB, 512GB, and 1TB
PCIe 3.0 x4
Speeds: ~3,200 MB/s read, ~1,800 MB/s write
Datasheet
Compatibility status: Good

960 PRO: Polaris controller (S4LP077X01): NVMe
2D & 3D MLC
Available in 512GB, 1TB, and 2TB
PCIe 3.0 x4
Speeds: ~3,500 MB/s read, ~2,100 MB/s write
Datasheet
Compatibility status:

PM981: Phoenix controller (S4LR020): NVMe
3D TLC
Available in 256GB, 512GB, 1TB, and 2TB
PCIe 3.0 x4
Speeds: ~3,500 MB/s read, up to 2,400 MB/s write
Datasheet
Compatibility status: Issues/not compatible

970 EVO: Phoenix controller (S4LR020): NVMe
3D TLC
Available in 250GB, 500GB, 1TB, and 2TB
PCIe 3.0 x4
Speeds: up to 3,500 MB/s read, up to 2,500 MB/s write
Datasheet
Compatibility status: Good

970 PRO: Phoenix controller (S4LR020): NVMe
3D MLC
Available in 512GB and 1TB
PCIe 3.0 x4
Speeds: up to 3,500 MB/s read, up to ~3,000 MB/s write
Datasheet
Compatibility status: Good

Recommended PCIe adaptors:​

Standard PCIe x4 cards (tops at 1500 MB/s)(no switch):

Low cost:

Lycom DT-120

For proprietary Apple SSD: generic adapter from eBay (e.g. "2013-2014 Macbook Air SSD PCIe adapter 4X") (no brand)

Medium cost:

Angelbirds Wings PX1

Aqua Computer kryoM2 evo: Aqua Computer kryoM.2 evo PCIe 3.0 x 4, adapter

PCIe x8 & x16 switch cards:

Better performance / higher cost (up to 3,000 MB/s):

IO Crest IO-PCE2824-TM2 (aka Syba SI-PEX40129): Supports 2 blade SSDs. Uses ASMedia ASM2824 switch.

Top performance / high cost (tops at 3200 MB/s with one blade, 6200 MB/s with two to four):

Amfeltec Squid: Amfeltec x16 PCIe with 4 SSDs: 5900+ MB/s. Supports 4 blade SSDs. Uses PLX PEX8732 switch.

HighPoint SSD7101A: Highpoint 7101A - PCIe 3.0 SSD performance for the cMP. Supports 4 blade SSDs. Uses PLX PEX8747 switch.

More comparison

 

[chown33]

One example
[doublepost=1540486458][/doublepost]

More comparison

The picture of that benchmark at ~1400 MB/sec seems inconsistent. Since yours benchmarked in excess of 2000 MB/sec, it seems kind of odd to me that the meter needles are below the half-way mark. Or is full scale on the meters keyed to the type of storage device? That is, does Black Magic know that the upper limit for RAM-disks is, say, 6000 MB/sec, so when it reads 2200 MB/sec it draws the meter needle below the mid-point?

Or is there a simpler explanation: the meter needles mean nothing.

 

[startergo]

I did the screenshot during the test. The speed was very consistent. Since it was not a screenshot of an end result you might see some discrepancies. Highest reading speed was in the ballpark of 2500

 

[chown33]

I did the screenshot during the test. The speed was very consistent. Since it was not a screenshot of an end result you might see some discrepancies. Highest reading speed was in the ballpark of 2500

I meant the screenshot in the first example you quoted, which links to here:
https://forums.macrumors.com/threads/pcie-m-2-nvme-on-macpro.2030791/#post-24265661

That screenshot shows ~1400 MB/s, and the meter needles are well over 50%. Your screenshot shows ~2400 MB/s (substantially above 1400), yet your meter needles are well below 50%. That's an odd discrepancy to me.