I have been using vfr for a while now and this is the first time that I have come accross this problem. I have created a rendermesh from my scene using Micha’s cool tools! I can render the scene on my main workstation but when it somes to rendering it over two machines the slave machines comes up with this error after a while…
error receiving dr scene (0), closing dr session
Connection reset from 10.1.1.2 <10053>
Is this because the rendermesh is too fine and dr spawner can’t handle it or it can’t be sent accross the network? I know that there is nothing wrong with my set up because it works fine with the same scene without exporting it as a rendermesh but the setting is jaggered. You wonder why I’m bothering then? Well Rhino crashes if I try to render the scene normally with such a high mesh. If I an export it as a rendermesh then I don’t understand why it would render over the network.
I removed different objects and mappings and suddenly it worked.
Do you also get an invalid color error message somewhere in the process? I reckon it had something to do with mappings I’ve used, but I’m not sure. Couldn’t repeat the error on purpose, yet…
Thanks for the reply. I know that it’s not bad objects as I always check this before I render.
As for the texture issue, I’m not sure. It’s working fine now but I will investigate this further and try to locate the texture that might have been casuing this if at all. Thanks for the forum links too. I had a quick scan and most of the things mentioned I already do for large renders but I’ll have a look more into it later on.
Could it be that it is a time out error? I have the feeling, if the scene is large that to much time is needed to transfer the scene.
Some weeks before I bought a silent and cool HDD for my project data, but I have overseen, that this HDD is quite slow. Maybe the error is related to my current complex scene and the slow HDD.
Doe’s somebody know a good, fast, silent HDD with 1GB?
Did you mean 1tb? You can get a Solid State Drive which is probably the fastest and because there is no moving parts there is no noise. I think you can get up to about 160gb. If you want larger capacity then you might want to try something like a raptor drive which is very fast.
My scene is transfered over a normal 100.0Mbps connection and the hard drive is normal 7200 speed. I do think that the time out issue might need to be addressed.
Right, I mean 1TB for the project data. SSD would be to expensive for this usage. I will try to copy the project dir to the system SSD and start from there. Maybe it helps for large scenes.
Some times I have the error and some times not, the project data stay the same. Today morning I restart my complete system and it works. If I run in the problem again, I test the SSD for the data.
I use a Gigabit LAN, but I have the feeling the HDD speed is the bottleneck. The HDDis a green series one
Western Digital Caviar Green WD10EADS - 1TB 5400/7200rpm
I think the problem with “green” HDD are that they change between 5400-7200rpm to save power. I have read that the Seagate Barracuda 7200.12 is one of the best for performance and speed http://www.hardwaresecrets.com/article/739/1
I use my raptor drive which is 10000rpm for all the projects I’m currently working on and just move all the old projects to my normal HDD.
Have you tried coping the scene to each slave machine or having the scene on a central network drive?
I’m not sure what is the best way for speed. Manual copy could be a emergency workaround. Central network drive - the files are not faster distributed, since each slave must load the data to the local hard disk too.
So far I have seen the way of the files is: textures from the data hdd are collected at the ASGvis system dir and than loaded to the slaves. I use a SSD system dir for better speed. I will change the data hdd in the next time.
I tried “send to shared folder” per shared folder at the SSD system dir, but the load time wasn’t faster, the slaves loaded anything to the local HDD again. It could be good, if the slaves would load anything direct to the RAM. Maybe this is possible and the “send to shared folder” dosn’t work right.
If the current problem is a time problem it could help, if the DrSpawner get a longer time form loading. Maybe Joe can help with a quick fix. I will send him a PM with a link to this thread.
Here I’m wrong, I have seen now, that if I set at the master send to shared folder “\\Master\VrayDR”, than the progress window of the slaves show me this path too. So, since my shared folder is placed on the master SSD, the slaves should load the maps much faster than save it to the slave HDD and load it from there. I will use this mode as standard mode now.
Could be great if VfR could compare the versions of the maps at the shared folder and the source folder, and if the maps are the same, they are not loaded to the shared folder again. Loading it from the slow data HDD needs some time too.
… but the error receiving DR scene (0) is still alive. Could be good to know, what the reason is and how it can be avoided.
I use Allway Sync to just send everything over to the Slave machine, so an error upon loading the scene there could only be related to the differences in either capacity or speed.
Are your machines equal to each other?
What I’ve just come across is that it works when you swap Master and Slave computers!
It seems to be a relative timeout issue: if the Slave is faster than the Master then drspawner does not crash. At least in my case…
Master (HP Z600):
2x E5530 @2.4GHz
3.23GB RAM
Seagate Barracuda 7200.12 | 500GB
HP SAS 15.000RPM | 146GB
I am working with my Desktop PC when being in the office. So, my workaround is:
- modelling, setting up the scene
- transferring files to Slave machine (via Sync software in my case, which is pretty brilliant if you have several texture folders - eg. [general texture archive] and [in project folders])
- starting renders from the weaker Slave computer
Yes I have often wondered this… Both my machines have the same spec. the only difference is the video card, hard drive and operating system. It’s makes sense though. If the weaker computer can render then there shouldn’t be any reason why the faster machine couldn’t render it.
The master is an i7920@3.6GHz and the slaves are Q6600@3.4GHz. I found, if I get the error (airplane interior with many seats) and than I hide some geometry, the the error is gone. So, it could be that the error is caused by the heavy geometry. I suppose so an internal time out option is set to tight. maybe the developer could help here.
The geometry can’t be manual (or automatic per sync software) shared over the slaves. :-\
Micha,
did you ever try it from one of the Q6600 machines?
Would be really interesting, whether you can repeat my finding!
I guess that any weaker Slave can be addressed as long as the Master can handle the file.
If this is actually the case in general, then it might help exploiting the DR this way until an official patch/new version will fix the issue.
I’m hard work on a tight deadline at the moment and I don’t like to start renderings from a slave. But I found an other trace. In the past I never got this errors. Some weeks before I bought a new master machine and the old master is a slave now. Since this time I have the feeling the network is slower. Today I have seen, that the “new” slave works with 100MBit only, but it’s a 1000MBit card. So, there is a problem. Maybe this cause the slow down of the slave network. It seems to be that disconnecting this slave helps to get the rendering done at the other slaves. Also after reconnect it seems to work better too. I will keep my eyes open for this trace.
Today I installed the latest network card driver for the slave with the to slow network card and changed the cable (this seems to be was the main problem). Now the Gigabit LED is glowing and the rendering of all slaves is much faster. I can render the scene without to hide parts of the geometry, 6.000.000 polygons seems to be no problem anymore.
I think, a Gigabit LAN helps a lot if several slaves try to load the scene/maps during startup - the LAN usage jumps at 90%.
Right on, that makes perfect sense.
However, my network connexion uses a 1GB/s transfer rate. Drspawner keeps crashing over here when a large scene with less than 1.500.000 polygons is being started.
But I’m quite sure that we’ll get to the bottom of this pretty soon.
I’ve tried to check the RAM usage but it takes only one second for drspawner to crash. So I didn’t see anything on the system monitor…
Still, it works when I start it from the weaker machine.
But usually the weaker machine is not the one that is used to create the content.
Especially when work is being in progress, it doesn’t really help to downsize and mesh the model just for a quick preview. I’m not even talking about maps, yet. I know that one map is loaded several times in some cases and baking the Micha cake is my favourite workaround - only it works merely for finished models and scene setups.
