Waveform processing on ARM, Nexis vs Syno

[foret_sombre]

I have made a case support about a problem I noticed on ARM machines which slows processing a lot when audio files are on a Synology server rather than on a local disk. We are used to move sessions from folder to folder (recording and mixing sessions) which force the wavecache to recalculate itself. For sessions with few clips or clips that are note very huge it's usually fast, but since we switched to ARM machines it can take 45 minutes for the wavecache processing of a re-recording session of a 2h30 movie (with Atmos beds and objects and re-renders). For a mixing session which is reimported in another session for example it can take hours. The problem seems to be with caches that are >1Go and were already calculated. Trashing the cache pref, or copying the existing cache in the new folder doesn't do anything.

As I said to Avid support, it used to be a bit long on Intel machines as well but not that much, but they are blaming it on our Syno raid (I sent them the logs between having the session + files locally and on the server, and explained to them we can't have all the files locally for size reasons).

I'm then asking for experience : people with Nexis, have you noticed huge drops in waveform processing between Intel and ARM ? Is it that much more convenient compared to a Syno ?(we do only sound post and don't really have to communicate sessions between people besides save copy in)

Thanks for your input.

[tope d]

Hi,

May we know your case number? Last case opened I saw was regarding GUI issues which make false clips on tracks.

[foret_sombre]

Hi Tope,

Here is the case version : 04803518. It seems to be closed and I just responded.

[BScout]

Are you comparing the same macOS between Intel and ARM computers?
Apple has done a lot of changes to SMB.
Have you checked the write speeds (for small file sizes) between Intel computer to Synology and ARM computer to Synology?

[foret_sombre]

It was the same OS (Monterey), and when I changed OS on ARM machines it's still the same problem.
AmorphousDiskMark give similar results for the random blocks write (Intel is a bit better, it's around 8Mb/s for both), but it crashes on ARM for the RND4KQD64 test.

[Frank Kruse]

No idea which PT or OS version you're using but for what it's worth, I did a quick test opening a huge session on a TrueNAS Scale server mounted via SMB (10Gb network) and waveform creation was just about as fast as on an internal drive.
I strongly suspect your server might struggle with random read/writes maybe? Depending on how you've tuned SMB or your disk array on the NAS you can get massively different results for different tasks related to RAM cache on the NAS too. 8Mb/s seems EXTREMELY slow. Have you checked if maybe an ethernet interface involved has switched to 10Mbit or something?

[foret_sombre]

Originally Posted by Frank Kruse

No idea which PT or OS version you're using but for what it's worth, I did a quick test opening a huge session on a TrueNAS Scale server mounted via SMB (10Gb network) and waveform creation was just about as fast as on an internal drive.
I strongly suspect your server might struggle with random read/writes maybe? Depending on how you've tuned SMB or your disk array on the NAS you can get massively different results for different tasks related to RAM cache on the NAS too. 8Mb/s seems EXTREMELY slow. Have you checked if maybe an ethernet interface involved has switched to 10Mbit or something?

Writing is 400Gb/s in sequential (same with Blackmagic Disk Speed Test), the problem is random access. Every switch are 10G. I'll check the SMB settings. Do you have a read/write cache SSD on your NAS? We have a read-only cache for the moment.

[Frank Kruse]

Originally Posted by foret_sombre

Writing is 400Gb/s in sequential (same with Blackmagic Disk Speed Test), the problem is random access. Every switch are 10G. I'll check the SMB settings. Do you have a read/write cache SSD on your NAS? We have a read-only cache for the moment.

I have a 1TB NVMe read cache installed and 64GB of RAM installed that TrueNAS uses nearly fully as well. I get between 700-800Gb/s sequential read write with an 8-drive (spinning, not SSD) raid Z2 (double parity).
On extremely large projects (series that have massive media vaults) I do keep static audio on the server to be able to work off of the inernal NVMes with the fluctuating audio but never really noticed any massive difference. Once the read cache has filled even less so. But this is not a regular setup I use. On features I keep everything local. But it's apples vs. oranges. Every server is different and there are a million variables that influence SMB performance. Just wanted say that I don't think it's ARM vs. Intel per se... but I could be wrong obviously. As others have said SMB performance/issues on Mac can change a lot depending on your MacOS but 8Mb/s seems a bit extreme to me even for random read/write.

[foret_sombre]

Actually we are using AFP and not SMB, so it should be more stable over different OS. There wasn't a DSM update or a change in network infrastructure before I noticed the slow waveform processing, only going from 2023.12.1 to 2024.3 and on ARM (no OS change). However the slow random access writing speeds on both Intel and ARM are concerning, so there might be an underlying problem with the server which wasn't that bad before ARM.

[Frank Kruse]

Ah, AFP has been abandoned for many years (even by Apple). Even Apple discourages using AFP nowadays and they don't maintain it anymore and the NAS mfgs just drag the old code along just so there's something "apple" in the specs.

Try SMB see what that does.