[Frankwoll]

I am experiencing a new problem with animation job render. I have two Dual Xeon's that are almost identical. The machine with the license, monitor and manager renders a frame in 3 minutes. But now the second twin machine will take 83MIN to render the first and subsequent frames.

Any ideas as what I can do? It's rendering to the time set in the time limit instead of the sampling level? But not rendering at the higher SL that the time limit would let it reach. It's like there is a speed governor on the SL so that it will reach the specific SL I have set of 12.4, but it will take 83MIN to reach that SL.

Any Ideas?

[Frankwoll]

I just discovered - when I kill the slow rendernode and restart that node after the job is already going and the 1st rendernode has completed a few frames - the slow node picks up speed and renders as fast as it's primary twin.

Is there a setting somewhere that makes the second node act so strangely when it's included in the job submittal?

Thanks for any insights.

[T0M0]

What OS are you running on the slow rendernode and main workstation ?

[Frankwoll]

Both Machines are running Windows 7 Ultimate 64, XEON ES-2630@2.3GHZ DUAL CPU. The primary machine has 32GB RAM and the secondary has 16GB.
Other than that they are both the same T5600 DELL servers.


After doing the trick of starting a job in the Network Monitor with the primary rendernode running - I let a few frames render and then launched the rendernode on the secondary machine. It was identified and picked up the next frame and ran as fast as the primary.

The next morning I checked the Network Monitor and about 50 frames in to a 138 frame job it looked like the nodes had stalled out. I was going to cancel the job and restart when I noticed that the Network Manager showed that all frames had actually rendered and the job was completed - it was just that the Network Monitor hadn't updated. Possibly related?

[T0M0]

I noticed same slowdown on my nodes, also running on Windows 7 x64.

When I opened Task Manager, maxwell.exe process wasn't using CPU at all and usage was throttling,
then I saw process svchost.exe was using one core and was related to Windows Update (right click on process and choose Go to Services).

You can try this by yourself. Just before you launch rendering, open Windows Update and click on Check for updates.
Result of this will be huge slowdown.

There are few ways how to avoid this:
- set Priority to Normal in Maxwell Render settings (where you set final SL, time, etc ...)
or
- completely disable Windows Update in Services

In my case, this was causing the slowdown.

[Frankwoll]

Thanks,

I'll check in to that. It does seem odd as this was not happening in the past. I'll do a network test and see if that is the issue. I appreciate the lead.

[zparrish]

I just wanted to add what I'm experiencing too. I'm running MW 3.2.1.4 and unless I set the priority to "Normal" on all of my render nodes, I can't guarantee they will render on more than a single thread. It's hit or miss, but sometimes it will make every node that's set to low priority render on a single thread.

That's interesting that it's potentially tied to Windows Update. I never would have guessed that. I did notice though that if I change the priority through Process Explorer in mid render, it will jump from a single thread to the thread threshold set in the Maxwell Render Network Preferences.

[T0M0]

Yeah, I spend few days with debugging and looking what is causing this slowdown.

It was very strange for me, because after restarting the node everything was running fine and after some time when I added new job in queue slowdown appeared again. And then I found that service for Windows Update is launching with some delay not immediately.

Now I have Windows Update service set to manually.

[acrighton]

Concur with the Windows Update thing being the cause of the extremely slow rendering on network nodes. I've experienced this a number of times and only recently stumbled on the Windows Update feature being the culprit. I ended up disabling all Windows update features and all is good...

[numerobis]

Yes, i also recognized that the slowdown can be immense. Maybe there is some possibility to block it when Maxwell starts? Or at least place some warning in the documentation?

[burnin]

Confirming issue, still present with 3.2.1.5.

[Fast Render Farm]

Another possible cause for abnormal slowdown in a render node is the Antivirus. If the machine is only used for rendering you can (and should) disable it.

[F. Tella]

Hi,

We also found node.exe can cause some trouble with rendering speed. It is installed by Adobe and runs in normal priority mode.

Here is more information about it: http://www.file.net/process/node.exe.html

I hope this helps.

Best,
Fernando