If you have not done it then check the CPU usage through the Task manager: is just one CPU working or are all? (could be a setting in Vegas then).

Windows 7 has a fine resource monotor (under performance) and with that one you might find the bottlenecks that are delaying your machine.

If I understand you correctly then you are trying to render using material from on another machine via a network connection - well most of us try to optimize the speed to access to the material using fast internal disks or even internal RAID 0 arrays. (some NLE's are even demanding RAID 0 disks for HD editing).
Accessing it through a network does not sound fast at all - and depending on your PC's net card also some hidden CPU usage might be spent without that you can see it in the task manager.

It seems to depend on what effects and what type of render you are performing.

For instance; in a project rendering AVCHD to NTSC DV widescreen I get 100% CPU use until I hit a clip using the Neat Video noise reduction plugin, then I get 40% across the 4 cores. When I get past that clip use goes back up to 100%. I also see varied CPU use below 100% on clips with other effects.

I don't know why, but below 100% utilization can be normal in some cases. Eight % seems like another issue though.

Jeff9329,

What you said is exactly what I was implying in my reply. Without further info from the OP, there's not much to say but what I wanted to add was that the percentages quoted depend on the number of processors you have and whether you have hyperthreading turned on or not. For example:

* Single CPU, fully utilized = 100% reported by Task Manager
* Quad-core CPU with 1 CPU fully utilized = 25%
* Quad-core CPU with hyperthreading enabled, 1 CPU utilized = 12.5%
* Dual, Quad-Core CPU with hyperthreading enabled, 1 CPU utilized = 6.25%

All these numbers could be for the same task...different numbers, but they all indicate 1 CPU being maxed out - not necessarilfy for Vegas, but for a single threaded task.

I run a Dual Quad system for one of my editing systems on a 1 gig network. I have found if I pull from network and render to local drive on computer I use 100% of all 8 cores. If I pull and render to network I am lucky to get 50%. Also if my Dynamic ram preview in vegas is set above 500mb it slows to a crawl (I have 64 gigs of ram on system). Sometimes only 25% of CPU's are used. Check these because it drove me crazy untill I figured it out.

I did a bunch of testing and found the culprit. First the background... By "running on a network", I simply meant the raw footage is on another machine, and I'm rendering back to a file on that same network machine (i.e. 'server' although it's not a dedicated server box).

I have a 1GB LAN connection, and can edit, preview, etc. from the media on the network drive with absolutely no problem at all. So the network bandwidth limitations are definitely not slowing the render down.

The simple situation was that if I start up a particular render on the machine with the drives local, it renders in about an hour. When I start up the same render, from the same Veg file on the network drive, using the same media files, it renders in 10 hours!

But here's the result of the research... I was incorrect in thinking it had to do with 64-bit vs. 32-bit. And it actually doesn't have anything to do with the source media being on the network... BUT it has EVERYTHING to do with writing the render file on the network drive. I simply changed the render to write to the local drive, and still kept everything else on the network, and the CPU shot up to 100%.

So there is something going on in how the rendered output file is being accessed. The network is killing it. Recommendation if you want to work from a network is to render to a local file and copy it to the network drive after it completes. It'll save you about 9 hours for a 1-hour render....

That's great that you were able to track down and resolve the issue! Just curious if the two workstations are connected directly together via a x-over or via a gigabit switch?

Thanks for sharing your resolution.

I just ran a quick test with WIn 7 64x Intel core 2 quad 8G ram rendering AVCHD on the TL rendering to NTSC DVWS mpg2 with Vegas 9c and all 4 CPUs are running 98% - 100%. Default Vegas 9c internal preferances Video render threads min = 4, max = 16. Target drive is a local RAID 0. Do a search on this forum for John Clines's Render Test.

Ed

I had a similar problem when switching to xp x64 3 years ago.
in vegas 7 first all 2 cpus were at 100% and after a few minutes they where at maybe 10%. even previewing went slow after a short time with ordinary DV files.....
in xp x86 the same render was always at 100% and x-times faster
i never solved it completely, tried deinstalling/installing vegas, etc....
but i found what caused the weird behavior:
when i edited and rendered a project on an external hardisk or usb stick without using any internal HDs everything worked fine. So the problem had to to something with the HDs:
The Problem were the Nvidia Sata drivers with a RAID-0 configuration. With a clean x64 Install on another HD without a RAID i had no problems. Installing the Nvida Drivers HD drivers -> same problems again. No problems ever in any another application.
Even killing the RAID and unistalling the nvidia drivers did not help - only a fresh install without them worked.
Funny thing was also that i had no problems in Vegas 4 and Vegas 8 on the same machine.


so - nice done! - it is always the best way to to isolate the problem somehow on computer errors - and the next time i have problems rendering on a network, i will think of this thread - thanks

Glad that you have figured out how to reduce your render time. Regarding this:

"But here's the result of the research... I was incorrect in thinking it had to do with 64-bit vs. 32-bit. And it actually doesn't have anything to do with the source media being on the network... BUT it has EVERYTHING to do with writing the render file on the network drive. I simply changed the render to write to the local drive, and still kept everything else on the network, and the CPU shot up to 100%.

To come to this conclusion (and to be completely anal about it), one more test would be necessary, and that is to put the source material on the local drive, and only the rendered file should be on the network. The goal of this reverse test is to figure out if having both input & output on the network is a problem, or if it really is just the rendered output file on the network is the real issue.

If it's just the rendered output file that is the issue, then a call to SCS might be in order (maybe it's a bug, or maybe they can explain what the limitation is). If it's the fact that both input & output are on the network, then it might still be a network congestion or even the OS at fault.

Good leg work, and glad you found a workable solution.

So it looks like all you are actually saying is that you are having extremely slow network performance on your new Win7 machine?

If so, this is a common problem with a couple of common possible causes, and a number of less common ones you may need to do a Google search for.

The two common causes are: 1. badly written "security" software (McAfee, Symantec, etc) interfering with the network data flow, and 2. Remote Differential Compression (RDC), a new Microsoft trick supposed to improve transfer over slow connections (ADSL) but which sometimes makes things worse on good connections (Ethernet).

The solutions to 1 is: Completely uninstall* the suspect security software (AntiVirus, AntiMalware, Firewall, etc) for test purposes to see if it improves the transfer speed. If so, find a better behaved security solution, if not, re-install whatever you were using. (*It's important to completely uninstall this sort of software when testing. Although most of it has control panels that appear to allow you to turn it off, this will often not be enough to prevent it causing performance problems - only removing the software completely will do that. And that can be quite a tricky task in itself - often just uninstalling it in the usual way will leave things behind that can still interfere with the good running of the machine. But special uninstallers are often available that will remove all trace of McAfee, or Symantec, or whatever, software.) If your HP machine is running the sort of manufacturer-installed "added value" security software that the last HP laptop I saw was burdened down with, then there is a fair chance that this may be the cause. You are probably better off removing it all and using the machine in as clean a state as possible, even if it does not solve the network performance problem.

The solution to 2 (along with some other suggestions, can be found here.

Best of luck in resolving the situation.

Mark