Rendering farm?
Dan Ritter
dsr-mzpnVDyJpH4k7aNtvndDlA at public.gmane.org
Fri Oct 9 19:44:33 EDT 2009
On Fri, Oct 09, 2009 at 07:37:25PM -0400, Richard Pieri wrote:
> On Oct 9, 2009, at 6:39 PM, Scott Ehrlich wrote:
> > I received at least one email suggesting a Windows-based rendering
> > farm - likely to consist of a few rack systems all running 64-bit
> > Windows. I read an article on Tomshardware which gave some decent
> > insight. What can list participants offer on this concept?
>
> Virtualization is a nifty thing, and like every nifty thing it gets
> misused :). Don't use it for your render farm. Render farms are a
> lot like Beowulf clusters (and are sometimes set up *as* Beowulfs).
> They take big tasks and break them down into smaller pieces. More
> nodes = more pieces = faster render times. Virtualization is not a
> win in this environment because your host limits the number of
> concurrent VMs. Virtualization is not a win because you want to be
> able to swap out a failed node as quickly as possible -- and that is
> neither easy nor fast if you have a hardware fault on the physical host.
Yup. The key to a render farm is the old-fashioned notion of
batch computing. Set up your job management system, and let
people submit jobs to it. Finished jobs are delivered; if a
machine in the farm breaks for whatever reason, that part of the
job is allocated to a working machine. If a job fails for its
own reason, the whole job is kicked out and returned to the
submitter along with the error messages.
http://www.linux-mag.com/id/1184 is old but useful.
-dsr-
More information about the Discuss
mailing list