@simon_pepper
I have the same Samsung M2 here. I tried to install Roon Rock using USB but ran into issues (it could boot from USB alright, but it stated No Boot Disk found, insert boot disk …).
When installing using a PC I could install Roon Rock on the M2 unit but my Nucleus wouldn’t boot from it.
How did you get it to work? Did you clone the original SSD using Clonezilla for example?
What do you have enabled under Boot in BIOS? UEFI or Legacy Boot?
Make sure you have both checked.
1 Like
It was a fresh SSD in my NUC, which ROCK formatted before I was able to restore a backup of the Roon database to it,
1 Like
Thanks, I will check that.
That might be the trick.
How does roon rock make sure it’s using the Performance cores ? If single core performance is still that important, isn’t it time to optimize roon to use multiple cores for one zone?
After all it’s just music streaming.
Sure these 8-16 core cpus will be nice for people with lots of endpoints.
And how does a Nas running roon in docker etc allocate cores to roon?
And couldn’t roon rock use a SSD for swapping the way a ps5 uses its SSD ? Surely there would be a option with amd boards and cpu
Can only speak for a QNAP NAS running roon as a native app on QTS, but seemingly this OS is utilizing one core per heavy stream plus another for computing-intense browsing operations swapping the cores every 10 or 15 seconds once they get hot. Monitoring the CPU load per core over time you can nicely see how one at a time is peaking in turbo mode.
Text queries seem to utilize all cores simultaneously already.
If you do not demand highly computing-intense crosscoding operations for every single endpoint (such as applying EQ or convolution filters on DSD512 or upsampling from PCM352 to DSD512) you would not really notice the load a particular stream is putting on its designated core. Cannot really imagine an application in which someone is listening to 8 DSD512 streams simultaneously not to speak of the necessary DAC hardware in 8 rooms…
Want to say, it is rather browsing and performing searching what is demanding computing power rather than performing the streams themselves.
2 Likes
It’s quite likely the Roon Server application does not distinguish between Performance and Economy cores at present. (It almost certainly wouldn’t have when the 12th generation processors were first introduced). However, even economy cores should be good enough for much of the DSP that can be performed (high bit rate DSD possibly excepted).
Handling the stream in a single core, as is done at present, is the most efficient way of doing it. Whenever you spread a workload over more than one core, you introduce an inefficiency that ineveitably means that you use more total resource. Thus, you are better off with single core processing until such point as the processing cannot be done on a single core.
I believe search is mulithread and so may well also benefit from the extra cores.
I don’t know the answer to this. I am not intimately familiar with all the different NAS solutions or with Docker.
For maximum performance, no matter how fast your SSD is, you want to avoid swapping. Swapping incurrs a time penalty (swapping memory to and from a disk or SSD takes, in processor terms, a significant amount of time) and so it degrades the performance of any given application (meaning that that heavy realtime DSP that you are doing is less likely to work) and also makes it less deterministic (which, will not normally matter but could in extreme circumstances).
Since RoonOS is designed just to run one application (and the services required to support it), it is relatively easy to determine how much memory is required and supply enough to avoid the need to swap. If swapping was supported by the RoonOS, then that would, in itself, have a (very) small overhead with respect to some operations - even before swapping started to occur. When the system got to the point that it started to swap, the system performance would fall dramatically although you would not notice it in the audio stream provided it was still able to keep up. Only when the increased overheads got to the point where samples could not be delivered to the DAC on time would an issue be observed.
More significantly, you would get support requests of the form “sometimes everything is OK and sometimes the audio breaks up and the stream stops” which would be almost impossible to diagnose properly without looking, in depth, at OS logs. And the solution would still be the same - add more memory to avoid swapping.
Consequently, for an appliance type device (like a Nucleus or a ROCK installation), the decision to not allow swapping makes more sence both for the customer (who gets a system with more predicatable performance) and for the company (who get a reduced support overhead because memory related issues are easier to diagnose using only application logs).
2 Likes
Might be best asked in Tinkering since docker is not a supported Roon environment.
My experience shows Roons most cpu intensive processes are its metadata updates. Running
upscaling and convolution on my system hardly taxes it cpu wise, yet when it Roons a full metadata update it manages to max out a single cpu core it’s and subsequently lose all connectivity for a few minutes until it’s done. This has been reported happening more recently by a number of users.
2 Likes
That is accurate, but metadata-crawling-intensive browsing operations such as compiling composition lists, track lists, composer´s pages and alike comes second according to my experience. With a huge and complicated local library, roon seemingly relies on a single core to crawl all data and compile these lists causing this core to spike for several seconds or longer.
Do not really see the point why this is not done by several cores combined, as it is the case with text queries which are also computing intense.
That is the case with PCM352>DSD512 crosscoding as well? Sounds like a very powerful CPU.
Not that powerful just a series 11 11390 , Processing speed shows 4.8x +, HTOP shows little happening overall.I cant go higher than DSD256 as my DAC doesnt support it over DoP. This is also sending to it over Wifi which adds to processing time.
Search can use more CPU than this as its spread across all cores. Searching for ‘The The’ it goes nuts and takes 10 or more to return back like others have found.
Using any of the focus stuff has little affect I find, but my library isnt massive about 3000 album, 1036 artists and 33393 tracks.
1 Like
To cut a long story short. I managed to boot from USB but the nucleus hanged at Welcome to Grub.
I have used Macrium reflect to clone the M2. The source in the slot in my computer and the target disk (Samsung 970 evo) mounted in an external m2 unit, through usb-c.
The nucleus booted from this Samsung 970 EVo perfectly. I am testing it now but it seems to be working more than fine. 