MP 1,1-5,1 Internal SATA2 SSD vs PCIe SSD vs PCIe NVMe; MacPro 5,1 2010

[bosDAW]

Hello, I have spent the last few days searching forums for general information, and it seems this one has some of the most tech savvy members (of which I am not!). I understand computer hardware at a relatively basic level and would appreciate some feedback or suggestions for the following issues observed in trying to upgrade my cMP. Note that I use the mac for digital audio and would like to get the best performance out of my sample drives (primarily read only or read "mostly") that store large sound libraries ranging in size from 12GB up to 700GB each.

Current config: Samsung 860PRO 1TB SSD, internal drive bays
Alternate config (i.e. I have the card but do not use it): Sonnet Tempo Pro Plus 6Gb/s SATA PCIe 2.0 x4
Considered config: 970PRO or EVO plus used with Sonnet M.2 4x4 PCIe card

1.a. Will an NVMe via PCIe card give better performance than an SSD via PCIe or even the internal drive bay? Or is there no real-world difference?
The reason I ask is because a rather quick test produced some unexpected [to me] results. It not very scientific, but the basic idea was to open a stand-alone application of a software synth (Omnisphere 2.6) with samples being loaded from an internal SSD (Samsung 860PRO); I clicked/cycled through the first dozen of the presets, which range in size from 1MB to 1GB, and noted the time required to load each one; I repeated a similar operation using a sample player (EastWest Play software using Hollywood Orchestra Diamond sample library; this software/library is notoriously slow to load large files); I then took the same SSD, plugged it into the Sonnet Tempo Pro Plus and ran the same tests; for reference, I measured performance using BlackMagic in both setups:

Samsung 860PRO 1TB SSD, internal bay-> 260Mb Write, 271Mb Read
Samsung 860PRO 1TB SSD, Sonnet Tempo Pro Plus PCIe 2.0 x4-> 457Mb Write, 527Mb Read


Results
The BlackMagic speeds were as expected. For Omnisphere, presets <10Mb in size loaded instantly, with no perceptible lag; presets 10-538Mb in size loaded almost instantly (they loaded ~equally as fast, the only difference being that a green progress bar in the GUI is momentarily visible, at which point the preset has already loaded anyway); the largest preset tested was 1229Mb and took 3-4s to load, with a clearly visible progress bar that is first yellow and then green. One 474Mb preset took ~2s whereas one 538Mb preset loaded almost instantly. The smallest EastWest presets I tested took <1.5s to load and the largest all took about 3-4s to load (I don't know the sample sizes for these, but loading time is always noticeably longer vs Omnisphere).

Initially, I would have thought ~2xSSD speed would load presets ~2x as fast, or at least be a tiny bit faster, but this was not at all the case. Clearly, preset programming/complexity has at least something to do with it. Even so, I could see no observable difference in the time required to load the same presets under the same conditions with the same SSD in either software synth in either setup; they were indistinguishable. The smallest presets in Omnisphere were still instant, the medium ones were still "almost" instant (with the same green bar visible momentarily), and the largest one still took 3-4s (with the same yellow bar visible). The EastWest samples also behaved exactly the same. There was simply nothing that would indicate any difference in loading times despite the clear speed difference between the internal bay and the PCIe card.

This is where I would ask for your help, as the answer may be obvious to you but not so much to me! Clearly, SSD speed is not the limiting factor, but why? Why is there no change at all? Neither do I know if it is the CPU, the software itself, or something else entirely. Somewhere, a bottleneck seems to occur long before even the "slowest" SSD setup is able to reach anywhere near peak performance.

NB The system disk is an older SSD (Apple brand Toshiba purchased with the system back in 2012) and measures up at 165Mb write/222Mb read vs the Samsung 860PRO. This is a difference of ~100Mb/s write speed and ~50Mb/s read speed, but I would not expect the system disk to be the limiting factor as it is not really "doing" anything here, but maybe this is incorrect?

1.b. Would using a new SSD as the system drive change anything here?

Following from the above...

2. Is there any reason to expect a difference with NVMe?
If doubling [roughly] the speed from 250Mb/s to 500Mb/s on PCIe does absolutely nothing in terms of performance, I would think that "tripling" this with an NVMe would be a very expensive way to get the exact same results (I am guessing the best I could get from NVMe on PCIe 2.0 would be ~1500Mb/s with the Sonnet M.2 4x4 PCIe card; and 3 x 0 improvement is still 0!). But I do not know enough about computer hardware to know if this is correct. Perhaps the NVMe would indeed be faster for some other reason? Perhaps there is only a difference in speed with presets/project files that are significantly larger (2, 5, 10, 100Gb)?

3. Is this an inherent limitation of the Mac Pro? Or, what is the fastest possible configuration?
I sent the same questions to the software manufacturers to see if they have any insights, but I suspect this has something to do with SSD hardware, QD, bus architecture, or maybe 5,1 firmware. Or maybe it is inherent to how sample data is read from an SSD? Compression/decompression? My system is as up to date as possible without getting a Metal GPU and installing Mojave (or just updating firmware and going back to stock 5770 GPU and High Sierra), but not sure if this would change anything.

I know it is a long post, but I am hoping that someone with a much better technical understanding will be able to offer some advice. Thank you for taking the time to read it!

 

[tsialex]

Your post is very confusing. 960PRO is a PCIe NVMe drive, maybe you are talking about 860PRO, since Samsung SATA drives are 8xx? Another thing, Blackmagic Speed Test is just a sequential bandwidth indicator, don't use it for benchmarking.

Any decent NVMe drive like a 970 EVO Plus will give you less latency than a SATA drive, better QD4Kb speeds and a lot more bandwidth. Even with a no-name PCIe adaptor you will have ~1450MB/s throughput.

 

[ObiJuan2080]

Any decent NVMe drive like a 970 EVO Plus will give you less latency than a SATA drive, better QD4Kb speeds and a lot more bandwidth. Even with a no-name PCIe adaptor you will have ~1450MB/s throughput.

I’m a videographer using my Sony a7riii to record video (hoping for a7siii if Sony gets off their asses). That’s good to know as I’m planning to make the single Samsung 970 EVO PRO NVMe as my boot drive and to run applications. While having a huge OWC SATA SSD as a scratch disk for media.

Thank you.

 

[tsialex]

I’m a videographer using my Sony a7riii to record video (hoping for a7siii if Sony gets off their asses). That’s good to know as I’m planning to make the single Samsung 970 EVO PRO NVMe as my boot drive and to run applications. While having a huge OWC SATA SSD as a scratch disk for media.

Thank you.

Don't make sense a fast drive for OS and apps, it's your scratch disk that needs to be fast. It's where you are working. This is paramount for video work.

BTW, most people here have very bad experiences with OWC SSDs. I'm one that would never buy anything there that I can find elsewhere.

 

[bosDAW]

Yes, you are correct. I meant to say 860PRO (it was a late night; will edit this), so I apologize.

The point of confusion for me is why the 860PRO/internal bay gives the same real-world performance as the 860PRO/PCIe. Disregarding the BlackMagic tests, I would still expect the PCIe connection to be faster, but I saw no improvement when actually using the software. So I am wondering why. Stated another way, if I have everything set up properly and see no difference in software performance, does this mean that the slowdown occurs because of the software programming rather than the SSD configuration? I would have expected to see something different between the two setups, but I would not be able to tell internal vs PCIe based solely on how the software was working. If the SSD is not the slowest link in the chain, then it seems pointless to upgrade to NVMe. But I feel like I am missing something here.

 

[tsialex]

Yes, you are correct. I meant to say 860PRO (will edit this), so I apologize.

The point of confusion for me is why the 860PRO/internal bay gives the same real-world performance as the 860PRO/PCIe. Disregarding the BlackMagic tests, I would still expect the PCIe connection to be faster, but I saw no improvement when actually using the software. So I am wondering why. Stated another way, if I have everything set up properly and see no difference in software performance, does this mean that the slowdown occurs because of the software programming rather than the SSD configuration? I would have expected to see something different in the two setups, but I would not be able to tell internal bay vs PCIe based solely on how the software was performing. If the SSD is not the slowest link in the chain, then it seems pointless to upgrade to NVMe. But I feel like I am missing something here.

860PRO = SATA
960PRO = PCIe NVMe

NVMe drives have less latency, more IOPs, more sequential and random bandwidth, but if your workflow is not disk bound, you won't see any real life benefit.

NVMe shines with sequential transfers, usually 6 to 10 times better than SATA, but if your workflow is basically random 4k disk access with small files and not disk bound, you will only see small improvements.

 

[bosDAW]

Ok, so maybe what you are saying is that unless I have 50+ tracks all streaming audio data, I would not notice much difference between between 860PRO SATA and PCIe NVMe. And this is probably why I do not see any difference with the 860PRO in the internal bay (SATA2) vs on the PCIe card.

I suppose that sample streaming, even with a large number of total tracks/instruments, may only be accessing what is still considered random as opposed to sequential transfers. For example, if I have 25 instrument tracks, this is a lot of audio. Even though the total sample data being streamed may be 10GB, the individual sample files may be relatively small (maybe 500MB for one instrument, 200MB for another, 800MB for another, etc). Is this still considered to be random because there are 25 sample files being streamed as opposed to a single, huge file?

 

[tsialex]

Ok, so maybe what you are saying is that unless I have 50+ tracks all streaming audio data, I would not notice much difference between between 860PRO SATA and PCIe NVMe. And this is probably why I do not see any difference with the 860PRO in the internal bay (SATA2) vs on the PCIe card.

I suppose that sample streaming, even with a large number of total tracks/instruments, may only be accessing what is still considered random as opposed to sequential transfers. For example, if I have 25 instrument tracks, this is a lot of audio. Even though the total sample data being streamed may be 10GB, the individual sample files may be relatively small (maybe 500MB for one instrument, 200MB for another, 800MB for another, etc). Is this still considered to be random because there are 25 sample files being streamed as opposed to a single, huge file?

If the instruments are not sequentially saved one after the other and the access to it is not in the same sequence as it's stored on the disk, it's random access.

PCIe SATA cards just give your more throughput, PCIe AHCI and NVMe give you less latency, more IOPs, more bandwidth and more throughput.

We as humans usually measure performance as the time that something takes to be complete, basically latency and throughput. Real disk benchmarking involves latency, bandwidth, IOPs and throughput. Blackmagic shows you just throughput.

Use amorphous or something similar to do real disk benchmarking.

AmorphousDiskMark for macOS - measures storage read/write performance

 

[bosDAW]

Ok, that makes more sense. Sample libraries consist of a series of sample files organized by instrument, playing style, etc. but any combination of instruments may be loaded in a project such that these files will never be sequential. Or even if I wanted to manually group them all together in a new location for a particular project, they are still individual files playing in parallel and at different times. So that means even if one of these files is itself large (1GB), as long as there are two or more files being requested at any point, it is random access and gives about the same performance. Is that the right idea? So really, whether one single file or many smaller files, they would have to be ordered one after the other in exactly the same linear sequence as they are used in the project.

Forgive me if this is a stupid follow up, but then is NVMe really only useful for doing something like video editing? As an analogy, if I had a video project open with 3 different video clips playing at the same time, would this also be considered random access? Obviously this makes no sense for video as there is no such equivalent to "mixing" tracks of video as you do with audio. But if the video clips were saved on a scratch disk in order of "1, 2, 3" and used in a linear sequence during playback of "1 followed by 2 followed by 3...", this would be sequential access. If the order during playback were then changed to "1 followed by 3 followed by 2", this would now be random access. Any further edits to any of these clips would further change the order. So the biggest advantage might be in opening/copying large files rather than editing them. Am I understanding this correctly?

 

[tsialex]

Ok, that makes more sense. Sample libraries consist of a series of sample files organized by instrument, playing style, etc. but any combination of instruments may be loaded in a project such that these files will never be sequential. Or even if I wanted to manually group them all together in a new location for a particular project, they are still individual files playing in parallel and at different times. So that means even if one of these files is itself large (1GB), as long as there are two or more files being requested at any point, it is random access and gives about the same performance. Is that the right idea? So really, whether one single file or many smaller files, they would have to be ordered one after the other in exactly the same linear sequence as they are used in the project.

Forgive me if this is a stupid follow up, but then is NVMe really only useful for doing something like video editing? As an analogy, if I had a video project open with 3 different video clips playing at the same time, would this also be considered random access? Obviously this makes no sense for video as there is no such equivalent to "mixing" tracks of video as you do with audio. But if the video clips were saved on a scratch disk in order of "1, 2, 3" and used in a linear sequence during playback of "1 followed by 2 followed by 3...", this would be sequential access. If the order during playback were then changed to "1 followed by 3 followed by 2", this would now be random access. Any further edits to any of these clips would further change the order. So the biggest advantage might be in opening/copying large files rather than editing them. Am I understanding this correctly?

Random read/write is greatly affected on magnetic media, SSDs not so, since SSDs have different way of storing files, 2 files saved at the same time can be on totally different areas on the NAND memory.

If your application is not multithread and reads data with just one thread, you won't benefit from more IOPs of a good NVMe drive, just the less latency will be notable.

NVMe benefits applications that are storage bound. Databases, video editing and storage are the usual applications that benefit greatly from the greater NVMe IOPs/latency/throughput.

Install Amorphous, it's free and easy to see IOPs/throughput, easy to see where NVMe shines.

 

[bosDAW]

Thank you tsialex, and I will check out Amorphous.

The digital audio software is multithread (as opposed to the standalone instrument apps, which I am not sure), so maybe this is a very poor type of comparison for test purposes. Maybe the biggest difference would be seen only in the initial loading time required for an entire project that has multiple instances of a virtual instrument with multiple tracks each. So for example, a large project with several GB of sample data being accessed that takes 25s to open, it would load almost right away. But within the virtual instrument itself (within the DAW software for a project), loading different presets, making changes, etc. probably would make no difference at all.

Is an there an easy way to test to see how demanding the software is in terms of IOPs/throughput at a given workload to compare to the Amorphous results? It would be great to see a few numbers that tell me if the software is asking more of the SSD than it can deliver. Or is it possible that the software or even CPU are hitting a wall long before the SSD performance is anywhere near max? I suppose I could just try it to see if it makes any difference. But based on what you have said, it seems like I probably would not notice any difference except in the time required to open a very large project.

Why then is NVMe so popular with gamers? I would not think a video game is storage bound, certainly not to the same extent as a large video archive. Or is that simply a matter of NVMe being the new standard along with the fact that prices are almost the same?

 

[tsialex]

Thank you tsialex, and I will check out Amorphous.

The digital audio software is multithread (as opposed to the standalone instrument apps, which I am not sure), so maybe this is a very poor type of comparison for test purposes. Maybe the biggest difference would be seen only in the initial loading time required for an entire project that has multiple instances of a virtual instrument with multiple tracks each. So for example, a large project with several GB of sample data being accessed that takes 25s to open, it would load almost right away. But within the virtual instrument itself (within the DAW software for a project), loading different presets, making changes, etc. probably would make no difference at all.

Is an there an easy way to test to see how demanding the software is in terms of IOPs/throughput at a given workload to compare to the Amorphous results? It would be great to see a few numbers that tell me if the software is asking more of the SSD than it can deliver. Or is it possible that the software or even CPU are hitting a wall long before the SSD performance is anywhere near max? I suppose I could just try it to see if it makes any difference. But based on what you have said, it seems like I probably would not notice any difference except in the time required to open a very large project.

Why then is NVMe so popular with gamers? I would not think a video game is storage bound, certainly not to the same extent as a large video archive. Or is that simply a matter of NVMe being the new standard along with the fact that prices are almost the same?

Multithreaded software can have disk operations single threaded or have badly optimised queues. Optimization for hard disk drives are totally different from SSDs. PCIe SSDs, principally NVMe, have different optimisation from SATA. An application optimised for hard disks will perform sub-optimally with a NVMe drive.

Use Activity monitor to see CPU/DISK/Memory instantaneous usage.

Gamers like what is newer/faster/have bigger benchmark numbers to show others. NVMe drives optimised for the gaming market are not the optimal performance drives, far from it.

 

[bosDAW]

I will check it out and see if I have any new information for you. If it is helpful/interesting, this review was the only specific resource I was able to find (and maybe it does a better job at explaining some of the more relevant details):

A Comparison of Storage Mediums for Sample-Based Plugin Load Times in Pro Audio Applications - PCAudioLabs

A Comparison of Storage Mediums for Sample-Based Plugin Load Times in Pro Audio Applications - a White Paper by OBEDIA PCAudioLabs

pcaudiolabs.com

The article states that NVMe clearly outperforms the other SSDs in the test. While correct according to the reported numbers, the differences are not as significant as I would have expected. In most cases of sample loading, they show the SSD (Samsung 860Pro) as actually being pretty close to the fastest NVMe (Intel Optane 905P PCIe NVMe).

The 320 instrument-autoload of EastWest (91GB) was 8s SSD vs 6.7s NVMe. The 320 instrument-autoload of HALion (7GB) was 30s SSD vs 16s NVMe; this is a much bigger disparity but it is also the smallest file size yet took longer for all drives. And in one case (third figure for "EastWest Strings Gold Patch Load Time" for a 1155MB file), the 860Pro is actually faster.

I do not know if these numbers are accurate as the units are not even labeled correctly on the x-axis (e.g. "0.5min" means [0.5min * 60s/min = 30s] and not 50s as the writer seems to mean. In any case, if these data make sense to you in terms of the types of files being loaded for audio and you would say it is a fair representation, it seems that NVMe does not offer such a great improvement. And, depending on the software used, it may be slower as you suggested earlier.

I hope you do not find this to be too boring! Asking the same questions on a music forum simply did not attract as many replies from users with a more technical background.

Quick EDIT: looking through the actual sample libraries for EastWest, a particular instrument loads samples from one or more nested subfolders. The subfolders organize sample data into groups of about 50-100 files at the lowest level, but the individual files are typically only 500-1000K in size. Moving up one level, a parent folder may contain anywhere from one subfolder (~20MB) up to 50 subfolders (~1GB), and moving up again this may continue up to 10GB+. So it seems that this would be exactly as what you described earlier, and that an NVMe would serve no purpose here. Other libraries use proprietary formats that encapsulate sample data into single .db or .ufs files that may be 50GB or larger, but I have no idea how these are constructed. Presumably, there would be some similar file structure.

At least, I feel like I am getting much closer to a definitive answer!

 

[bosDAW]

I actually managed to dig up an article written by an engineer who did a similar type of comparison of loading time for SSD vs NVMe, except it is very thorough and very detailed, with measurements of throughput and IOPs, and comparing CPU usage with disk usage at different times far better than anything I could do myself (let me know if you want me to post the link). Basically, the finding was that the initial loading time of the GUI was entirely CPU dependent and did not change by much between drives (~4% difference) and with relatively little difference with single vs multicore threading. The NVMe improved sample loading-times, but only by ~16%. QD rarely exceeded 1, and mean block size during disk reads was ~118K.

I may be confusing a few different things here, so please excuse my ignorance, but maximum bandwidth will depend on the ideal combination of block and batch size for a particular type of SSD. So depending on how the data is structured and whether the software is optimized, performance will vary. Generally speaking, there is much less difference between SSD and and SSD NVMe at very small block size and very small batch size (???) such that smaller files with random access do not achieve anywhere near max performance for NVMe (does this make any sense???) and may even be close to regular SSD. Even if I have this completely wrong...

1. Is it fair to say that NVMe will almost always be [at least slightly] faster than SSD, even if not optimized for the best possible performance? Or is there a case where you would say that an SSD would actually be preferred and give better results? Would music production, sample loading, and sample streaming be one of these cases?

2. If the differences are unclear/marginal, is there any reason to avoid NVMe (compatibility, reliability, heat, etc)? Or does it just come down to whether the cost is justified for what may be minimal improvement.

3. lastly, because this may depend a lot on how a specific instrument/software is written, is there really any way to tell other than to get the hardware and just test it out myself?

 

[tsialex]

I actually managed to dig up an article written by an engineer who did a similar type of comparison of loading time for SSD vs NVMe, except it is very thorough and very detailed, with measurements of throughput and IOPs, and comparing CPU usage with disk usage at different times far better than anything I could do myself (let me know if you want me to post the link). Basically, the finding was that the initial loading time of the GUI was entirely CPU dependent and did not change by much between drives (~4% difference) and with relatively little difference with single vs multicore threading. The NVMe improved sample loading-times, but only by ~16%. QD rarely exceeded 1, and mean block size during disk reads was ~118K.

I may be confusing a few different things here, so please excuse my ignorance, but maximum bandwidth will depend on the ideal combination of block and batch size for a particular type of SSD. So depending on how the data is structured and whether the software is optimized, performance will vary. Generally speaking, there is much less difference between SSD and and SSD NVMe at very small block size and very small batch size (???) such that smaller files with random access do not achieve anywhere near max performance for NVMe (does this make any sense???) and may even be close to regular SSD. Even if I have this completely wrong...

1. Is it fair to say that NVMe will almost always be [at least slightly] faster than SSD, even if not optimized for the best possible performance? Or is there a case where you would say that an SSD would actually be preferred and give better results? Would music production, sample loading, and sample streaming be one of these cases?

2. If the differences are unclear/marginal, is there any disadvantage to NVMe (compatibility, reliability, heat, etc)? Or does it just come down to whether the cost is justified for what may be only ~16% improvement.

Small file size with single queue and sequential requests are the very worst use case for NVMe technology and you'll only see the latency benefits of the PCIe NVMe here. NVMe real benefits, like massive parallel IOPs with giant queues and multiple simultaneous requests, are not being used at all with single thread/single queue/sequential requests of data. NVMe is massively parallel and accepts multiple simultaneous requests.

PCIe drives have more performance than SATA drives even for the worst usage case. Latency is always greater with SATA drives.

SATA drives are obsolete for more than two years, no new developments of performance drives are being done with SATA, just bigger, but slower, drives. It's a mature technology and being phased out, most motherboards being released are eliminating SATA altogether. For example, when Apple designed the MP5,1, they made available all the 6 SATA ports of the Intel Tylersburg platform, while with MP7,1 Apple made available just two of the 14 possible SATA ports of the Lewisburg platform. Other workstation and high-end motherboard manufacturers are doing the same, SATA is already dead.

You don't optimise a technology just for your worst use case, but in the future with even less latency from faster controllers/bigger density of NAND banks, small file size being accessed from a single queue and sequential request will get more performance, but only changes in software, moving from single queue and sequential requests to multiple queue and parallel requests of data will really bring performance.

 

[bosDAW]

Small file size with single queue and sequential requests are the very worst case for NVMe performance and you'll only see the latency benefits of the PCIe NVMe technology here.

So this means that NVMe would give a performance advantage, it is just not making real use of the technology?

You don't optimise a technology just for your worst use case, but in the future with even less latency from faster controllers/bigger density of NAND banks, small file size being accessed from a single queue and sequential request will get more performance, but only changes in software, moving from single queue and sequential requests to multiple queue and parallel requests of data will really bring performance.

Are you speaking generally as to why SATA is dead, or are you suggesting that [specifically for me], the only real difference would be seen with if improvements were made to the software?

Bottom line: yes, NVMe is faster; yes, I could upgrade and I would see "some" improvement. But unless the software I am using catches up with NVMe, 98% of the technology is wasted. Is that a fair characterization?

 

[tsialex]

So this means that NVMe would give a performance advantage, it is just not making real use of the technology?


Are you speaking generally as to why SATA is dead, or are you suggesting that [specifically for me], the only real difference would be seen with if improvements were made to the software?

Bottom line: yes, NVMe is faster; yes, I could upgrade and I would see "some" improvement. But unless the software I am using catches up with NVMe, 98% of the technology is wasted. Is that a fair characterization?

NVMe has a lot less latency than SATA, you will see several performance improvements. Your Mac will be faster, even if your main application won't benefit at all from it.

SATA is dead from every point of view. Besides for very specific type of servers, no manufacturer is implementing all the native SATA ports that the Intel Lewisburg platform have. Desktop variant of the same platforms never offered this massive quantity of SATA ports. No new performance SATA drives were released in the last two years, only bigger and a lot slower drivers - Samsung QVO line. BTW, QVO drives have serious compatibility problems with MP5,1.

Single threaded software don't benefit at all from the now massive multicore processors available, the exactly same is applicable to NVMe.

 

[bosDAW]

So there is a benefit of decreased latency (which is still a good thing!), it just doesn't translate into much even on the best modern systems. For my 2010 5,1 adding NVMe may help very slightly at very specific times with some software sometimes but do zero the rest of time. Is that the obvious conclusion?


Typically in a DAW, you would open several instances of a virtual instrument to take advantage of multithreading for that very reason. For example, rather than have a single instance of a software plugin with 16 channels of audio, you might split this into 2 instances with 8 channels each, or 4 of 4. I guess you could extend this to 16 or 64 instruments with 1 channel each, but you would probably max out CPU long before even SATAII SSD.

Or... if parallelism were like lanes on a highway and QD the number of cars, using an NVMe would be like building a superhighway with 100 lanes for only one or two cars. It would be silly to think that you would arrive at your destination any faster, and the only thing you may notice is that there is never a delay getting on/off or maybe passing through any EZ Pass/tolls.

Maybe this is a terrible analogy, but just let me know if I have the first paragraph correct. Thank you tsialex!

 

[tsialex]

So there is a benefit of decreased latency (which is still a good thing!), it just doesn't translate into much even on the best modern systems. For my 2010 5,1 adding NVMe may help very slightly at very specific times with some software sometimes but do zero the rest of time. Is that the obvious conclusion?

Your Mac overall performance is greatly improved, even if you use just one application at a time, your SO have a massive quantity of little apps/tools accessing the disk all the time, concurrently. With NVMe you don't have to wait your time in the disk access queue, you just do the request and get it back.

Your multilane highway analogy makes perfect sense for a single queue/sequential request app, but not for the whole SO.

In the past you had to use multiple disks to optimise request queues, NVMe basically eliminated the need for that. People still use scratch disks for different motives now, like the greater cost of bigger drives and the wear-out that NAND cells have with massive write cycles - it's better to have different drives for storage and scratch, you replace the scratch disk easily when the wear out starts down the road.

While your main app is not optimised for NVMe, macOS already is for some releases and is performing badly with older tech. A Mac with just HDDs or Fusion, is a nightmare running current macOS.

 

[bosDAW]

By "SO" do you mean OS or stack overflow or something else? Does that mean an NVMe is better suited for a system drive as opposed to a sample/storage drive? Or am I just confused here?

 

[tsialex]

By "SO" do you mean OS or stack overflow or something else? Does that mean an NVMe is better suited for a system drive as opposed to a sample/storage drive? Or am I just confused here?

OS, it's the inverse in my native language and sometimes I write it without noticing.

Except for archival and backup, nothing beats price per terabyte of hard disks, NVMe is better than SATA every way/metric that you look at it.

Don't make any sense buying a Samsung 860PRO drive nowadays to use with a Mac Pro, while prices on Amazon-US are affected by COVID-19 shortages, today you get a 970PRO with massive performance advantages for $125 less than a 860PRO. Remember that series 8xx of Samsung SSDs are SATA, while 9xx are PCIe.

Even for samples storage, a NVMe drive will perform better than a SATA drive.

 

[bosDAW]

Perfect. Thanks for being so patient with all the questions so far!

If I wanted to give it a shot, is my choice of the Sonnet M.2 4x4 PCIe card good? It is more expensive but seems to be well regarded.

I was also not so sure about the 970PRO vs 970EVO plus. It seems like everyone automatically goes to the PRO, but the EVO plus offers better performance. Yes, the EVO plus has a shorter lifespan, but I would think that long before the drive gets down to even 75%, you would probably have replaced it with something newer. It would probably still last for 10+ years. Price savings is ~$120, and the EVO plus also has 2TB option. Do you think there is any real difference?

 

[tsialex]

Perfect. Thanks for being so patient with all the questions so far!

If I wanted to give it a shot, is my choice of the Sonnet M.2 4x4 PCIe card good? It is more expensive but seems to be well regarded.

I was also not so sure about the 970PRO vs 970EVO plus. It seems like everyone automatically goes to the PRO, but the EVO plus offers better performance. Yes, the EVO plus has a shorter lifespan, but I would think that long before the drive gets down to even 75%, you would probably have replaced it with something newer. It would probably still last for 10+ years. Price savings is ~$120, and the EVO plus also has 2TB option. Do you think there is any real difference?

Sonnet M.2 4x4 is not a card made for MP5,1, seems it was designed for MP7,1 internal measures. It barely fits on a MP5,1 and you have to remove the PCIe fan every time you need to install or remove it. Another serious problems, it won't boot Windows and you have to hack it to use double sided blades. HighPoint SSD7101A-1 it's a much better card overall for a MP5,1.

Only instantaneous performance of 970EVO+ is better, after the SLC cache is full and you have the real speeds of the TLC NAND, the write throughput falls vertiginously. For reading bound applications, don't matter. 970PRO MLC NAND is insuperable, buy a 970PRO for a scratch disk, 970EVO+ for storage.

 

[bosDAW]

I would not be concerned about booting Windows. I actually asked Sonnet if it would work with my system and they said yes. No mention of a size problem, but they did say I could also return it for a full refund. I will have to do a search to read more about it and compare to the HighPoint. Aside from the size issue, would you consider the HighPoint to be better quality, or maybe just a better value? I am also still running 10.13.6 and know the Sonnet will work.

 

[tsialex]

I would not be concerned about booting Windows. I actually asked Sonnet if it would work with my system and they said yes. No mention of a size problem, but they did say I could also return it for a full refund. I will have to do a search to read more about it and compare to the HighPoint. Aside from the size issue, would you consider the HighPoint to be better quality, or maybe just a better value? I am also still running 10.13.6 and know the Sonnet will work.

If you have to workaround and remove the PCIe fan every time, it fails the fit test for me. Read the posts about it, practically only people with MP7,1 are satisfied with the M.2 4x4.

I have a HighPoint SSD7101A-1 v1.01 and installed SSD7101A-1 v2.00, SSD7103 and Sonnet M.2 4x4 for friends, the HighPoint PCBs are always better routed, PCB has better quality, the shroud/heatsink of HighPoint cards are a lot heavier than the one from Sonnet and the HighPoint cards accepts double sided blades without any hacks.

4TB blades arriving soon are double sided, btw.