New Roon hardware for very large libraries

[Tor_Gunnar_Berland]

@George_Frouzakis

Hi, No it’s RAM. I’ve placed two 64gb chips in the slots of nucleus +. I don’t have a SSD in the nuclear plus but rather a NAS Synology server, with a total of 22TB, and of which I’m using about 60% of the available space. The Synology server is also maxed out in RAM with 128gb of RAM.

I’ve chosen to go with the nucleus for its hi fidelity, as I connected with a hi-end stereo and powered by a Farad linear supply, cables and few other stuff here and there. I was hoping to maintain the level of quality because it did work for me this set up. Going another route from now on, I have to make sure that the fidelity is maintained. This seems hard to do because computing is not my field of expertise…

I have 200.000+ tracks, and regarding RAM - I could almost get by with 8GB (on certain versions of Roon I have seen it exceed slightly when investigating the Nucleus+ logs), 32GB RAM should be enough for up against 1.000.000 tracks. Actually I’m not even sure the Nucleus+ will use more than 32GB of RAM regardless (don’t think this is supported by hardware even) - it might work, but don’t think it will be ever used (hence you have wasted money).

The CPU of the Nucleus+ is also more than you need regardless of size (memory is the limiter when library grows). The M.2 SSD for database and RoonOS is default 64GB (at least on first revision of the Nucleus+) - this will be more than enough for way more than 1.000.000 tracks as well (I use 12GB currently with well above 200.000 tracks).

However, having the music stored on local SSD (either internally and/or USB) - will make the performance good even on larger libraries.

I’m actually not sure the hardware is the problem here. Obviously there is a limit to when the Nucleus+/ROCK is optimal, but should work fine even for large libraries (I would think not even 0.0001% of the Roon users have something even near the limit of the Nucleus+).

CPU is mainly used for DSP (and analyzing files).

[Suedkiez]

@Tor_Gunnar_Berland

Actually I’m not even sure the Nucleus+ will use more than 32GB of RAM regardless (don’t think this is supported by hardware even)

I don’t know the exact CPU in the N+ but for instance the NUC8v7PNH with 8th Gen i78665u, I’d be surprised if any do more and certainly possible that some are limited to 32.

[Tor_Gunnar_Berland]

Intel® NUC Kit NUC8i7BEH - Product Specifications | Intel

[gTunes]

@miklats

Maybe your problems are originated in Roon’s move into the cloud. I think the search function is now completely cloud based. That might explain the lame response you encounter.

This is probably the first thing you should investigate and understand.

@Tor_Gunnar_Berland

I have 200.000+ tracks, and regarding RAM - I could almost get by with 8GB (on certain versions of Roon I have seen it exceed slightly when investigating the Nucleus+ logs), 32GB RAM should be enough for up against 1.000.000 tracks.

This is very helpful - there’s now plenty of evidence to suggest that your library size alone is unlikely to be the problem.

@Tor_Gunnar_Berland

However, having the music stored on local SSD (either internally and/or USB) - will make the performance good even on larger libraries.

@Tor_Gunnar_Berland - I suggest we be careful about implying to @George_Frouzakis that changing his storage solution will help. Playing a local file from a NAS with spinning media should be quick. That’s what I do and playback begins in under a second. My library is much smaller but that shouldn’t make a difference for playback. I would expect the difference between a NAS over SMB and even a local-to-the-core USB SSD to be measurable in maybe tenths of seconds. @George_Frouzakis hasn’t said specifically how slow playback is to respond but it seems likely he’s experiencing something longer than the normal difference between SSD and spinning media plus network hop.

How slow is it, George? If it’s slow enough to justify looking into it further, can you explain your network including the network between your core and your NAS?

[Tor_Gunnar_Berland]

Playback from NAS works fine, but scanning or analyzing music files on NAS will take forever compared to local SSD storage.

Edit:
It also be nice to know if @George_Frouzakis uses any form of DSP; because this can have an effect on the performance if you in parallell analyze tracks in background (this is a very time consuming process via NAS compared to local storage). It might slow the system down.

I also recommend to check logs:
\nucleusplus.local\Data\RoonServer\Logs ==> file: RoonServer_log.txt is the latest (active).

In logs, search for “[stats]” and lines like this:
11/26 11:11:53 Info: [stats] 26109mb Virtual, 6477mb Physical, 3202mb Managed, 498 Handles, 84 Threads

Physical is the key part here, what is the number on your system ? This is my system, as you can see, 6477MB is consumed on 200.000+ tracks.

Please scan through multiple lines to see how physical memory consumption moves up/down.

Actually if you run out of memory, the RoonOS will crash - since it does not use any swap file. Hence adding more memory will not increase performance (it will not utilize more regardless what you have available). So only time you need to increase memory is if it actually crashes, else it is like throwing money out the window.

[Bill_Janssen (now wearing snowshoes on my asymmetrical isolation feet)]

@Tor_Gunnar_Berland

scanning or analyzing music files on NAS will take forever compared to local SSD storage.

Unless the Core is also running on the NAS.

[Tor_Gunnar_Berland]

@Bill_Janssen

Unless the Core is also running on the NAS.

Regarding initial post; this is Nucleus+. And NAS is not the issue, but retrieving/scanning files over the network is much slower than via local SSD.

[George_Frouzakis]

Hi guys! Truth is I’m in doubt now here. It has been more that a year that I have installed the RAM in the nucleus plus and is possible to mix it with something else. But one thing is for sure. I have used the maximum RAM I could. I’ll open it when I head home to check again.

[garym]

@Tor_Gunnar_Berland

And NAS is not the issue, but retrieving/scanning files over the network is much slower than via local SSD.

Correct. But keep in mind that a regular spinning disk attached to the Nucleus is perfectly OK (and way faster than file access via NAS). SSD is critical for running the core and for the database. But not needed for feeding files via an attached drive.

[crowlem]

@garym

regular spinning disk attached to the Nucleus is perfectly OK

Isn’t the latency (seek time) a bit of a problem on spinning disks ?

I would imagine if you have a large local library, that would be pretty unpleasant. The instant response of SSDs would help when locating files for playback and for search?

[garym]

I have only about 130,000 mostly flac files on an attached 4TB USB spinning drive to a NUC running ROCK. I find searching, browsing, etc. to be instant.

[Swisstrips]

Why not ditch the “roon” direct to dac config and get an endpoint, which there are tons of around from a basic pi to higher end which will meet your fidelity requirements.

Roon core:

• Purchase a tower/mid-tower/small form factor workstation (which resides in a utility room/closet). Config this to whatever processor and mem you want.
• Load it up with high capacity HD’s (roon core/DB has direct access to your music files) and do away with ext usb drives etc…
• Install Ubuntu and then roon server. Those are the only application running on this dedicated wkst.
• Purchase high quality endpoint (I believe this is the recommended config by roon) and connect that direct to DAC. Unlimited options here from basic to high end and the way to go IMHO.

Backup / maintenance:

• DB + music file backups are now done from dedicated wkst > to NAS
  • In roon server settings, set the NAS as the DB backup every day or whatever you want
  • Music files would be backed up to NAS using various methods (many options here)
• Once a method is in place for DB and music files backing up to NAS, you could then back up NAS to another media to be thorough is desired.

Good luck

[Suedkiez]

@crowlem

Isn’t the latency (seek time) a bit of a problem on spinning disks ?

Compared to SSDs if you have lots of random accesses, yes. However, for reasonable modern hard disks the sum of seek time and rotational latency is in the range of 20 milliseconds.

Searches that must hit the disk would be unpleasant, but it would be bad design. Any high-performance search must run from RAM, anyway.

[crowlem]

Good to know, thanks

[gTunes]

@Suedkiez

Compared to SSDs if you have lots of random accesses, yes. However, for reasonable modern hard disks the sum of seek time and rotational latency is in the range of 20 milliseconds.

Correct but that’s not even the complete story. Hard drives have RAM caches and in most cases, systems will “read ahead” resulting in caches getting populated. When a NAS with RAID is in use, depending the RAID mode, content is distributed across drives such that reads are effectively parallelized. Add gigabit network to the mix, and you have a fast and capable storage strategy for streaming media.

I’m not talking about where to put your database. Database i/o patterns are different and a database should most certainly be on SSD (or an SSD cache in front of spinning media) and co-located with the core.

The poster isn’t have issues with how quickly his library is processed. And playing from a NAS isn’t problematic in a scenario in which the NAS and network are functioning well.

[Suedkiez]

Agreed with everything. I think we can agree that access times on HDDs are negligible for the purpose of starting an audio file replay

[Hogio_Setiawan]

No, the speed depends on the database. When you do search etc, I don’t think Roon “search” the files themselves. The actual files are only accessed when being played.

[steve_smith1 (Steve Smith)]

Hi @George_Frouzakis,

You should be able to use information below to identify candidate storage solutions to fit your budget and Core requirements should you decide to go there. This is a very general guide to what each technology can do for you and is not intended to suggest specific drives, they were convenient for my objective, i.e., easy to access.

I’ve built my own Roon Core for a few years now and am perpetually testing new storage technology. I compiled performance results for different technologies used today for use in all my systems.

Below are well-known benchmarks of the different technologies. The benchmark tool is Crystal Disk Mark, is free and available by searching on google. The storage types are listed in order of performance from slowest to fastest.

The benchmark reads and writes 1 megabyte of data sequentially (SEQ) and 4 kilobytes (4096 bytes) of data randomly (RND) data to the drives with the result displayed in MB/s. These are shown on the left column of the image:
SEQ1M means 1 megabyte of data is sequentially (SEQ) read from and written to the drive on the first two rows of the image.

RND4K means 4Kilobytes (4028 bytes) of data are randomly read from and written to the drive.
Random reads and writes show how the drive performs when it cannot effectively use its cache because the data used is likely outside of the cache. So you should see significantly poorer performance here.

A Q followed by a number, e.g., Q8 indicates how many queues are being used. Similarly, a T followed by a number indicates how many CPU threads are being used. This can be a rathole because of the permutations possible., today’s consumer CPUs have 24-32 threads. In short, these are provided for completeness only.

SATA drives today are all SATA III (6Gbps) and have maximum data transfer rate of ~600 (MB/sec). But not all hard drives reach that speed or if they can, may not be able to sustain it, e.g., the first drive below can only sustain transfers of 237MB/sec vs the 600MB/sec theoretical.
Read and write speed results should be close for each test (row in the image). They are shown at the top of the image and are labeled Read (MB/s) and Write (MB/s)

1. The SATA hard drive; a Seagate EXOS 7E8 (Enterprise 8TB drive) ~$200. This might be in your NAS or in a data center or on your PC.
   

2. Sold State SATA drive - Sandisk Ultra 3D 4TB ~$300. Same interface limitations, 600MB/sec. but it can nearly reach that speed 500+ MB/sec. This is a key improvement that solid state drives (SSD) made over traditional HDD.
   ![Sandisk SATA SSD|482x352] (upload://WTLmkLg3SICe2Id4BLBn8Rkiyh.jpeg)

3. USB Solutions: There are 2 basic ones, a USB to SATA interface adapter and is limited to the maximum speed of the interface (600 megabytes/sec. as noted above). The other is a USB to NVME (PCIe) adapter that use PCIe as an interface.

USB 3.0 and 3.1 gen 1 (5,10 Mbps, respectively) can work well with SATA enclosures.
USB 3.2 gen 2x2 and USB 4 (20, and 40 Mbps) typically work with NVME enclosures. While faster, their price is much greater because the enclosures are about 5x the price + the cost of the NVME drive vs a SATA drive. The USB 4 drives are typically thunderbolt 4 on PC’s and Mac’s. On PCs the enclosures only work correctly with certain NVME SDDs that the manufacturer may or may not specify.

USB 3.2 Gen 2x2:

USB 4 - The drive shown is not compliant with the enclosure’s manufacturer, so the disc read speeds are slower and the write speeds are a disaster. With a compliant drive, the read and write speeds would be about 3 gigabytes/sec. Just USB 4 drive enclosures have this issue, I believe because they are new.

4. PCIe 4.0 NVME drives are the fastest storage available.
   

But they vary in performance - note the write speeds on the WD drive below vs the Samsung above.

Most motherboards (and SBC’s aka NUC) support 3 or more of these high-speed drives and I just purchased a 4TB drive on sale for ~350 on sale. Your mileage may vary, but I believe these to be the best solution as their prices decrease and density increases. My current motherboards support 4-6 NVME SSDs even though the manufacturers don’t provide that information. It works out to roughly (PCIe lanes -4)/4. depending on what other hardware is in the computer, e.g., a graphics card, ethernet/wifi, USB cards, etc.

[George_Frouzakis]

So much information there, Thank you!!

[George_Frouzakis]

Hi! Thank you! This route would cancel out few components that I have invested in i.e cables. but definitely a possibility. Thank you for the suggestion!!