B1553 Feedback

Early Access
21

Roon is never really idle. It does mDNS discovery of endpoints, tries to update files with missing metadata, syncs with Qobuz/Tidal, runs your backups, etc.

Here’s about 4 days of a Docker container running nothing other than Roon prior to the fixes in the latest EA builds.

You can see the non-stop CPU activity as well as seeing Roon grow from a functional baseline of around 2GB to well over 18GB of RAM use. Now that the fixes are in, it never exceeds 2.5GB of RAM. It only dropped in this graph because I restarted.

image
image1933×1033 69.9 KB

@David_Nanian - you have a very large library. You’re running on an i3 with too little RAM. Your system is almost certainly underpowered and under-resourced. You probably, quite reasonably, believe that for the money you spent on your Titan, you shouldn’t have to hear this news. The only thing I can say to that is to please not shoot the messengers.

You may or may not also be impacted by the memory leak that exists in production and EA builds other than the latest couple. That may be exacerbating your problem and leading to the crashes because that’s what it does when it runs out of memory.

I have no idea if Roon can run healthily in 8GB of RAM with your library. I also have no idea if it can run healthily with an i3, and that’s what you’ve got in the Titan. There are a lot of variables here.

22

Not shooting the messenger - just trying to indicate what I’ve seen.

I recognize that things aren’t “really” idle. What I mean is that I’m not actively using it, nor is the library changing. As such, you’d think any metadata updates would be minimal (as compared, say, to an initial scan).

The mDNS/Bonjour/Rendezvous daemon (something I’m all too familiar with, having written software that uses it) doesn’t do a lot when things aren’t changing so I wouldn’t expect that would take much memory either.

I’ve ordered 32GB of memory so we’ll see if that helps. But I can say that on macOS it doesn’t grow its footprint save for the ports (which really should never happen).

I have to assume that the i3 was deemed to be sufficient, given it replaced the older units with more capable chips. But certainly it’s far less performant than the mini, and will be so even after the memory is increased. But I’m not complaining about the speed so much as the crashing, which shouldn’t be chip dependent. If anything, I’d expect Mono/.NET on Intel to be “more efficient” than on ARM/Apple Silicon, given the history,

24

I believe it was thought the Titan had an i9. I was surprised to read the article I found what the above screenshot was from. An i3 13th gen is capable. It out performs my older spare i5-8500T server by quite a margin.

I believe the Roon information states the Titan can perform all DSP tasks. I’m guessing not simultaneously. I can comfortably convert DSD256 to PCM and apply VL. So the i3 in the Tatan should fair better.

I have had several i5 based servers for Roon duties. They have always proved capable. Even the 8500T versions.

As some know, I also have a N95 based server, with 8gb. This performs really well with some DSP and it was recently with this device that I noticed my library of 90k tracks at the time was crashing due to running out of memory.

My library is now 120k tracks and with B1553 I’d feel comfortable, not fully confident I could use this little beast again.

Having said that, it’s CPU is noticeably slower than my current i5 based server.

The latest issues have been memory related though.

A while ago it was more memory usage from a reboot that I noticed, then a steady growth to cause crashes.

I upgraded my N95 to an i5 and thought “what the heck, I’ll pop 32gb RAM in it”

The CPU is fast enough and I have more than enough memory now that I could go a week or some with the memory leak that was first noticed before a crash.

I see a higher amount of memory being used upon a reboot while the server comes online but then recedes to 4300mb or so.

I’ve added a few albums tonight and memory has increased to 5gb.

Roon’s information suggest 4gb for 100k tracks.

260k tracks, well, 10gb maybe :man_shrugging:

This also may not be the issue @David_Nanian is experiencing, but my gut tells me if the RAM isn’t increased then it cannot be proven. Or reduced the library size to 50% (or less) as Roon suggested to see what happens.

Folks like @gTunes and I (and more) are here to offer help where we can.

25

macOS swaps, so it “never” runs out of memory. Roon OS does not swap (on purpose).

You spent 4K on a NUC in a very fancy case, don’t skimp on 30 EUR to run it with an amount of RAM that is consistent with the official recommendation for your library size.

It’s not running on Mono anymore, and if the application needs more memory, a limit wouldn’t help it.

Besides, we know for a fact that Roon OS crashes when out of RAM, and that it does so on machines with 8 GB if that is insufficient for the library size.

26

If you look up the CPUs on CPU Benchmark, you will see that an i3 of that generation is a wise choice. A i5 or i7 would be more expensive without giving Roon or you anything useful.

The single core speed (which is most important for Roon) of an i5/7 is not faster than an i3, and an i3 already has 6 physical cores, which is enough for running 6 zones in parallel with crazy DSP, and way more than 6 with sane DSP.

A 13th gen i3 is much more capable than, say, a 10th gen i7. Model numbers mean nothing.

(But yeah the M4 in the base Mini is faster)

27

Yeah, like I said, I assumed the it was deemed to be sufficient…but obviously would also top-out should they decide to do more CPU/threaded things in the future.

It is kind of shocking how much faster the mini is, though.

28

I have a different opinion, @Suedkiez.

When I compare the 13th gen i3 to the i5, I see plenty useful in the upgrade. If the 15% single thread rating doesn’t convince you, then take a look at the difference in cache. It’s enormous.

If I were building a NUC or similar for Roon, and my budget was $1000, let alone $4,000, there’s no way I’d put an i3 in it. It’s not just about concurrent streams, it’s about all of the database operations.

We haven’t talked about database. LevelDB is not SQL. I have no estimate for how large a LevelDB database with 268k tracks and 20k albums is but it has to be very, very large. LevelDB was designed by smart people who used sorted keys, bloom filters, and other tricks but it is not SQL and that means no statistics, cardinality estimates, query optimizer, query processor, etc. It can be both memory and CPU hungry for the sort of workload that Roon throws at it and there are likely some operations that have O(n) or even O(n^2) performance.

It would be interesting to see some real-world Roon performance data comparing the two. I think an i3 would be absolutely fine for a small library and a small number of concurrent zones when there is no expectation of doing DSD or heavy DSP for multiple zones concurrently. But if you’re budget is $4k, I don’t think it’s the obvious choice.

image
image813×690 50 KB

29

I feel like we’re very off topic here.

I started this thread to provide a place for people to give @ben, @vova, @ivan feedback on the latest build. I was hoping it would be short lived with a release this week but since it may need to live longer, can we return to the topic?

This is build 1553 since installing on 8/4. It doesn’t have the steep memory leak that pre-EA and early EA builds had but it does step-function upward over time.

If this trend continues, it’s indicative of another leak or some other behavior which is causing memory to jump up at regular or semi-regular intervals and they stay up.

image
image1226×791 56.1 KB

30

We are looking at very different CPUs. As far as I know (as per post linked above), it‘s a i3-1315U, you are comparing an i3-13100 and an i5-13600.

I don’t think yours can be right because it’s a 60 to 65W TDP, which certainly is not a mobile CPU.

See this for a comparison of „my“ and „your“ CPUs.

I am quite sure that I have compared the i3/5/7 mobile 13th gen CPUs before and found the i3 to be the best choice. I normally don’t say such things without facts. (But I can be wrong. Can’t really search for other NUC CPUs now, no time at work)

31

Sorry, wrong link. This one:

And in fact it says „desktop“ on the comparison chart

1 Like
32

This could be due to methods of CPU cooling. The Mac has a fan?, the Titan has passive cooling via the case.

The Titan, as do all the Nucleus devices, have additional code to throttle the CPU performance, to maximise it but obviously not to cook the CPU.

@moderators could we have these posts broken out into a thread of their own. Thanks

1 Like
33

The current version (1553) is running great on my M4 Mac mini. 10gb ram are used (I have Splashtop , vpn and other things running) , 1.5gb ram of that are used for roon . 6gb ram are used for cache. There is zero swap.

My music is stored on a external thunderbolt NVME SSD.

(Im Also using upsampling and opra)

1 Like
34

My devices are all taking much longer to connect than before. I don’t know if this is due to tracking instrumentation built in to the ipv6 connection changes but it’s a real pain.

1000027878
10000278781080×2217 95.1 KB

1000027877
10000278771080×2217 120 KB

1553 server build

35

@ged_hickman1 Curious, is this following a reboot or during normal daily use when you revisit the app?

I’m noticing occasional unresponsiveness with the iOS app, similar to remote freeze gate the other year, but I’m so use to swooping up and away to close out the app I’m not noticing what you mention.

FWIW - IPv6 is disabled on my LAN, always has been and my ISP doesn’t offer it.

36

@ben + others - I’m going back to production. I don’t understand if there’s a direct, trusted path from EA back to production, so I keep separate environments. So using EA means I lose play history, etc. for that period. So back I go.

Here’s one last view of 1553, which is holding pretty steady around the 3GB mark for me. The spike on the left is pre-memory fixes.

image
image943×938 52.3 KB

I’m hoping for a release soon. Thanks again for investigating these issues.

37

I presume they’ve just switched on the discoverability group as I’ve gone back to connecting straight away. :+1:t2:

1 Like
38

You can simply switch as long as the database format doesn’t change in EA. And you would notice that because the EA update would be followed by a lengthy stay on the „updating your database“ screen

1 Like
39

If you’re confident that the UI always makes it very clear when some sort of breaking change is happening and you’re also confident that you’ll never miss it and you’re also confident that you’ll find the right moment in time to switch back, then by all means, please continue to do that :slight_smile:

I’ve had my database go corrupt for reasons not related to EA. The corruption went back weeks - Roon wasn’t complaining and it kept doing backups. Suddenly it complained that the database was corrupt and when I tried to restore from a backup, it turned out that my backups had been corrupt for weeks. I’m lucky I keep many around.

I don’t want to repeat something like this so I’m very conservative. I keep my EA and prod environments completely separate. Easy to do with Docker.

1 Like
40

This is a bit counterintuitive. I assumed they want to test if turning this “discoverability group” feature on breaks things for people. The notes about the upcoming changes suggest that the are removing a discoverability mechanism. It’s strange that turning it on would fix something. But who knows.

41

Here you go