Is Network Render Worth It?

johnmeyer wrote on 5/2/2004, 6:13 PM

I have now rendered several projects using network render. Admittedly, I only have one render client, but in every case so far, the network render has taken longer than the same render on a single workstation. The killer is the stitching time. I just rendered a ten minute music video. It took one hour and five minutes with my 2.8 GHz PC by itself. When I did it using network render, it rendered faster (about forty minutes), but then the stitching took another thirty-five minutes. Why stitching 2 Gbytes would take so long, I don't know. I have 512 Mbytes of RAM, two 120 GByte, mostly empty drives, both with Ultra DMA enabled.

Maybe one needs 3-4 network render clients, or maybe there is something wrong in the way my disk subsystem is configured (which I doubt, but I am open to suggestions). At any rate, for me, network rendering is definitely NOT worth the time it takes to set up and fiddle with (which is a whole 'nother post for another time).

Back to post

Comments

B_JM wrote on 5/23/2004, 12:05 PM

the stitching is a real bottle neck ... as in a major use of time needlessly because its writing to the same drive array for one thing (which means i have to set up .5 tB and up raid just for this featureto alow for double the amount of space required) and it just seems to do it very slowly as another thing...
digital fusion has network rendering and farms out each frame to next machine that is ready .. and renders to a complete file (or file seq) ..
it will auto find nodes and you can add or remove nodes while rendering - of course it also a much more expensive program , but you can buy render lic only.
you can adjust the size of the temp files in vegas netowrk rendering -- i think (not proven or compared) if you use higher values - it should speed things up on big projects ..

johnmeyer wrote on 5/23/2004, 12:54 PM

Liam_Vegas:

Give that man a cigar!

That is some really great testing you did, and your idea for avoiding the stitching is fantastic. I really appreciate your effort and your ideas. It seems to confirm several things I suspected:

1. I didn't think the 100 Mbs network was going to be much of a bottleneck. There were several posts awhile back about this, including one with some good calculations. However, I think the thing that was missed is that while the specs on disk drives make it seem like they can sustain very high data rates, in practice most disk drives can't accept data at rates that are that much higher than can be pushed over a well-constructed 100 Mbs network. (Having said all that, you DID get a 15% reduction in rendering time -- from 270 minutes to 230 minutes -- by going to Gbit networking).

Also, even though the Sony spec says you need a switch, if no one else is using the network, I don't know whether a switch will give you much (or perhaps any) improvement. I could be wrong on that one though ...

2. Your idea on the stitch file is brilliant. Why stitch the darn things at all? Make it an option, and automatically create a VEG file that puts the files on the timeline so all you have to do is print to tape from the timeline. Did I already say this is a great idea?

Actually, now that I think of it, there is a way take your idea a step further. If you put the unstitched files on the Vegas timeline, then Vegas will have to create SFK files, something that can take several minutes or more. Also, when you start the print to tape from the timeline operation, Vegas insists on creating a bunch of W64 audio files. This can take quite a long time as well. However, if instead you open the Vegas capture utility and go to the "Print to Tape" tab, you can load all those unstitched tiles and print them right away. If this is a good idea, Sony could probably find a way, at the end of a network render to automatically launch the Capture app, pre-load those files into the print to tape area, so all you would need to do was click on the "Record to Device" button.

B_JM wrote on 5/23/2004, 1:15 PM

that would only make sense if you are creating dv or printing to dv .. many of us don't and dont care much about dv .

johnmeyer wrote on 5/23/2004, 5:54 PM

that would only make sense if you are creating dv or printing to dv .. many of us don't and dont care much about dv

Ah, you are rendering to MPEG2 then? You must have several Vegas licenses then (lucky you!). However, the same idea would apply. At this point, Vegas cannot concatenate several MPEG files. However, if you have the Womble MPEG Wizard, what you could do is cancel the render as soon as all renderers are finished and the stitching starts. You then would drop all the files into the Womble program and let it combine them to another drive. It works extremely fast, and you would get the considerable added speed of going between different physical disk drives.

busterkeaton wrote on 5/23/2004, 7:32 PM

Ah, you are rendering to MPEG2 then?

Think higher bitrate, not lower.

B_JM wrote on 5/23/2004, 7:59 PM

not to mpeg2 -- not with network rendering anyway

BrianStanding wrote on 5/24/2004, 6:04 AM

Sheesh! A 3000 and a 2800 working together only produce a 9% savings in render time? Hardly anything to write home about! I would have hoped you would see closer to 50-60% speed increases. Liam, what kind of project was the 4-hour render? What FX, etc. were you doing, and what format were you ending up in?

Anyone have any experience with, say, After Effects network rendering, who can say how this compares?

I agree with Liam that the whole stitching function seems time-consuming and unnecessary. I like the .VEG file idea much better.