Non-Motherboard NVMe Installation

[cgrafx]

Nice overview. But by SSD I assume you mean SATA SSD, and by M.2 I assume you mean NVMe SSD. My understanding is that, for example, a SATA M.2 drive will perform no better than a 2.5" SATA SSD.

Yes, SATA SSD and M.2 NVMe (which is an extension of the PCI bus)

From Wikipedia

Legacy SATA
Used for SATA SSDs, and interfaced through the AHCI driver and legacy SATA 3.0 (6 Gbit/s) port exposed through the M.2 connector.

PCI Express using AHCI
Used for PCI Express SSDs and interfaced through the AHCI driver and provided PCI Express lanes, providing backward compatibility with widespread SATA support in operating systems at the cost of performance. AHCI was developed when the purpose of a host bus adapter (HBA) in a system was to connect the CPU/memory subsystem with a much slower storage subsystem based on rotating magnetic media; as a result, AHCI has some inherent inefficiencies when applied to SSD devices, which behave much more like RAM than like spinning media.

PCI Express using NVMe
Used for PCI Express SSDs and interfaced through the NVMe driver and provided PCI Express lanes, as a high-performance and scalable host controller interface designed and optimized especially for interfacing with PCI Express SSDs. NVMe has been designed from the ground up, capitalizing on the low latency and parallelism of PCI Express SSDs, and complementing the parallelism of contemporary CPUs, platforms and applications. At a high level, primary advantages of NVMe over AHCI relate to NVMe's ability to exploit parallelism in host hardware and software, based on its design advantages that include data transfers with fewer stages, greater depth of command queues, and more efficient interrupt processing.


As an example of Read/Write speed

mSata/SATA
Samsung 860 EVO 550MB/s and 520MB/s

M.2
Samsung 970 EVO 3500MB/s and 2500MB/s

So M.2 is 5-6x the speed of mSATA/SATA interfaces

[John Ludlow]

Good insights, John. I think very much like you do, and I have no database experience.

Now, to find out if my sockets and SSDs are ver. 3 or ver. 4... Any thoughts on how to suss that? Not that I'm going to do anything about it, but I like to know.

You think like me? Oh... well, hang in there. And it's not too late Dave. You too can acquire database experience.

Yeah, I'm not sure it's always a good thing. My friends who always buy the cheapest thing that for sure meets their needs don't seem to have fewer problems than I do (although they upgrade more often...).

When I wanted to know, I looked at the back of my motherboard box. You could try that. Or - check your MB docs. It'll be there for sure. Or, Google your MB model and read the specs on a sale site. They'll always have them, I think, cuz geeks like us shop for specs.

Or - you could take a chance and check your NVMe boxes/docs. If they're ver. 4 then your MB sockets must be ver. 4 too - since it works at all.

The ver. 4 NVMe specs are just frightening. Read/Write speeds on a Samsung 980 Pro PCIe 4.0 NVMe M.2 are 7GB/5GB per second. Seven billion bytes per second average read speed! What application could possibly require that? Hmmmm... a really big database, for one. Obviously, I want one. They run hot though. You need a heat sink for them.

[Dave Labrecque]

Yes, SATA SSD and M.2 NVMe (which is an extension of the PCI bus)

From Wikipedia

Legacy SATA
Used for SATA SSDs, and interfaced through the AHCI driver and legacy SATA 3.0 (6 Gbit/s) port exposed through the M.2 connector.

PCI Express using AHCI
Used for PCI Express SSDs and interfaced through the AHCI driver and provided PCI Express lanes, providing backward compatibility with widespread SATA support in operating systems at the cost of performance. AHCI was developed when the purpose of a host bus adapter (HBA) in a system was to connect the CPU/memory subsystem with a much slower storage subsystem based on rotating magnetic media; as a result, AHCI has some inherent inefficiencies when applied to SSD devices, which behave much more like RAM than like spinning media.

PCI Express using NVMe
Used for PCI Express SSDs and interfaced through the NVMe driver and provided PCI Express lanes, as a high-performance and scalable host controller interface designed and optimized especially for interfacing with PCI Express SSDs. NVMe has been designed from the ground up, capitalizing on the low latency and parallelism of PCI Express SSDs, and complementing the parallelism of contemporary CPUs, platforms and applications. At a high level, primary advantages of NVMe over AHCI relate to NVMe's ability to exploit parallelism in host hardware and software, based on its design advantages that include data transfers with fewer stages, greater depth of command queues, and more efficient interrupt processing.


As an example of Read/Write speed

mSata/SATA
Samsung 860 EVO 550MB/s and 520MB/s

M.2
Samsung 970 EVO 3500MB/s and 2500MB/s

So M.2 is 5-6x the speed of mSATA/SATA interfaces

There it is.

I have two EVO Plus NVMe's. What I've discovered in the real world, though, is that those numbers are only gotten close to when transferring big, single files. Lots of little files just kills the throughput. Unless I'm doing something wrong, which is likely.

[Dave Labrecque]

Yeah, I guess there's always looking at specs. Why didn't I think of that?

It'd be fun to calculate how many playback tracks you could get with that kind of throughput. I'm no good with long division, though, so...

[John Ludlow]

Yeah, I guess there's always looking at specs. Why didn't I think of that?

It'd be fun to calculate how many playback tracks you could get with that kind of throughput. I'm no good with long division, though, so...

7,000,000,000 / ((44,100*2) *2) = 39,682 simultaneous stereo tracks and change I believe (at 44.1K samples per second, 16 bits each). So, you could probably overcome the lack of peak speed issue. Dave, I'm not good at long division either. But - I found a calculator built right into Windows.

[Dave Labrecque]

7,000,000,000 / ((44,100*2) *2) = 39,682 simultaneous stereo tracks and change I believe (at 44.1K samples per second, 16 bits each). So, you could probably overcome the lack of peak speed issue. Dave, I'm not good at long division either. But - I found a calculator built right into Windows.

LOL. I get 7,000,000,000 B/sec / (10,500,000 B/min / 60 sec/min) = 40,000 stereo tracks. Yours seems more precise, though. Call me conservative, but I think I"ll play it safe and try to keep it below 39,500 tracks or so.

I did not know that two times the sample rate is the data rate for a stream in bytes. How does that work? I know it's probably very simple, but I didn't study any of this stuff in school.

[John Ludlow]

LOL. I get 7,000,000,000 B/sec / (10,500,000 B/min / 60 sec/min) = 40,000 stereo tracks. Yours seems more precise, though. Call me conservative, but I think I"ll play it safe and try to keep it below 39,500 tracks or so.

I did not know that two times the sample rate is the data rate for a stream in bytes. How does that work? I know it's probably very simple, but I didn't study any of this stuff in school.

Go ahead. Wind me up.

In computers there are 8 bits to the byte. By extension, sixteen bits is equal to two bytes. So, 44,100 samples per second times 2 bytes per sample equals 88,200 bytes per second. But it's stereo, so you have to multiply that by two, which gives you 176,400 bytes read per second, per stereo track (at 44.1K, 16). You divide that into a max read capability of 7 GB per second for the drive (running full tilt boogey, rather than the way it runs on your machine for small files) or 7,000,000,000/176,400. And that results in a calculated potential capability of 39,682.53968253968 (with due credit given to Windows calculator...) continuous simultaneous tracks read. I figure: cut that in half just to thwart Murphy.

If you were using 24 bit samples, that would be 3 bytes (8+8+8) per sample instead of 2 - but still 2 tracks. Did you ever wonder why they chose '16' and '24' bits for sample size, rather than something sanely divisible by 10? That's the reason. If you had previously recorded those 39,000+ tracks at a higher sample rate, then you'd have to adjust the samples per second for that.

No matter how you slice it though - it's total overkill. But, that does not deter database guys like us. Plus, if you use sampler soft synths, it takes some throughput to move each synth note event off the disk in realtime. So, maybe you subtract a track or two for that - depending upon the number of instruments. And those MIDI samples are quite a bit larger, although the number of samples read per second is much smaller. But no matter how you slice it, it's still total overkill for this application. Better too much than too little though (I tell myself).

Bonus:

Did you know that you can copy simple algebraic equations into Windows calculator? Like, if you copy and paste: "7,000,000,000/176,400 =" (without the quotes) it will do the division automatically without you having to press any keys. It's not smart enough to parse parens though. So, it will get "7,000,000,000 / ((44,100*2) *2) =" wrong.

[Dave Labrecque]

Go ahead. Wind me up.

In computers there are 8 bits to the byte. By extension, sixteen bits is equal to two bytes. So, 44,100 samples per second times 2 bytes per sample equals 88,200 bytes per second. But it's stereo, so you have to multiply that by two, which gives you 176,400 bytes read per second, per stereo track (at 44.1K, 16). You divide that into a max read capability of 7 GB per second for the drive (running full tilt boogey, rather than the way it runs on your machine for small files) or 7,000,000,000/176,400. And that results in a calculated potential capability of 39,682.53968253968 (with due credit given to Windows calculator...) continuous simultaneous tracks read. I figure: cut that in half just to thwart Murphy.

If you were using 24 bit samples, that would be 3 bytes (8+8+8) per sample instead of 2 - but still 2 tracks. Did you ever wonder why they chose '16' and '24' bits for sample size, rather than something sanely divisible by 10? That's the reason. If you had previously recorded those 39,000+ tracks at a higher sample rate, then you'd have to adjust the samples per second for that.

No matter how you slice it though - it's total overkill. But, that does not deter database guys like us. Plus, if you use sampler soft synths, it takes some throughput to move each synth note event off the disk in realtime. So, maybe you subtract a track or two for that - depending upon the number of instruments. And those MIDI samples are quite a bit larger, although the number of samples read per second is much smaller. But no matter how you slice it, it's still total overkill for this application. Better too much than too little though (I tell myself).

Bonus:

Did you know that you can copy simple algebraic equations into Windows calculator? Like, if you copy and paste: "7,000,000,000/176,400 =" (without the quotes) it will do the division automatically without you having to press any keys. It's not smart enough to parse parens though. So, it will get "7,000,000,000 / ((44,100*2) *2) =" wrong.

Interesting stuff, John. It's amazing how much of the basic digital stuff I just am not hip to. Thanks for the lesson(s).

[John Ludlow]

Interesting stuff, John. It's amazing how much of the basic digital stuff I just am not hip to. Thanks for the lesson(s).

I think so too (that it's interesting...). I remember distinctly when I finally realized what they were doing. Clever guys. So much of world understanding is just knowledge away, you know? That is - it isn't unfathomable or beyond our ordinary minds to grasp. The basic concepts are often simple. But, someone very clever twisted their perception of the issues around in a brand new way, thought of it for the first time, fleshed it out, and realized it in the world. Imagining it the first time. That was the tough bit.

[John Ludlow]

You know, these days we are often presented with numbers with a whole lot of zeros. It's hard to put them into a framework we can grasp. I just thought of a way to (hopefully) put the scope of NVMe throughput into focus.

Those of us, who are old enough, remember what an encyclopedia, in paper volumes, looks like. What a volume weighs in the hand. We visited the library to use their volumes to research our school reports. How long would it take you to read the entire set of encyclopedia, do you think?

Well, Microsoft's Encyclopedia Encarta 2005 contains about 26 million words, comprised of about 40 million characters (according to: https://en.wikipedia.org/wiki/Wikipe...ze_comparisons). As straight text, each alphabet character can be represented by 1 byte. That new Samsung ver. 4 NVMe drive can read those words in their entirety, the entire encyclopedia, 175 times every second (seven billion / 40 million). NVMe is capable of reading an entire encyclopedia 175 times every second. That's how fast it is.

Some may point out that these days each character is almost always graphical, and is made of dots so that it can have lots of extra things associated with it like font and type size and color - and all those things increase the storage size of each. And an encyclopedia has pictures and charts that are not comprised of letters of the alphabet. And that's all true. But, if you rendered just the words of Encyclopedia Encarta 2005 in a text editor - each character would take exactly 1 byte, and there are 40 million of them (give or take). Work with me here.