Error Receiving DR Scene

[Sando]

Hi all,

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
[AcceptProc] 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.

Cheers,
Sando

[uffepep]

Re: Error Receiving DR Scene

Hi

I have exact same problem although my error is
[AcceptProc] Connection reset from 10.1.1.2 <10058>

Any help would be appreciated. The DR works fine with a simple model (with textures/map)

[frip51]

Re: Error Receiving DR Scene

I've had a similar issue, although I didn't get to see the error message because the window closed before I could read what it said

http://forum.asgvis.com/index.php?to...44314#msg44314

maybe check for socalled bad objects?

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...

[Sando]

Re: Error Receiving DR Scene

I've had a similar issue, although I didn't get to see the error message because the window closed before I could read what it said

http://forum.asgvis.com/index.php?to...44314#msg44314

maybe check for socalled bad objects?

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...

Hi Matt,

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.

Thanks again,
Sando

[Micha_cg]

Re: Error Receiving DR Scene

Now I have the problem too and found no solution. :-\

[Micha_cg]

Re: Error Receiving DR Scene

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?

[Sando]

Re: Error Receiving DR Scene

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?

Micha,

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.

Sando

[Micha_cg]

Re: Error Receiving DR Scene

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

not optimized for speed.

[Sando]

Re: Error Receiving DR Scene

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

not optimized for speed.

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?

[Micha_cg]

Re: Error Receiving DR Scene

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.

Thanks for the HDD advice.

[Micha_cg]

Re: Error Receiving DR Scene

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.

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.

[frip51]

Re: Error Receiving DR Scene

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


Slave (Lenovo W700):
Q9300 @2.53GHz
2.49GB RAM
2x Hitachi Travelstar 7K320 | 160GB


...big difference, huh?




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


Hope that helps!

Cheers,
matthias

[Sando]

Re: Error Receiving DR Scene

@ Matthais,

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.

Sando

[Micha_cg]

Re: Error Receiving DR Scene

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. :-\

[frip51]

Re: Error Receiving DR Scene

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.