PDA

View Full Version : SCREAMERNET - takes long time to write files



Stardust
06-20-2017, 09:38 AM
HI,

Been playing with Scremaernet on 3 dual CPU nodes... seems to run nicely....

After some experimentation...

I've copied to BIN folder to each node (Dunno if it make a big difference having the LWSN.exe executed locally or over the network)
I execute up to 3x scre4amernet instances per dual CPU node (Each CPU has 4 cores).. this seems to give me the best "yield" so far....

Also, on 2 of the nodes when finished rendering, it takes a loooong time to write the files, CPU utilization drops almost to 0%.. yet the files take minutes to write
and I wonder why this is and how to fix it..


Thnx

Scazzino
06-21-2017, 01:47 PM
Could be a network issue? What's different about the two that are slow to save vs. the one that's not?

Stardust
06-22-2017, 09:24 AM
Thank you!

I'm investigating this right now...

the 3rd system is offline and needs some other checking...

So I'm left with 2 Identical systems, exept HD's are different...
Same CPU's - RAM - MOBO's..... Win 10 Enterprise LTSB

I also have a 16 minute rendertime difference ( 10 mins vs. 26 mins, which is crazy for 2 identical systems), dunno if the rendertime display on LWSN includes the time it takes to write the image to disk...

I just had an image finish on the first node and it took less than 2 seconds to write the image

Scazzino
06-22-2017, 10:13 AM
No problem.

I'd run a simple test locally on each machine using LWSN to render in standalone mode. That will eliminate any potential network issues. You can use the free lite version of DLI_SNUB-Launcher to run a quick background LWSN render one at a time on each machine if you don't want to do it manually on the command line. To eliminate the network as a possible issue install LightWave on each node if it's not installed yet. Then just put DLI_SNUB-Launcher in the LightWave folder on each machine. Then drag a scene (with a proper content folder structure and RGB output path already set properly) onto the DLI_SNUB-Launcher icon and it'll launch and render the scene in LWSN in the background. If those tests consistently give you very fast save times, then it could be a network issue.

Here's the download.
http://dreamlight.com/shop/dli-snub-launcher-lightwave-3d-network-rendering/#download

Here's a quick standalone drag-and-drop 1-2-3 tutorial for a quick local background render test.
http://dreamlight.com/shop/dli-snub-launcher-lightwave-3d-network-rendering/render-tutorials-with-dli_superballs-benchmark-scene/#StandaloneTutorial

BTW: Do any of your hard drives go into a hibernation or sleep mode? I have a small RAID drive that goes to sleep, so any saves when it needs to wake up are delayed a bit.

Stardust
06-22-2017, 12:56 PM
Thank you;

I found this article:
https://www.tenforums.com/network-sharing/2806-slow-network-throughput-windows-10-a.html

I did what they sayd but didn't test it (Silly me) and immediatelly did run a tool called TCP Optimizer on all involved machines and now it seems to be running great (So Far).

The only noticeable difference I found was that on the (Faster) system I had also VirtualBox installed, I also installed it on the other machine then, just in case VirtualBox did some messing with network drivers, so now I don't know which of the 3 was the solution, lol

I do have 2 RAIDS on the host where everything is being saved, but that shouldn't make a difference, because it would be for all machines the sames.

Now all nodes render at about the same speed, so I guess that LWSN includes the time it takes to save the frame in its statistics.

Scazzino
06-22-2017, 02:03 PM
Glad you got it going!

I'll add a link to that page in my troubleshooting sections (http://dreamlight.com/shop/dreamlight-constellation-lightwave-3d-network-render-controller/#sctab12) in case any other Windows users run into it when trying to set up ScreamerNet with my render controller - DreamLight Constellation (http://dreamlight.com/shop/dreamlight-constellation-lightwave-3d-network-render-controller/).

It did sound like a Windows networking issue. I had run into a similar Windows networking issue where LWSN would read old commands out of the SMB network cache and report "ignoring duplicate command." It wasn't the controller sending a duplicate command, it was just the LWSN node reading the old command out of the cache.