# Sample streaming speeds, Accelsior 4M2 vs Glyph Atom RAID SSD



## Dylan P (Feb 14, 2021)

Hi everyone

I recently purchased an Accelsior 4M2 NVMe SSD from which to stream samples. It claims transfer speeds up to 6000MB/s, which is in theory much faster than the previous drive I was using, a Glyph Atom USB-C External SSD, which claimed speeds of 960MB/s.

However, in practice, the difference in sample load times between the two drives was hardly noticeable. I was expecting load times to be, in theory, 6x as fast, but in reality, they were about 1.3x faster (load times for one project, for instance, went from 1’30" to about 1’10").

Why would this be? Might I be using the Accelsior wrong? Is there a limit to how fast the samples can load into a project? Is there any way I can speed up my load times?

FWIW the Accelsior was plugged directly into my MacPro via PCIe 3.0 in a RAID 0 configuration and the Glyph was connected via USB 3.1, also in a RAID 0 configuration. Both drives are 4TB.

Thanks in advance!
Dylan


----------



## JLKooistra (Feb 14, 2021)

First off: searching these forums will give you many and quite possibly better answers!
- you did not get the 6x improvement because project loading time is a 'real world' use case, the max transfer speed is usually based on sequential reading tests, using fixed size files, from special benchmark software.
- "samplers" / "romplers" (such as NI Kontakt, EW Play etc), read from disk using their own "read" logic which is not necessarily "sequential", where on top of that, sequential reading from 'real world' sample sets would look more like randon reads ("on disk file organization")
- the "project loading", depending on DAW, would also not be entirely be done sequential

- lots of other factors, again, search these forums?


----------



## Dylan P (Feb 16, 2021)

Thanks for the reply!

I realize I'm never going to experience the advertised 6000MB/s speeds, but I figured there would at least be a more noticeable difference going from 960MB/s to 6000MB/s...


----------



## David Kudell (Apr 19, 2021)

Dylan P said:


> Thanks for the reply!
> 
> I realize I'm never going to experience the advertised 6000MB/s speeds, but I figured there would at least be a more noticeable difference going from 960MB/s to 6000MB/s...


What are your disk speed times using black magic disk speed test? I also have the Glyph Atom Raid 900MB/second considering getting a Glyph Atom Pro (2800MB read times) for samples.


----------



## ChristianM (Apr 19, 2021)

- latency
- bus saturation
- bus repartition


----------



## Dylan P (Apr 20, 2021)

David Kudell said:


> What are your disk speed times using black magic disk speed test? I also have the Glyph Atom Raid 900MB/second considering getting a Glyph Atom Pro (2800MB read times) for samples.


Read/write for the Glyph is about 850/800MB/s with Black Magic. Can't remember the exact speeds for the Accelsior, but I do remember them being close to the advertised speeds. They just didn't translate to streaming samples to the DAW. I've since returned the Accelsior.

Would be interested what your experience is with the Glyph Atom Pro if you decide to get it


----------



## David Kudell (Apr 28, 2021)

Dylan P said:


> Read/write for the Glyph is about 850/800MB/s with Black Magic. Can't remember the exact speeds for the Accelsior, but I do remember them being close to the advertised speeds. They just didn't translate to streaming samples to the DAW. I've since returned the Accelsior.
> 
> Would be interested what your experience is with the Glyph Atom Pro if you decide to get it


Ok, I got the Glyph Atom Pro and moved all my samples to it. Most of my samples had been on the Atom RAID (850MB), with others on a regular Atom (475MB). 

I measured load time of a Cubase project from the Cubase project selection screen. The project was my theme "Valiant" which you can see on my YouTube channel. It has 114 tracks active, split between Kontakt and Sine player. All tracks are 1 articulation per instrument and one instrument per track (ie I don't do multi-timbral Kontakt's). The project load time with the old setup was 1min 30sec, and the load time with the Atom Pro was cut to 1min 14sec. I'd say meaningful but not massive difference.

However, with the old setup if I tried to hit play immediately when the project first appeared, there'd be some clicks and pops as it was still loading some more stuff, for up to another 30 seconds more. With the Atom Pro I can hit the space bar as soon as I see the tracks and it plays smoothly. Also, thanks to having so much SSD speed, I decided to cut Kontakt's preload buffer from the default of 60 down to 24, which has cut the RAM usage of those instruments immediately in half...kind of like getting double the RAM for free.

Is it worth the expense? Probably only if you're going to be working on a feature and want to avoid going the VEP route. With this setup, a huge project loads in just over a minute - so I can stick to a one cue per project workflow and still work quickly. Of course a new template with deactivated tracks loads pretty much instantly. I moved my active Cubase projects to my iMac Pro's speedy internal SSD, and that has cut save times down significantly as well. It's saving me from moving to a VEP workflow just yet. If I need to go that route I will, but for now trying to keep everything in one box.


----------



## colony nofi (Apr 29, 2021)

Yeah.

Load times for Kontakt will never get even close to saturating out the speed of the Glyph. (I have one of the 4TB Atom SSD's as well). 

As mentioned earlier, kontakt has its own unique way of reading files in which is incredibly inefficient. 

I've still never seen it read files above 200MB/s speed - off of ANY drive tested. Now, that doesn't mean you won't get some performance increases by using faster drives. The time it is actually reading is sped up, but it doesn't read all the time. It is opening a file, reading a bit, closing it repeatedly. So, there's a bunch of time between reads that isn't going to change no matter what speed the drive you are using. 

Kontakt is reading in small chunks of data - which makes comparing to Blackmagic Speed Test a waste of time. (You'll never see the speeds BMST gets with software reading small chuncks of data...
@tack did an incredible deep dive into all this a few years ago... he found it was reading chunks of 118KB (!!) meaning any meaningful drive benchmarking needs to be done with block sizes of aroune 128KB. So use ATTO or a similar benchmarking system.

His findings (copied from his paper which you can find here : 








Kontakt Patch Load Performance


Kontakt Patch Loads: NVMe vs SATA SSD (Windows) tl;dr I compared a 1TB Samsung 960 PRO NVMe with a 2TB Samsung 850 EVO SATA SSD and measured patch load times of a multi consisting of all section patches from Cinematic Studio Strings. The goal was to answer the question: will the added performanc...




docs.google.com





The initial patch load times (that delay until the GUI becomes responsive) is entirely CPU bound. There was no difference between the two drives.
Once the GUI was ready, samples loaded from disk into memory substantially faster with NVMe.
If you run a purged template and rely on streaming, there probably isn’t much difference in practice between these drives.
If you prefer to fully load your samples, NVMe will do it much faster (2x faster in my comparison).
But I haven’t found this necessary as even modest SATA SSDs have been able to keep up with streaming even from purged patches for me. (Note that my ASIO buffer is 512 samples. Smaller buffers might benefit from the lower latency of NVMe. A test for another day.)

Kontakt is not as efficient as it might be in loading samples, including some bizarre pathological filesystem behaviour on Windows at least.
But it’s also not quite as bad as I’d previously thought (and claimed on forums), so, mea culpa.

Indeed, its kind of a waste to look at most disk benchmarks as we don't have a true correlation figure between CPU use and drive speed to be able to predict what performance to expect - even knowing that we should be looking at 128KB block sizes. We *do* know that some drive performance increases generally show some load time improvements, but the delta between those improvements is massive. Using a drive capable of double 128KB reads (using a disk queue depth of 1 - which is how kontakt behaves most of the time) may only see you improve load times somewhere between 10-40%ish

I just found tack's interesting thread here on this regarding NVME vs SATA drives from 2018 which also links to his paper above.





NVMe vs SATA: Will it make Kontakt faster?


On the subject of the benefit of NVMe over a modest SATA SSD, specifically as it relates to Kontakt, I've commented here and elsewhere that: At least with Kontakt's compressed samples, NVMe is completely wasted. Decent SATA SSDs are too for that matter: I bottleneck my CPU decompressing the...




vi-control.net


----------



## ProfoundSilence (Apr 29, 2021)

@tack has saved me a ton of money, he's the reason I didn't bother going all out on some NVMe

he's also the reason I'm kind of at a loss for a future upgrade build.

Realistically - I want a 512gb machine, but I'm seeing that kontakt/disk read will eventually throttle me when using more mic signals. - And given my CPU loading, I'm thinking that upgrading to a faster 10-12 core will make more sense than a higher core count - this also makes me not really think a dual xeon would even be useful, as ultimately - I'd still be choked out by reading from disks. - Although this could simply afford me more plugins, in practice - as soon as kontakt shits out, it shits out... plugins after don't seem to matter because I hit that disk read wall first.


----------

