Go to your Settings and tell it to use 2 threads instead of 4. See if this fixes the problem. Also, is the Vegas version installed on both computers exactly the same?

Hello to you both!

Thanks for your comments and tips. I've applied all of them and have seen some drastic changes already. I want to do some more testing in the next hour or so; to make sure the changes are consistent.

I will reply with more details later; however I can't promise that it will be today. I just got off work, it's almost 1 AM, and I can't guarantee a coherent reply at this time :-)

Thanks in advance, I think we're on the right track here!

Erik

Go to your Settings and tell it to use 2 threads instead of 4.

Correct - however after some experimenting in a setup similiar to GEJ's I had to specify 3 threads in VMSP 8 on a Core Duo to make the second processor kick in full.
It is probably a codec issue as it (number of necessary threads) seems to depend on the source (AVI, DV, Stills etc)

Hello all.

Thanks again for all the replies so far; and sorry to have kept you waiting. It's been a long day - and night! I've done a lot of testing; and come to some interesting conclusions.

But let me answer rustier's questions first. Yes, I'm quite comfortable building my own PC. I've been doing it for a decade and a half, and have turned it into a part-time business :-) The PC was re-installed, from square one, on a blank hard drive. Running Windows XP Pro, service pack two, with all the updates. VMS has been installed, and it has the latest update, version 7.0a, build 52. The installation was the same on the old PC.

The new motherboard is a Gigabyte GA-8I865GME-775-RH-AS. It's the cheapest motherboard they offer right now; but I bought it because I didn't want to spend the bucks for a complete upgrade (including memory and new graphics card) right now; and so could just install my old memory and video card. It takes DDR-400 and an AGP card, that, again, I already had. Cheap upgrade. The motherboard does have the latest BIOS; I flashed that in as soon as I installed it. It uses the Intel 865G chipset. I don't know if VMS has problems with that chipset; but it is rock solid and well supported.

The old motherboard is a DFI NF2 Ultra Infinity board; an (old) overclocker's favorite. It is based on the nVidia NForce2 Ultra 400 chipset. It also uses DDR-400, and an AGP card, both of which I've now moved to the new system. The RAM I use are two 512 MB sticks manufactured by Viking; the graphics card is an eVGA 6600GT. Other than that I'm using 2 IDE hard drives, one 160 GB, the other 40 MB. The smaller one is mainly used to make backups. I know, I know, not the latest and greatest; but the rest of the upgrade will follow in a couple of months.

So that's the hardware. Next up is a description of my test setup.

The video project consists of 37 AVI files, almost 4 GB in total, of varying lengths, no spaces in between them, no effects, no text or sound added, etc.; and is 18 minutes and 42 seconds long (plus a couple of frames). It is rendered as an AVI file, 720x480, 48kHz 16 bit stereo file. The rendered file is almost 4 GB as well. After each test I restarted VMS, assuming that the memory it had used for the test would be released properly.

rustier's reply gave me a couple of hints. I started playing with the amount of dynamic RAM. The default is 128 MB, and I ran 5 tests with that setting. The average rendering time was 5:05. I increased the setting to 256 MB, and again ran 5 tests. This time the average rendering time was 5:07, two seconds more. Just for the heck of it I doubled the amount of RAM again to 512 MB, at which time VMS told me that too much RAM could create problems. I did not run into any problems; but again the average rendering time went up, this time by no less than 11 seconds. So, I hate to say it, but increasing the memory setting doesn't seem to help, on the contrary.

The other tip I got out of your reply, rustier, was the one about using different drives. And that was a real eye-opener, holy cow! I started rendering the same project, from the source drive (C:) to the target (D:), and at the same time adjusted the RAM amount too. The first 5 tests, from C: to D: with 128 MB, yielded an average rendering time of 2:09. Less than half of the time it took to do it from C: to C:, wow! The second five tests were with 256 MB, and resulted in an average of 2:15. The third batch of five tests got an average of 2:26.

Again, the increased amount of memory seems to have a slightly negative effect. But that is overshadowed by rendering results from drive C: to D:, instead of using the same drive. Man, I wish I had picked up this tip 6 months ago, when I was processing all that video from our trip to the old continent. Most of those projects took hours!

Now, to reply to Eugenia and ritsmer's tips. All tests I'd done so far were with 4 threads. Since the best results I got were with 128 MB and from the C: to D: drive, I kept those setting to do my tests with different thread counts. I again ran 5 tests per setting.

The first test, mentioned earlier, was at 128 MB, from C: to D:, with 4 threads. The average there was 2:09. The next test was 128 MB, C: to D:, 3 threads. Average was 2:11. The third test (which I should have repeated) was 128/C: to D:/2 threads, came in at 2:22. I should mention here that one of five tests clocked at 2:39, much higher than the other 4, which came close to the average of the other tests. I'm assuming my PC was doing something else for a couple of seconds, like checking for updates or so... The last test was at 128 MB, C: to D: with 1 thread, and the average there was 2:12. So the difference between 4 threads and 1 is only 3 seconds, with more threads being faster. Obviously, in my (or this?) case, more threads is better.

Just for the heck of it: this afternoon I re-installed my old hardware, put Windows and VMS on it; and the old system is still faster. I didn't run the whole series of tests again, just a couple; but it still finishes first. I don't intend to keep it though; as every other (non-VMS) test clearly declare the Core 2 Duo a winner.

And there you have it. I wish I could repeat these tests with the large source files I had at the start of the year, but I can't; they've been deleted. And even if I still had them: thorough testing with these large files takes an awful lot of time...

So my question is still open, and if anyone can think of anything else to try or test I'd be more than willing to accept suggestions. I have submitted a question to the Sony tech department; but I realize it may take a while to hear from them.

In the meantime though, I'm rendering from C: to D:!!!!!

Thanks,

Erik

Have you tried tweaking the priority cpu settings for VMS? This is a long shot, I know, but you never know. I read about this somewhere on this forum, but I can't find the original thread. Also, I have the Dutch version of XP, so my terminology may not be perfect.
But here I go: run VMS, and hit CTRL+ALT+DEL. Go to 'running processes' and select VMS, right-click on it and select 'set priority'. You'll have several options there, but for testing, you want to go for one of the highest (high or realtime), of course. (Mine is set on 'normal').

I remember that in that thread people actually would turn down the priority, in order to be able to do other things with their pc while VMS was rendering in the background, but naturally, you want to render as fast as possible, so there you go!

EDIT: With my setting 'normal', when rendering, cpu usage skyrockets to 100%. I have an low spec AMD sempron cpu.

I started playing with the amount of dynamic RAM. The default is 128 MB, and I ran 5 tests with that setting ............ So, I hate to say it, but increasing the memory setting doesn't seem to help, on the contrary.

As I understand it, the Dynamic RAM setting is the amount of memory you want to reserve exclusively for RAM renders -- the "Dynamic RAM Preview" feature, I think. If you have FX applied to a clip, and maybe pan/crop, and a transition, for example, you might find that VMS cannot play the clip back in real time. If you want to see what the final product looks like, you can select a small section of your timeline and select Tools > Dynamic RAM preview (I think -- I don't have VMS installed on this computer...) There is also a keyboard shortcut (ctrl-B or ctrl-shift-B or something...)

Anyway, this feature lets you temporarily render a small section of your timeline into RAM (rather than render to a disk file), so that it can play it back in real time.

But, the amount of RAM you reserve for the Dynamic RAM Preview is essentially RAM that is then not available for anything else. The more RAM you reserve for the preview buffer, the less you have available to the program.

Again, I might not understand this correctly, but perhaps someone else can confirm or refute this...

Tim L

I think you are right Tim. When I suggested it I was kicking arond different ideas. I still am inclined to think this is a hardware issuewith GEJ. Something in the way he has his computer set up is limiting VMS. It is just odd that it seems fine with other programs.

GEJ I am glad the 2 drive tip helped you. I discovered that early on. Fellows like Johnnyroy, Glenchan, Johnymeyer, and Chienworks, have discussed it several times in the past. If you do a search key word "dual hard drive" or "HD usage" something like that you can read what others have said. I guess simply put it improves the flow of traffic as you are processing - a computer expressway.

not sure what else to tell you GEJ - gonna have to think on this one

(thinking out loud) . . . I wonder if the ram is properly paired with the motherboard - but of course you would think so if other programs are running better . . .hmmm

This is really strange.
I just tested GEJ's setups:
From one disk to another disk: 44 minutes (97-100 percent CPU util.)
From and to same disk: 75 minutes (40-60 percent CPU util.)

Sounds as if Windows XP for some reason chews up 1/3 or more of the available CPU power - because that XP is the only CPU user that (more or less) is not shown in the Taskmanager.

However: No problem - in future we will just render to another disk as the one where the source is stored.

Thanks to GEJ for this great invention.
Good for an Oscar?

Render to and from the same disk has low CPU utilization because the CPU is having to WAIT on the hard drives. (process is "I/O bound")

CPU: "I'm ready for the next section of file input..."

Disk Controller: "Just a minute -- I'm still writing that last chunk of output"

CPU: "still waiting...."

Disk: "Ok, just finished writing, now I can read the next section of the file you need for input"....

CPU: "finally...."

Tim L

The video project consists of 37 AVI files, almost 4 GB in total, of varying lengths, no spaces in between them, no effects, no text or sound added, etc.; and is 18 minutes and 42 seconds long (plus a couple of frames). It is rendered as an AVI file, 720x480, 48kHz 16 bit stereo file. The rendered file is almost 4 GB as well. After each test I restarted VMS, assuming that the memory it had used for the test would be released properly. If your source files are dv type2 and you rendered to a new file of the same spec's using VMS and it's smartrendering all your tests were consistent to a disk I/O test. IDE drives have issues with multiple reads/writes from the same device. They are terrible for multiple read/writes but a cost effective consumer drive. The answer is to use more then 1 ide drive for video editing. It's mandatory for my setups.

I think a better processor test would have been to render to a mpeg file or another format such as a wmv file, this would use the processors capabilities alot more. One should have at least 2 harddisks for video editing to work properly when using ide drives. I would suggest rendering the dv.avi file to a different format to make use of the math co-processors and parallel tasking in the new processor.

Tim L
Disk Controller: "Just a minute -- I'm still writing that last chunk of output" On my motherboards I can use the extra ide/sata ports that are installed to configure a raid setup as a standard ide/sata controller. The controller functions as another ide disk controller (Promise) and I don't have to set them as a raid array. Works out pretty nice, I use 4 drives in that machine, none of these drives are connected to the secondary optical drives (irq 15) ports. I have 2 writer connected to this port.

CPU: "I'm ready for the next section of file input..."

Guess you are right.
The numbers show so ...

I just thought that the hundreds of MegaBytes that Windows uses for disk-buffers were any good :-)

But still no problem: To morrow I will reorganize my 2 internal SATA's in order to have all source on one and the rendered files on the other.
I will make a little test first as to find out if it is the source or the rendered result that should be on a partition on the physical drive also hosting the C-drive - I mean - where Windows is pretty busy all the time - but also finding the best place for the source to get the best preview.

Hello Ivan123.

Dutch version of XP? Zeg het dan maar gewoon in 't Nederlands; ik ben een in Texas wonende Vlaming :-)

I hadn't tried changing the priority settings for VMS yet; but I did tonight. I ran another 20 tests; 5 each for "normal", "above normal", "high" and "realtime". As I was sort of expecting, changing the priority doesn't make a difference. The averages for each batch of 5 tests was exactly 5:07. (rendering from C: to C: again).

However, I know it would make a difference when running several programs, including VMS, simultaneously. That's what the priority setting is for, to control the amount of CPU time each individual program gets. But if, like me, you just run VMS by itself, there won't be any advantage in cranking up its priority level.

There a second setting, for multi-core CPUs, where one can choose the core that's used for the task; but I didn't try that as that would definitely be counter-productive. After all, using more cores is the whole idea behind faster processing.

Hey, don't underestimate your Sempron! My wife has a Sempron, and it runs almost as fast as my overclocked XP2600! Almost :-)

Thanks for your hints, they're much appreciated.

Erik

Hi Tim L, thanks for your reply.

Dynamic RAM Preview, I have to admit it's something I've never used before. It is lightning fast. And I understand better now what that setting is for.

When I tried it, again playing with the RAM settings, I found that with larger RAM settings I could select larger clips, and render those in memory. Makes sense, it's just one of those things that one has to do first before completely comprehending it.

Obviously this RAM setting has very little to do with rendering to disk, but everything with rendering to RAM. And it's very fast at doing that, I have to add.

Thanks!

Erik

Hello again rustier.

Let's see...

The new motherboard uses DDR-400, just like the old one. The new motherboard also support Dual Channel RAM configuration, just like the old one (and it's properly set up).

Also, Windows XP recognizes the new system as a "Multiprocessor PC", just like it should. So I'm assuming XP is OK too. I'm tempted to install the 64 bit XP, now that I have a 64 bit processor; but I've heard of so many driver problems that I'm a little hesitant...

I have gone through the BIOS again, and have turned off all power saving features. Those features potentially throttle back the CPU to a slower speed; something I'm trying to prevent from happening, for the tests.

What I have noticed is that VMS is doing many other tasks (not to mention starting up) much faster. Generating audio peaks, for example, and loading clips. But rendering, no, it's still not faster.

Just for fun I have taken a small screen shot of the rendering progress indicator, and Windows task manager side by side. You can see it at http://img168.imageshack.us/my.php?image=lowcpuusageduringrenderbs7.png . This screen image was taken at the peak of CPU usage, a whole 10 percent! On the old system it would easily go up to 90 percent, and more.

Now, the advantage of this situation is that I have lots of time to do other things - without them being slowed down to a grinding halt. Yes, on the old PC, when rendering, I could forget about doing anything else. On the new PC, however, I can still browse the internet without any signs of slow down. Weird, but welcome...

On to the other replies :-)

Erik

Hello again ritsmer.

I'm afraid I can't take credit for any of this; I was just trying the hint I got earlier. But I'm happy it helped you :-)

Erik

Hi again Tim L.

Your explanation about drive controllers makes sense; and honestly I never even considered it.

I think though, that in most situations, unlike mine with two clean, unfragmented hard drives, the problem is even worse; and that is that the drive heads have more work going from one spot to another, on one and the same drive.

On a clean, unfragmented drive, like mine right now, there is minimal head movement, which saves a lot of time.

Regardless, I'm happy I got that hint. More than 50 percent speed increase by using two drives. Sweetest freebee I ever got!

Erik

Hello 4eyes, and thanks for your comments.

Gosh, I'm not all that sure what my source files are. They were imported with Windows Movie Maker from my Canon DV camera, then processed with DVDate, and saved again to AVI files.

Yes, I'm still using the "old" IDE drives; but will upgrade to SATA drives later this year. It's just that "the green paper" is a little tight right now; so I'm doing it a couple of steps at a time. But yes, I do have two IDE drives that - as I've found out very recently - make a heck of a difference!

I can't agree that a better processor test would have been to render to a different file format; but only because I didn't do that test on the old system, so I have no reference point. I did a small test tonight, rendering to an MPG2 file; and you're right: it does stress the CPU much more. I uploaded a small screen image to http://img249.imageshack.us/my.php?image=renderingtompg2er8.png . But, as you can see, rendering to MPG2 adds 2 minutes to the total rendering time; not exactly what I was looking for....

Thanks,

Erik

found this on the sony knowledge base. Perhaps it makes sense to somebody?
Vegas Video 3.0 and multi-processor PCs.
Question
Vegas Video 3.0 and multi-processor PCs. Does Vegas Video 3.0 utilize more than one processor on a multi-processor PC?
Answer
Vegas Video 3.0 uses many 'threads' while playing. Each thread is qualified to be processed on any available CPU. The system handles all of that for Vegas. Any time more than one thread is running on a multi-CPU computer, more than likely both CPUs are being used. So the system splits tasks between the two processors, even in an audio-only project. Dual processors also pay off when rendering DV. If Vegas Video 3.0 detects two or more processors, it compresses to DV on one thread and renders/composes video frames on another.

ps
een natte zomer, hier in Vlaanderen, blijf maar in Texas! ;-))

Just made a little test: If you do not have 2 disk drives you can just render to a USB connected Flash storage - i.e. I just rendered to the 4 GB SD card from my camera - and the render time was low - precise like rendering to another physical diskdrive.

ritsmer,
I did the same (rendered to a USB2 stick), but I have bad results: render time on one hard disk: 7'49'', compared to render time to usbstick: 8'35''

By the way, what setting changes did you perform? I for my part, only changed the path in the 'Render as' dialog. Should I change other things as well? Or is it perhaps because my project results in a rather small file (111MB), which is below the amount of RAM I have?

EDIT:
My first, negative tests were when encoding to mpg2. I rendered the same file to avi, and now the positive results show: from 5'12'' to 3'21'', which is a spectacular improvement.
Still, this raises a new QUESTION: why doesn't the improvement show with the MainConcept encoder rendering mpg?

Ivan123: Besides what you already fould out then there is an issue about USB bandwidth - that is I just heard about it - but it seems to work so that when you have several USB thingy's and hubs, then either XP or the hardware limits USB bandwith to theese channels downto 20 or 30 percent og the full (possible) USB rate no matter if other channels are busy or not. Strange.

I just ordered a 16 GB Corsair Voyager stick and will make some experiments with it when it arrives. The reason is that I have only 2 physical HD's (500 and 750 GB) and so either the VMS source-from or render-to HD would be on the physical disk that also hosts the Windows C: drive.
And as Windows seemingly accesses the C: drive 100++ times for near to nothing then I want to keep it free from the rendering business - and so always render to the USB-stick.
Maybe it does not bring so much now where I have only a Core Duo 2.16 - it will bring something when I build the next machine around the coming 45 Nm quad processor from Intel because with 4 x 3 GHz processors the Harddisk issue will become the bottleneck more than today. So I think at least...