Hi Daniel,
Thought I'd take this offline for a second to debug.
Do you have any windows render nodes in the mix,
or are you entirely unix/osx?
If so, I don't think the client side caching/file server issue
is afoot, as I've only seen that issue with windows render nodes.
> tail lets me see the output of the nuke render command itself in real time
> from my NFS mounts.
When you ran that test, did you run nuke on a different machine
than the tail? ie. run nuke on a render node, and run the "tail -f"
on a workstation?
> Our current Nuke submit is written in Perl; is there a Python version already,
> or are you recommending that we try to write our own from scratch?
No, not what I meant.
If the problem is nuke buffering its stdout, there's nothing the
submit script can do to change that; each executable (in this case,
nuke) has its own internal stdout buffering that's handled by the
C/C++ library the executable is linked against.
So nothing short of modifying the actual application can change
the app's stdout buffering.
Even though we don't have the source code to e.g. nuke and maya,
these programs do have their own python front ends which does give
us access to the application's internals.
So what I was suggesting, assuming this is the problem,
is to try adding some code to nuke's startup scripts that attempts
to disable stdout buffering. This way when nuke starts, stdout
will be unbuffered.
But we should first see if we can replicate the problem
outside rush, so that you can test it easily.
There's nothing magic about how rush redirects the output
of the renders, so running the shell test I mentioned
should replicate the same problem, assuming the test simulates
the writing being done from a different machine than the read.
We should maybe interact directly to pin it down.
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|