[Beowulf] Re: 3d rendering cluster

[David Mathog]

> Message: 3
> Date: Tue, 24 May 2005 13:48:15 +0200
> From: Paul K Egell-Johnsen <paul.k.egell.johnsen at gmail.com>
> Subject: Re: [Beowulf] 3d rendering cluster
> To: beowulf at beowulf.org
> Message-ID: <de9a310e050524044864b89bef at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Thank you very much Robert, you told me stuff I should really have
> found out of on my own; and some things I do know.
> 
> I've contacted the different vendors we're considering for the
> software. I'm pushing for linux solutions because I know we can
> customise the os and software to make better use of the overall
> resources available. Unfortunately a lot of the other tasks we're
> going to do will require Windows solutions and then we're pretty much
> left to rely on sometimes very expensive solutions, and sometimes very
> unexpectedly cheap solutions, like FX Teleport for my sample library
> playback (ie. symphonic orchestra on a computer farm solution) needing
> nothing but a network connection and  a cheapish server software on
> each computer.
> 
> I didn't specifiy the size either, it seems like 10 to 20 Dell boxes
> would fit the bill, but if we can find some good integrators with
> better prices  we'd probably end up with even a bigger farm, though an
> important point would be the storage solution which for the video
> post-production would require much more than for the rendering with
> regards to the bandwidth to the storage solution.
> 

Parallel image rendering is one of those applications where you
have to be really careful how you store the output files.  If you
just write them all to a single common NFS directory it will hammer
your network to bits.  This is because these applications tend
to write out a line, or part of a line at a time, resulting in
a large number of packets.  Conversely, if you render it all to
local storage that problem is avoided but you then have to be careful
when all rendering is done not to move it all back to central
storage in one fell swoop, or once again your network gets hammered.
So no matter if it's windows or linux you're probably going to
want to queue the movement of completed image files back to
central storage.

Also, the pvm and mpi versions of POVRAY, while faster
than on a single CPU, are not nearly so fast as N separate runs of
POVRAY running one each on N nodes.  In other words, if you have
20 nodes you might be able to render 14 frames with the parallel
version in the same time you could render 20 frames in the
single threaded versions (running on each node.)

Regards,

David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech