My continuing frustration with the speed of my NUC, leads me to consider Skull Canyon again.
My question is, whether someone has run Roon with a Skull Canyon with RAID 0 SSDs. It might seem rather extreme, but as database storage is the bottle neck for fun with Roon, I am wondering. Would only add €150 to the build if I buy small SSDs.
My library is not massive, only currently about 130k tracks. But I am very impatient, and find Roon boringly slow at present.
I recall @brian posting some time ago that there was little to no benefit to be had housing Roon’s database on a striped SSD. May be my recollection is entirely wrong though.
Did you have a read of @Janis findings ?
Thanks both. @ncpl, I saw that thread but it doesn’t mention RAID. I did find this one though: Suggested hardware which does. Looks like it makes a difference, from @janis’s findings at least. Just a matter of whether one wants to spend the money for a relatively small improvement.
@evand, I’m curious about @brian saying it wouldn’t make a difference. I’ll search, but if you find it yourself, please drop it in here. Ta.
I was generally against because the minor performance increase didn’t seem to justify doubling the probability of total data loss. But if you want to try, feel free.
We’re working on performance for the next major release, so things should get better on their own a bit too.
I would just buy one of the Samsung 950 and see how that is on its own.
A full shut down and re-boot with Win10 is about 20s on my i5 NUC. This is much quicker than anything else I have used.
If you find that you need more then add a second and rebuild testing the stripes.
I doubt you will need it.
Cheers
Striping across disks can improve write access (the downside is that it doubles the potential failure rate), but is that where the bottle neck is?
I don’t know but suspect that in normal use (browsing / searching) reading the DB is more bandwidth hungry that updating it. In which case mirroring across disks would be the way to go rather than striping.
@Brian, do you concur or do I have it wrong?
Next time round, try Linux! 
Random access write performance (followed closely by random access read performance) is the main bottleneck for Roon–or at least, it’s the main culprit in the worst experiences.
Whenever you get long pauses–during editing, metadata updates, imports, etc, we are almost always writing out a ton of records to the database, updating indices, etc. This is the reason why SSD is practically a requirement for Roon.
Most browsing/searching is served up out of RAM, so a faster disk won’t make focus or search faster. It will just make the RAM-based data structures load up a little bit faster at startup (who cares?).
Looking forward: We’re in the process of making new search indices–as search gets painful with large libraries. A lot of the core library/database management stuff has been re-organized to cut disk accesses by about 50% and reduce write amplification during certain pathological index-update patterns by over 90%.
I suspect that the performance work we’re doing will make a bigger difference than incremental hardware improvements.
Indeed…I will do so as soon as @danny finishes the Roonux distro 
While I doubt RoonOS will replace my current install (which is also running local backup, cloud backup, ownCloud, VPN and local file/printer sharing), I’ll buy a second NUC just to d*ck around with it. Finally a genuine Roon home test lab… 
My thoughts exactly.
One thing that puzzles me is that many puts 16Gb RAM in their NUC I have never seen my NUC use more than 1.75 Gb. The 8Gb I have seems like overkill. It is running Linux.
@Ludwig Yes, this is one with RAID 0 vs. single Samsung 950 PCIe SSD testing.
On write there is 100% performance increase, on read there is 30% performance increase in RAID 0. Read speed increase bottleneck above 3000 MB/s is DMI 3.0, and heating of SSD modules.
It allows to cut down search by some 3-5 seconds to 10 seconds, and reach launch of playback to below 1 second.
On Skull Canyon it gives 6 seconds windows load time, but honestly also as improved Roon load time - they are not important.
I don’t store music on SSD, all on NAS. But actually it doesn’t make difference, where music files are located. The playback start time anyhow is less than second. Just the search is not so pleasant with 10 seconds wait time.
The bottleneck is database and search management. @brian Great news, I’m looking forward to see search engine optimization in next major release. Also as on Server SSD only database is stored, I don’t see much of concern even if RAID 0 would have 2x higher failure risk than single drive. Automated weekly backup of database folder is sufficing protection.
Janis
It’s important not to neglect the value of buffers + caches in the kernel when thinking about memory usage.
The filesystem cache is the most important one for us. Filesystem caching won’t show up in memory usage stats at the application level, but there’s a big difference in performance between a machine that’s barely fitting the app in RAM and one that can fit the app in RAM and fit the disk footprint (or most of it) in filesystem cache, too. This mostly benefits read performance, as writes still need to flush out to the storage media.
That said, 8gb is more than enough to fully benefit from any filesystem caching effects for the vast majority of our users.