@finnjaeger - well that might stop things dead in their tracks…
Thunderbolt bridge on macOS and i’m not quite sure what on Linux?
I don’t have any recent thunderbolt equipped Linux workstations to test - only some legacy mac trashcans which are, well, legacy…
1 Like
yea…
thunderbolt networking is direct and I can change MTU to 9000 as that isnt even switched.
I run QuTS as my distro so it has all the TB stuff with a Virtual switch built in its idiot proof
1 Like
what the hell,
i just set my whole network to be MTU9000 lets see if anything breaks.
yolo.
1 Like
guys… you are making this much harder than it needs to be.
- No inter-vlans/network routing is required.
- Having a single flat network @9000 will mean every single device you attach will need to be manually set to 9000, wifi, IoT, AppleTV, iPhone. Everything. don’t do this.
- Create a separate HighSpeed VLAN @9000, no internet, no Gateway setting, no DNS setting. DHCP if you want. Just high speed internal data.
For machines that need high-speed data, connect to both normal and HighSpeed VLAN.
For machines that do not need high-speed data, leave as is. No changes to the current infrastructure or configuration are needed.
Keep it simple. This is the way. I won’t chime in anymore on this. If you want further discussion, ping me.
1 Like
haha I get it, but → unifi doesnt let you have seperate MTUs for each Vlan it seems and blah blah blah…
my plan is to use thunderbolt for the framestore data so then thats fine 
and does what you mean
1 Like
it doesn’t matter. enable it globally. everuthing still works,
1 Like
yea
The issue we have with SMB is since Autodesk doesn’t support it, you can’t delete clips from the SMB folder you have written to. You can delete images, but not clips. You have to exit the software, delete and then restart. You also can’t overwrite clips with the same file name.
Flame on Linux
1 Like
ah yea true ive seen this
this NAS for example will only be used as a framestore
did a test with uncompressed UHD frames via 10Gbit NIC
NFS
W: 400MB/s
R: 650MB/s
SMB
W: 1.2GB/s
R: 1.2GB/s
SMB seems to be FAR faster and gives me constant line speed in real-world read and writes from inside of flame. at least on my mac studio clients.
Left test is NFS , right one is SMB …
2 Likes
I came across an article/post that compared performance on properly configured hardware for video playback off a NAS comparing MTU1500 to MTU9000 configuration. For whatever reason, and they could not explain it technically and they went back and thoroughly checked everything, MTU1500 actually performed better. I have no hope of finding it but I remember them theorising that somewhere in the chain there must have been a piece of hardware that although configured to MTU9000 may have had a driver issue or something. Anyway, have tried the same thing on NAS storage/networking setups and never noticed a difference myself either.
I’ve been fighting with this for a while at a site we work with. Most of the time, I don’t have to completely exit out, but it will take it’s sweet, sweet time in letting go of the files. I’ve talked to a few engineers, and it has something to do with smb file locking. Regardless, it is an utter pain in the ass.
1 Like
probably depends on the smb implementation?
No issues here overwriting stuff but then, this is just framestore and not shared media storage (we have thay on lucid)
I have to totally exit out. And when you’re exporting and doing qc on files it is really annoying. I often will have to exit and restart several times a day just for this reason.
If someone has a better solution I’d like to know.
In a land and time far away, I knew more of the guts of NFS. Back in the day of netoworkign and on SunOS.
One of the things that was good/bad about NFS, is that it was built on top of the RPC (remote procedure call) protocol that back then was a common way of building cross-server APIs. In a quick scan of the newer NFS versions it’s not clear if that is still the case or if they have come up with something more contemporary.
The reason that may matter, is that it was a reliabile implementation, but also has a certain amount of overhead. Which doesn’t matter all that much in every day use of a remote file system with average files. But may take a bite of the performance when you shuffle massive files at large speed.
Just a consideration / explanation - which would require further validation.
PS: After a bit more reading, it seems it’s a non-trivial answer. Some say NFS is better on small files, but even on large files. Other references speak of read/write being better on one and worse on the other. Lastly there seems to be a difference in allowing asynchronous (buffered) writes, absence of which impacts NFS more than SMB.
1 Like