Hmm. I don't mean to skirt the central issue too widely, but in my
experience, rendering simultaneous Nuke jobs on a single machine that are
doing anything more complex than converting files (or something equally
simple) results in high enough instances of instability and performance
degradation that the net gain often isn't worth it. To put it (possibly too)
simply, you either end up waiting far too long for your jobs to finish, or
you spend inordinate amounts of developer time doing something like building
a load-balancing system intelligent enough to avoid issues with memory
corruption and instability.
Nuke's memory usage patterns are still somewhat unpredictable, especially
when 3D setups are involved, so unless you have some method for weighting
and distributing scripts across nodes based on their current tasks, this
kind of thing will almost certainly continue to occur.
Just some thoughts...
-Nathan
-----Original Message-----
From: John RA Benson
Sent: Tuesday, January 29, 2013 10:37 AM
To: [email protected]
Subject: Re: [Nuke-users] Tiff metadata / tags
We had this issue on a project awhile ago (using Nuke5.1), where systems
were going into swap. Say, you have 3 jobs on an 8 proc machine, using
4, 2, and 2 procs of memory. One job is a real mem pig, using all the
system memory, so the other 2 jobs waited. Really, all 3 jobs wait
because the other 2 are pigs too. It could take literally hours to do a
3 min frame. Consequently, all 3 jobs suffered. Even when all the frames
finished, it seemed the only way for the system to fully recover after
getting easy jobs was a reboot.
So, recently, the farm was saturated. Some jobs were taking longer than
they should have, and I hear artists complaining but it's hard to get
enough info to debug anything. I don't know if it's the same issue. If I
could programatically recover the day's renders and check render times
and if they took longer than they should have, then correlate that to
specific machines, we might have an idea which systems are sketchy. Or
we could just have the artists get their submit parameters correct too.
JRAB
On 01/29/2013 06:40 PM, Nathan Rusch wrote:
Yup, like I said, it's only a good option if you've got the time (and CPU
power) to burn.
What kinds of render issues are you running into exactly?
-Nathan
-----Original Message----- From: John RA Benson
Sent: Tuesday, January 29, 2013 9:24 AM
To: [email protected]
Subject: Re: [Nuke-users] Tiff metadata / tags
ha - yes, but that kind of ruins the render ;)
the issue pops up as we saturate the farm (of course) and I think sys
would have me fired if I did it myself anytime in the next 3 months!
Cheers
JRAB
On 01/29/2013 06:15 PM, Nathan Rusch wrote:
I don't think Nuke will currently let you write arbitrary TIFF metadata,
but a simple solution (if you've got the time to run test renders) would
just be to do a Text node burn-in with [info hostname] as a text
expression.
-Nathan
-----Original Message----- From: John RA Benson
Sent: Tuesday, January 29, 2013 1:08 AM
To: Nuke user discussion
Subject: [Nuke-users] Tiff metadata / tags
Hey out there -
Does anyone know of a way to embed certain tiff tags into a (tiff)
render? A ModifyMetaData node doesn't seem to do it unless there is a
magic key I don't know of.
We are rendering tiffs and having some odd render issues. I'm hoping by
adding TIFFTAG_HOSTCOMPUTER
(http://www.awaresystems.be/imaging/tiff/tifftags/hostcomputer.html) we
might be able to ID the renderbox and discover if it's something to do
with specific machines on the farm.
hmm - possibly some python afterFrameRender trick if there's not a
simple way I've overlooked?
Any other ideas on ID'ing which box a tiff is rendered on is welcome...
rendering uncompressed, 16 bit if that matters.
thanks -
JRAB
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
