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.
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.
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.
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.
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…
@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.
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.