[rogerteddy]

I just read throu the postings and I am glad I am not the onlyone having that issue

can someone confirm this
-th: 0 or 2 dont effect something
all the same CPU and PC

[jomaga]

rogerteddy, you have to use network paths in mxs, bitmaps, image and mxi locations

[tom]

The differences in time column could be happening due to refresh intervals of job tree and it's normal. Even they are perfectly same PCs, the scene is not distributed to all at the same time, it's simply not possible to beam up MXS to many PCs in nanoseconds and make them start. You would say but it's not taking too much time so the difference shouldn't be too much due to this. But this initial difference in distribution causes delays in refresh intervals due to reached SL times. This means the nodes rendering at SL7 absolutely received the scene earlier than the others and the others were still trying to distribute among them while some are dealing with voxelization and some of them are really waiting for the bytes standing still. So, it's something normal.

As I've said earlier in this thread the major problem was about merging and we already fixed it some hours ago. It will be available in the next update.

By the way, is your Z drive a mapped network drive already?

[rogerteddy]

z: is a mapped network drive
the PC in question have 50% CPU usage during the renderprocess
threads 2 seems to be ignored from some slaves
threads 0 same effect

for each test I did some PC are th=1
not the same PCs all the time
slaves are effected (infected randomly

dont have time to investigate it more deeper
14hour work a day is too much +(

[b-kandor]

Hi Tom,

I do have a screen capture of 3 systems writing incorrect mxi files (i.e. the highest sl is found in the temp directory of one of systems - whereas the mxi specified in the render options is a low sl file).

As soon as I shrink the video I'll upload a link.

Thanks,

Kandor

[b-kandor]

Hi Tom,

I've given up trying to compress my screen cap below several hundred MB's so I took some screen shots instead:

1: Show starting scenario (3 machines)

2: Render options set (although I did change threads to 0)

3-6: These show that displaying a coop image while rendering shows a lower SL than what the 3 nodes merged should equal




7-12: Shows the steps of stopping and merging




11-15: These show me stopping the render, then I open the mxi specified in the render options and it's got the same sl as the lowest node. Then I open the temp/cooperative.mxi on the manager machine and it has a high sl.

[tom]

Yes, at this step below, one of the node is saying "merging" while another one is saying "writing final", so it's same bug with your 3 node setup. It just didn't happen with 3 node here so it looks like the problem was always there when more than 2 nodes are rendering. But the good news is, this is fixed and you'll have it soon.

[b-kandor]

Thanks Tom....

[ishook]

Yay! I can't wait for the network fix!

Will the fix happen to solve the resume problem where some (or all) of my nodes fail?

[tom]

Will the fix happen to solve the resume problem where some (or all) of my nodes fail?

There's no known bug which makes some of them fail. You need to investigate more what's happening to them.

[tom]

a remote way to restart them from the controller would be awesome

Depends on the reason why a server doesn't respond but they are generally due to crashes and if this was technically possible we would never let them fail already, they would just restart themselves. At the moment whenever this happens on any node, you should shut them all and later restart. Partially restarting them would fail. We will try to improve this.

Thanks!