Am I the only one with great Network Rendering results? This stuff is amazing!

shogo wrote on 6/13/2004, 7:37 AM
I just got my Vegas 5 in yesterday around 3:30 PM and haven’t stopped playing with the network rendering since then it’s almost 9:30 am now! I have to say I am really impressed with the network rendering though I was really not expecting much after reading all the other users post about how it didn’t work that good. This has to be one of the coolest things I have seen in a long time. Let me give you the specs on my computers and network.

Edit machine
P4 3GHz
1Gig ram
WinXP Pro
Gigabit NIC
Vegas 5 Full
several large HD’s yada-yada-yada
but the kicker is I have a gigabit switch that I picked up from Compusa for $99.00

File server
Server 2k3
Dual Xeon 3 Ghz
4 Gig ram
800 GB Raid 5 drives
Gigabit Nic
Render Node
(all my video and media reside on this machine)

Toshiba Laptop
P4 3Ghz
1 Gb Ram
80 Gb HD
XP Pro
100 MB Nic (unfortunately I can’t find any one that makes a PCMCIA Gigabit NIC ;-)
Render Node


This is what I have come up with so far…
After trying to get it working for like two hours, which entailed having to set all my computers “Primary DNS suffix of this computer” underneath the computer name tab
And figuring out what I was doing wrong with the file mappings – They really need to have better instructions on this…

I ran some of these tests two and three times with the same settings to make sure I had not made a mistake because I couldn’t believe that it was getting done so quick on some tasks compared to stand alone rendering.

One thing I noticed is stitching across network on 100Mb with default is terrible (unless all your media is on your edit computer) it’s like it pulls each one of the individual files over the network then sends the stitched file back over and repeats this step over and over whereas when you specify the file server as the Render Host it just stitches it locally. On a gigabit network it’s really not a big difference maybe 5-10% slower but on a 100Mb it is incredibly slow so if all you have is a 100Mb network make sure you specify the Render Host as the computer that actually host’s the media on the timeline. The way I am setup is all my videos and media I keep on the server and edit across the network which for most people may be backwards but my server has tons of storage and is very fast.

Gigabit seems to help by about 50-60%


Tests I ran
Render alone with two Magic bullet FX’s this was kind of overkill but I wanted to test it out, the clip was only 30 seconds long ouch….

19:01 minutes when ran with no network rendering

Gigabit Settings

6:05 when nodes set to gigabit and host was set to file server.
(That’s insane imagine if that 30 second clip were an hour long that would take 36 Hours but rendered on my setup with network rendering would roughly be 12 Hours!)

6:15 when all nodes were on at Gigabit and host was on edit machine not file server

100 Mb Settings
8:27 seconds when host was set to file server and all network settings were at 100Mb

22:58 when the default host was my edit machine and not the server while set at 100 mb



A video clip that was 2:44 seconds long with a mild secondary color correction took

22:29 render stand alone

Gigabit Settings
3:02 default Host Render
2:47 file server Host Render Near real time!


100 Mb Network settings

Default Host Render - Stopped it at 11% on the stitching part it was near 15 minutes blah couldn’t wait!

5:31 file server Host Render


Man this is awesome!!!!
The only thing is I wish they would change the limit of two render nodes, or at least let us by additional ones individually for say $25.00 or something it seems really strange that it goes from either 2 nodes to a site license which I don’t even want to no the price on that.

Oh and if some of my calculations are off go ahead correct me I’m to tired to care at this point ;-)

Comments

Grazie wrote on 6/13/2004, 7:43 AM
Excellent! Now, can you get to London UK and sort this out for me too?!?!?

Thanks for taking the time to write it al up .. NOW GO SLLEP!!!

Grazie
shogo wrote on 6/13/2004, 7:55 AM
I'm wired now can't seem to come down off all this Dr. Pepper and chips I've been downing!
shogo wrote on 6/13/2004, 7:57 AM
What's the problem? I bet I ran into it somewhere along the line today might be able to help out.
johnmeyer wrote on 6/13/2004, 11:19 AM
on a 100Mb it [stitching] is incredibly slow so if all you have is a 100Mb network make sure you specify the Render Host as the computer that actually host’s the media on the timeline.

I wrote several of the original posts a few months back, about the problems with network rendering, along with a few suggestions, workarounds, etc. However, I quit using the feature because the stitching time pretty much ate up the time saved. I am therefore intrigued that you were able to dramatically reduce stitching time on a 100 mbs switched network (which is what I have).

As I look at your configuration, I think the reason you got results that were so much better is that your server is a dual processor computer. Therefore, when the video assets are already on this fast computer, it ends up doing most of the rendering. Why? Because by the time video goes to the remote, single CPU machines, gets rendered, and then gets shipped back to the server, the dual CPU computer has probably rendered 2-3 more chunks of video. Thus, I bet if you look at the real-time readout that shows how many segments are being rendered on each PC, you will find that when the video assets reside on your dual-CPU server, that 70-80% of the rendering is done on that computer and therefore there is very little stitching that has to take place at the end. By contrast, when the assets are on your editing computer, I bet it only does 30-40% of the rendering, and thus more stitching is needed.

Stitching is the weak link in the current network rendering strategy. In other threads, several users have already suggested to Sony some very clever ideas that would eliminate the need for stitching. I hope they implement these ideas in a future release. They also need to improve their documentation, and eliminate the need for the specifying the network mapping. I don’t think anyone has been able to get network running without considerable trial and error.

It is definitely encouraging to finally hear from someone for whom network rendering makes a significant difference.
shogo wrote on 6/13/2004, 11:42 AM
"As I look at your configuration, I think the reason you got results that were so much better is that your server is a dual processor computer. Therefore, when the video assets are already on this fast computer, it ends up doing most of the rendering. Why? Because by the time video goes to the remote, single CPU machines, gets rendered, and then gets shipped back to the server, the dual CPU computer has probably rendered 2-3 more chunks of video. Thus, I bet if you look at the real-time readout that shows how many segments are being rendered on each PC, you will find that when the video assets reside on your dual-CPU server, that 70-80% of the rendering is done on that computer and therefore there is very little stitching that has to take place at the end. By contrast, when the assets are on your editing computer, I bet it only does 30-40% of the rendering, and thus more stitching is needed"

I am fixing to step out for awhile but when I get back I will try this out. I will see how I can further test your theory and see what I can come up with.
shogo wrote on 6/24/2004, 8:25 AM
"Why? Because by the time video goes to the remote, single CPU machines, gets rendered, and then gets shipped back to the server, the dual CPU computer has probably rendered 2-3 more chunks of video. Thus, I bet if you look at the real-time readout that shows how many segments are being rendered on each PC, you will find that when the video assets reside on your dual-CPU server, that 70-80% of the rendering is done on that computer and therefore there is very little stitching that has to take place at the end. By contrast, when the assets are on your editing computer, I bet it only does 30-40% of the rendering, and thus more stitching is needed. "

Okay I finally got a chance to run this with my wife's athlon xp 2000 machine and did not use my Xeon server at all. I did use a gigabit network card to try and keep it similar to what I had configured on the other tests.

Actually on the previous tests when I looked at how many render objects each had done they were pretty much equal the Xeon would always finish first but not by much it had rendered like 13 while my edit machine had done 12 and my laptop had done 10. That is still a pretty equally rendered project.

Now when I ran this last test I used my edit machine for holding the clips and used it as my stitch host one thing I did notice was that stitching on the edit machine took considerably longer this could be because my server has 4 200 gig drives in a RAID 5 confg or just because of the CPU's and additional ram.

First test I ran was to Magic Bullet FX's and the render times were as follows on this 30 sec. clip.

Network render 8:34
Standalone 16:37

second test was a single color corrected clip that was about 3:30 long

Network rendering 6:10
Standalone 4:39

the stitching on the second test was the performance hit here but then again it wasn't that much FX applied you can see the difference it makes with Magic Bullet or heavy composites.

So from what I have found is if you are doing a very complex project with lot's FX's it seems to do what it is intended to do but on long projects with very little FX's it is not worth it unless you render it to a dedicated machine so you can edit another project while this is going on. I know I will be using it allot because I do allot of FX type work and this is going to be a real time saver for me but I think it really depends on what type of video work you do that will dictate if it is effective for you.
SonyEPM wrote on 6/24/2004, 8:32 AM
If you have not done so, you should try netrendering with the newly released Vegas 5.0b update. Netrendering is MUCH faster in many situations.
shogo wrote on 6/24/2004, 9:03 AM
Sweet! I haven't updated yet but it seemed fast to me before can't imagaine it getting MUCH faster....
johnmeyer wrote on 6/24/2004, 9:36 AM
Sony: If you have not done so, you should try netrendering with the newly released Vegas 5.0b update. Netrendering is MUCH faster in many situations.

That is great to hear. I will try it again the next time I have a complex render.
shogo wrote on 6/24/2004, 9:39 AM
I have a question do you update the render clients as well if so when you download the update patch do you just run it on the render clients as well or do you download a seperate patch for them?
SonyEPM wrote on 6/24/2004, 10:12 AM
As of Vegas 5.0b, there is no longer a render only installer. Just install the 5.0b update right over the top of all your Vegas 5 installs (full or netrender only) and you'll be set. The versions have to be synchonized- you can't run 5.0a of one and 5.0b of another.

The license agreement (http://mediasoftware.sonypictures.com/support/eula.asp) is the same- you are entitled to use one full version with the other 2 copies as renderers.

jsteehl wrote on 6/24/2004, 10:35 AM
SonyEPM:

How much more gain would one see with a gigabit vs a 100mbit network?
JaysonHolovacs wrote on 6/24/2004, 3:04 PM
Sony:

I take it this new installation strategy still does not relieve the limitation that network render computers CANNOT render MPG or AC-3?
shogo wrote on 6/24/2004, 3:25 PM
"How much more gain would one see with a gigabit vs a 100mbit network? "

Are talking about with the new update or just in general terms. I would say about 30 -50 % in my testing but I am no expert just my experiance. I haven't updated yet so I can't say I will try tonight if possible before I update and run a before and after results test.
SonyPJM wrote on 6/24/2004, 5:43 PM

Nothing has changed with regards to the MPEG and AC-3 restrictions
BUT you can network render MPEGs. (There seems to be a popular
misconception that you can not). The restriction is that you can not
use MPEG as the segment format on more than one machine running under
the same serial number. But you can choose an AVI encoder such as DV
or YUV for the segment format.

AC-3 is less of an issue since you can't distribute audio-only render
jobs anyway... just means you can't offload the job to another machine
but you still can use network rendering to queue up an AC-3 render in
the background on your editing machine.