This has been popping up for some time, and autodesk advises to use NFS
as I have a new all nvme storage server for a shared stone - i wonder for my mac clients as to which is actually better ?
I cache prores444 or dwab exrs.
Blackmagic disk speedtest showed that smb was way way ahead in terms of speed, i got 10Gbit line speed with smb and more like 300/700 MB/s on NFS, flame internal benchmark showed again line speed for both smb and nfs.
I couldnt tell in a playback test which one was faster/less latency or anyhting, it really was⌠the same?
Its probably fine to use either but maybe anyone knows why adsk is saying to use nfs?
I would expect that itâs related to the fact that Network File System is mature and despite some edge cases, itâs almost ubiquitously functional.
Server Message Block can be an unpredictable ratâs nest of ACL complication and drama on Linux, despite being relatively trivial on macOS and Windows.
SMB Direct with the right cards will permit line speed throughput with very low CPU overhead.
Iâm curious to know if youâve experimented with thunderbolt networking and SMB on your flames, Finn?
Take a look in this file to see how you might configure multiple interfaces to carry metadata and data separately:
/opt/Autodesk/cfg/network.cfg
You may find this section interesting:
[Interfaces]
# Comma separated list of the local network interfaces to be used for
# metadata operations. Metadata operations are usually small IO operations that
# may degrade performance when done on a high speed network adapter when a
# lower speed adapter can be used instead. If a metadata operation is too big
# for this lower speed adapter, the IO operation falls back to the adapters
# defined in the "Data" token described below.
#
# The order of the interfaces in the list is the order in which they
# will be tried. '*' can be used to denote any interfaces. The loopbacks are
# implicit and always preferred.
#
# If left empty, all active interfaces will be used.
#
# Example: Metadata=eth2,eth1,* (on Linux)
# Metadata=en1,en0,* (on Mac)
# Metadata=eth2 (only eth2 will be used)
#
# Note: Stone+Wire uses a different interface mapping that is defined in
# /opt/Autodesk/sw/cfg/sw_framestore_map
#
#Metadata=
# Comma separated list of the local network interfaces to be used for
# large IO operations (data or metadata). See also the "Metadata" token for
# additional information.
#
# The order of the interfaces in the list is the order in which they
# will be tried. '*' can be used to denote any interfaces. The loopbacks are
# implicit and always preferred.
#
# If left empty, all active interfaces will be used.
#
# Example: Data=ib1,eth2,* (on Linux)
# Data=en1,en2,* (on Mac)
# Data=ib1 (only ib1 will be used)
#
# Note: Stone+Wire uses a different interface mapping that is defined in
# /opt/Autodesk/sw/cfg/sw_framestore_map
#
#Data=
@finn - I admire your approach to experimentation brother, and applaud it.
There are many factors that could be affecting the situation:
Blocksize
RAID Type
RAM Allocation (if possible)
RDMA (Iâm not sure if macOS permits this but Iâm sure some clever wag has hacked it)
Bus Type
Cable Type
And then you have to configure both ends.
What is the read speed of the source volume?
What is the write speed of the target volume?
What is the data type being sent?
Is it constant or variable?
Is there pre-read happening?
Is there cache-ing?
Are the machines doing IO solely, or performing multiple tasks.
If youâre using ProRes or DWAB, and your source framestore is set to such and shared=true, do you actually need to transfer any media at all?
Can you do shared workspaces on the project server and no transfer?
(You may need to rope @ALan in!!!)
How well does that work with a mac project server with multiple mac âclientsâ?
No doubt, you will do an exhaustive investigation, and present your results to the community as you usually do.
Godspeed @finnjaeger - may the force be with you brother.
âWe recommend using Jumbo Frames on all devices in the network, including the clients. If a device uses the standard MTU size of 1500 bytes, connectivity issues may occur.â
thats from unifi and one of the reasons my previous workplace didnt want this so i refrained from doing it as the switch does more than just the storage network stuff.
If the switch is set to accept Jumbo, it still passes all packets. But if machine A is using Jumbo, and machine B is not using Jumbo, then you have problems. I think the fact that switches need to have Jumbo enabled (instead of just default on) is some legacy crap. No harm in enabling it, unless for some reason you want to ban Jumbo traffic.
The right way to do this, is to have 2 networks whether physical or logical (VLAN).
Normal traffic, internet, administrative, local LAN type stuff. Standard MTU 1500. This way you know youâll always be able to hit that host without any special config.
Your high-speed data network. MTU 9000. Every device on this network needs to have Jumbo enabled.
And machines/devices can be members of both networks, as long as the interfaces have the appropriate MTU set.
An example for us, we have a copper 1gig network used for the basic stuff, SSH, machine configuration, normal traffic.
192.168.1.xxx âAutomatic MTUâ (1500).
We have a 25gig fiber network, just for high speed data.
192.168.10.xxx âmanually defined MTUâ (9000). Setting this on windows is in some obscure hardware settings tab, and the value is 8972 or something like that, look it up.
If you were to use a single physical network interface, you would do this all via VLANs which are quite easy on Unifi.
In regards to the ADSK network.cfg, just set it all to the highspeed interface. Most of the descriptions in their cfg files and documentation are from like 20 years ago when hardware was lame.
sadly on unifi vlan routing is utter garbage peromance wise, it doesnt do inter vlan routing on the switch but on the router⌠might need a second switch
really not much more complexity if you already have a 10gig nic and cable run. Making the VLAN in Unifi takes 30 seconds, then just setup the new interface on the workstation and server.
The highspeed VLAN doesnât even need internet/dns/dhcp.
At the same time, there is a forever debate whether with modern hardware Jumbo is relevant anymore.
