Hi gang,
We have multiple Flames running over our network in our office. We have one dedicated Flame suite with other “working” stations around the office. Lately, when we’ve been running sessions out of the main suite while connected to one of the “working stations” we’ve been experiencing super slow render times (like minutes just to render supers in the timeline… whereas this should be taking seconds). We’re essentially using the Flame in the suite to run the session, but working off of the networked machine. I’m having a hard time understanding why this would be happening. If you were to physically get up out of the seat and walk to the networked machine and run the same render locally, the render time drops substantially. Why would working over the network reduce the render time on the machine that’s doing the render? Doesn’t make sense. Can someone explain to me how we can try and solve this issue OR what’s the reasoning behind the slow render times over the network? We have a fibre connection between the machines in the office.
The machine you’re logged into and working on is the one doing the render. It’s using the other machine’s storage, so it has to read and write the media at network speeds instead of locally-attached speeds. That shouldn’t be seconds versus minutes unless something is majorly wrong with your network, though.
Thanks for the quick reply! but I’m still failing to understand how that works. The flame in the suite is only being used as a source to connect to the networked machine. Isn’t the networked machine the one doing the render? The project is still on the framestore of the networked machine, so to me this means that you’re really working locally on the networked machine but just using the suite to connect to it? Why would it be rendering over the network?
Negative. Unless you are talking about Burn, the workstation the artist is driving is the one doing the rendering. It is using the networked machine like a server, reading and writing the footage.
Another thing to check would be the Resource Manager on that host machine. I find if I have renders that should be seconds that are now taking minutes, this is the issue… Check it out. When you’re getting the slow render times, how much free VRAM do you have at that moment?
Never tested it, but I’m curious what would happen, when you use background renderings, while switching the flame’s background reactor to the other machine in the settings. Don’t know if that does something or not.
The terminology you are using here is a bit confusing. So I’m going to try and summarize your scenario to make a bit more sense.
You have a “primary” flame in which the project actually resides on. This is where the database is kept and assuming the storage resides also.
In addition you have secondary Flame/Flare machines, which utilize the “primary” machine as the Host when choosing a project in flame. Let’s call this a “remote” project.
When using a remote project on a secondary machine, the rendering is slow. You say you have “fiber connection between machine” but that is very generic explanation. Please provide further details.
When rendering something on the “primary” flame, it is fast. When rendering the same thing on a secondary Flame via remote project, it is terribly slow?
There are some configuration files which control what network interface is used for what purpose with flame. So there is a possibility that Flame is actually NOT using your Fiber interface, and the processing on the secondary/remote Flame is starved for data via a slow network.
Assuming Linux, run ip a in a shell to get a list of all network interfaces. Make note of the high speed interface name.
then check /opt/Autodesk/cfg/network.cfg
Look for the Metadata= and Data= entries. They should be using your high speed interface.
Example for my workstation.
[alan@ws104 cfg]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:be:43:bd:65:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.104/24 brd 192.168.1.255 scope global noprefixroute enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::2be:43ff:febd:6535/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp156s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 24:8a:07:11:42:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.104/24 brd 192.168.10.255 scope global noprefixroute enp156s0
valid_lft forever preferred_lft forever
inet6 fe80::268a:7ff:fe11:4284/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether b0:4f:13:ce:eb:ac brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:23:ac:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
Metadata=enp156s0
Data=enp156s0
Network speed between Flames would be the first thing I’d check. In addition, you really might want to implement a proper Project Server as using an actual Flame workstation as the server is not ideal. See my videos regarding this.
Please see this article. if you need further clarification, please open a case with support and we can get it straightened out.
Thanks for all the replies everyone. We got it sorted out. Turns out all we had to do was enable “True” under the shared media storage option in the setup.
