Performance issues Premire CS5

[Kenneth Maultsby]

Hello everyone I have another newbie question on Production Premium Performance. The problem at the moment is with CS5 Premier Pro. I am having a strange problem and I would like to know if it is normal or it is something with my setup.
Here is my setup Intel I7 930 @2.80 not over clocked, 24gb of memory. I am using the onboard raid controller set for raid 5 using four Hitachi Deskstar HDS72101010CLA332 which is my D drive. The C drive has OS and App on it which is a Western digital. Media cache File set D:\Media cache files; Media cache Database is set D:\Media cache database\. Rendering optimize for Performance. So everything Media, Projects, Media, Media Cache, Previews, and Exports goes to the D drive. I have the memory set for save 3gb for other programs. Here is the problem I have just complete my first good size project and what had notice was for example when I was scrubbing in the timeline there would be at least a five second delay and sometimes when I click on a clip in the project window it would take a few seconds for it to show in the upper preview window. It almost seems like it has trouble finding the clip on the hard drive. Now here is something crazy the longer I work on a project the smoother the better it gets. These our DV clips but I will be mostly working with AVCHD. Any Ideas? Are the hard drives the problem?

[Alan Emery]

Hi Kenneth,

I am not a hardware expert so I can't help you there, but I have had a similar experience although with different file formats than yours:

1) I find I need to allow all the media to load before I touch the keyboard or mouse or it acts resentful for some time.
2) I have no idea why but sometimes doing two or three "saves" in a row seems to dump the clogs in the memory system especially if I am dealing with large or numerous clips.

Hope that helps,
Alan

[Kenneth Maultsby]

Thanks Allen yep it was doing that also. But still it act as if hard drive is slow.

[Alan Emery]

HI Kenneth,

I tried one more experiment. My initial scratch disk had about 150GB free space. While this seemed ample, I thought well .. let's try a lot more. So I switched the scratch disk to a drive that had 1.4 TBs of free space. This made a quite significant difference. It still is not perfect, but it certainly helped.

If you can do something like that it might make a difference for you also.

Good luck with it,
Alan

[Bo Skelmose]

Those isues you have - I do not but I am using big 10tB raids for video and scrach and fast SSD for Cdrive.

One problem I do have - is when dragging the timeline roller to a new place on timeline and hit spacebar for playing, it jumps back to the earlier spot and start playing there. I have to wait for a second or two before I hit play to make it work - rather annoying.

[Alan Emery]

HI Bo,

Just out of interest, what RAM do you have available to Premier Pro CS5? I currently have 16GB and much of the time it is maxed out.

Thanks,
Alan

[Robert Young]

I have noticed the same glitch with timeline playback occasionally. It is usually more common when I've just opened the project.
I'm using 24GB RAM and 2TB RAID 0 for media- so I doubt that it is a hardware issue.
I think it is a minor bug in CS5.

[Alan Emery]

Hi Robert,

Yes, the timeline lockup or hesitation is most pronounced when I first start working on a project as well. In my case, it can take up to an hour of working on the timeline for it to become completely smooth in playback. During that time, taking care not to allow the memory to get too clogged up before doing multiple saves helps.

I also wonder if the problem is a minor bug or maybe (worse) it is actually the program logic attempting to strut its stuff too early: render, create preview files, and index on the fly would result in a slow jerky start but better performance once the preview files are in place and indexed. If at the beginning of each session the number and size of files is large, perhaps the memory capacity maxes out and then the CPU can't do much so the computer locks up temporarily while it sorts things out. After a while there would be enough indexed preview files to ease the burden on the memory.

A bit frustrating at times, but with care, I am able to work through it. Not sure what Adobe's reaction to this might be. If I am wrong and it is a minor bug, it could be fixed. If I am right and it is the basic logic, it could be a more difficult.

Alan

[Robert Young]

Originally Posted by Alan Emery

Hi Robert,

Yes, the timeline lockup or hesitation is most pronounced when I first start working on a project as well. In my case, it can take up to an hour of working on the timeline for it to become completely smooth in playback. During that time, taking care not to allow the memory to get too clogged up before doing multiple saves helps.

What you describe is quite a bit more severe than I have noticed.
I'll occasionally get the failure to play preview, or failure to change preview image on movement of the CTI, usually early on.
Most often, if I just click to open a different sequence it's fine, then click back to my original sequence and that's the end of it.
I would describe your problem as a real issue rather than an annoying "glitch" & have no idea what the source could be.
Definitely make sure your graphic card, etc., drivers are up to date, but beyond that, I have no brilliant ideas.
Maybe post the problem on the Adobe PPro CS5 forum, if you haven't already done so.

[Steve Kalle]

I haven't seen this mentioned yet, but I do know what the problem is: using Raid 5 on the Intel motherboard. To be quite honest and frank, Raid 5 on the Intel ICH is the worst thing you can do for a few reasons:

1) it is very slow compared to Raid 10 on the Intel ICH and Raid 5 on a hardware raid controller (3ware, Areca...)

2) when a drive fails, the Intel raid can take a few days to rebuild - usually about 3 times longer than a hardware controller. In this time, it is extremely risky because another drive could die or have a read or write error in which case, all data is lost. Oh yeah, I forgot to mention that your computer is pretty much useless during the Raid 5 rebuild whereas a hardware controller can handle the rebuild and the data can still be accessible.

3) Raid 5 on the Intel ICH is much more likely to be corrupted than a hardware controller because it is software based and their drivers are not bullet-proof.

What drives are in the raid array? If Western Digital, then immediately find a way to change them to another brand because WD drives cannot be used in a Raid array without severe risk of losing data. Search my name and WD raid in this forum and you will see what I have written about this problem with WD drives and raid arrays.

If you have 4 drives, I HIGHLY recommend switching to Raid 10 which should require backing up all data and deleting the R5 array in the Intel management, and then creating a R10 array. Another option, which I do love about Intel, is creating a Raid 10 array on the first 90% of space and then a Raid 0 array on the rest to use for media cache and possibly for encoding. For my work PC (HP Z800), I use an Areca 1680ix with 6 Seagate Constellation ES 2TB drives in R5 for all assets, and then 4 1TB seagates in R10 on the Intel ICH with 3TB for encoding and the remaining 600GB for Media Cache and uncompressed rendering

My home PC, I use a 3ware controller in R5 with 8 1TB drives for all assets, and on the Intel ICH, I have 2 1TB drives in Raid 1 for encoding with 700GB and the remaining 230GB is in Raid 0 for Media Cache.

Both PCs have expensive UPS's because you can lose an entire raid array from a power outage as I did 6 years ago, which took 30hrs of my time to recover 95% of the data. I also have an Areca battery backup for the Areca 1680ix controller as a safe-guard in case data is being written and the UPS fails or runs out of juice. The Intel ICH raid does not have any battery backup.

[Alan Emery]

Hi Bob,

Your observation that my problem was more severe than yours prompted me to do some experiments so I thought I would share my observations.

I opened the Task monitor so I could watch the computer performance and also the resource monitor so I could see if there was a reason why the CPU was sometimes very laboured. I started a new project and imported nonoflash files. On opening, there was a minor amount of RAM used as overhead. As each of the files came in and was conformed (most in the range of 300MB to 2 GB) the RAM used rose more-or-less in equal amounts to the size of the files being imported. When the imported files plus the overhead was roughly equal to the available RAM (16GB in my case) the CPU use plummetted, the number of page faults skyrocketed and the computer froze or struggled if I tried to do anything much.

Once the project was closed, the RAM usage dropped to about 1 GB. When I re-opened the same project the overhead was equal to approximately 10% of the sum of the file sizes I had earlier imported. So, for example if I imported 50GB of files, the opening overhead is about 5GB. At this stage I can not import more than about 11 GB of additional files before the RAM is used up, the CPU usage drops and the hard faults rise dramatically. As I add more files, the overhead on re-opening the project is increased by about 10% of the new file sizes that I added. If I eventually add 150GB or more of files, the opening overhead is just about my entire RAM and the CPU has great difficulty doing anything because there is so little RAM available, instead it is using the scratch disks.

Next I used a project that had about 50GB of files (and therefore about 5GB of overhead RAM usage on opening the project). I placed a file of about 1 GB size on the timeline. No increase in RAM use resulted. I then played the file and the RAM used gradually rose as it played until at the end of the file. At that point, the RAM use was up about 1GB (a total of about 6GB). At this stage clicking on any of the functions (such as "save") was quick and normal.

I kept adding and playing files until the overhead reached about 10GB. Then went back to the beginning of the timeline and played the same files. This time the RAM usage remained stable at the level it had reached after playing the files I had on the timeline. It did not rise on files being re-played.

I added more files until when I had played about 15GB of files the CPU dropped, hard faults increased and when I tried to click on any function, the program was very fragile or froze.

I am not certain how to interpret this, but I think it is that PProCS5 uses about 10% of the file sizes as overhead in any project. As the timeline is played, the program memorizes the material played so it can be played back smoothly. If there is too much material on the timeline (plus overhead), the program struggles to play it the first time, using scratch files. If you can once play the material, the program is prettty good at recovering it and playing it back smoothly even if there is a lot of material on the timeline and in the files. It does not however seem to know how to spill memory that is not in use.

Once I did this experiment I went back to look at the project that was so troublesome. The sum of the file sizes in the project was over 500GB. This meant that my project overhead was too much for the RAM available.

The lesson I took from this is to keep the sum of the file sizes in my project well below 10 times my RAM -- preferably about half that so there is room to play the material and to add effects and still have room to operate. If the memory gets overloaded, I close and re-open the project. This reduces the RAM usage initially to just the overhead.

Interesting!

Alan

[Robert Young]

Alan
Those are indeed very interesting observations.
IMO this is not at all normal behavior for CS5.
I've done CS5 projects with 1000+ HD clips, using 12GB RAM and typically the RAM usage runs an easy 4-6GB, and will rise to 8+ GB on export rendering, etc., but never top out.
In your case it sounds like CS5 on your system is "accumulating" RAM usage; it is not releasing RAM when it has finished a particular task, so the RAM usage just keeps on stacking higher and higher until it hits the wall.
I recall having that problem with CS3 and CS4 on 32 bit systems.
It required all sorts of workarounds to keep a project moving forward- very annoying.
BUT, I am not seeing any of that sort of thing with CS5 on my off the shelf Dell Studio XPS i7.
My guess is that this is a problem known to Adobe & maybe you should try to contact tech support.
You definitely should not be having to employ elaborate work arounds to do the sort of projects you are describing.

[Alan Emery]

Hi Bob,

I took your suggestion and updated all the drivers and as well contacted the Adobe technical experts. Three very helpful people worked with me and the problem has calmed down considerably. The program can now play through a large project and can release memory as it goes. It is close to the limit however and occasionally stutters, but is quite acceptable.

The only time now when the program chokes completely is if I try to import and conform too many nanoflash files all at once. A simple workaround is to import them in small numbers, close then re-open the program before importing more. Because importing large numbers of files is not an everyday task for me it will not pose a problem.

Thanks very much for your advice. It's great to have someone else to ask who has similar software and can suggest when something is amiss with my experiences!

Alan

[Steve Kalle]

What did Adobe say to do?

I just got a nanoFlash and noticed today that Premiere was eating up ram when conforming a few nanoFlash files I imported.

[Alan Emery]

Hi Steve,

I had more than one problem.

I use a Canon XLH1s with a nanoflash and usually have two mics in the XLR plugs so I get two separate channels. At first PProCS5 was only importing one channel. The setting that brings both channels in is in the Edit>Preferences>Audio>Default Track format> "Mono as Stereo".

The second was being unable to play a not-very-long sequence without the computer freezing and crashing. It seemed to accumulate RAM (I have 16GB) and hit the wall without being able to release memory. There were a number of things that we did along the way so I am not 100% sure what the real fix was but it included 1) removing the folder 5.0 under Documents and Settings>User>Application Data>Adobe>Premiere Pro>5.0. Note that there are two entries, Premiere Pro and Premierepro. Choose the first one with separate words. Restart the computer and program (you lose all the project names and some internal settings, but the project names are still on your hard drives of course so you can re-locate them). 2) was to update all the drivers etc. In my case these were all up to date. 3) was to update Quicktime to 7.6.9 (in my case from 7.6.2). This in total solved the RAM accumulation on playback.

The third problem is when importing and conforming nanoflash files; the computer accumulates RAM, switches to the scratch disk with lots of hard faults and then the CPU drops, freezing and ultimately crashing the computer. I am still working with them on this one, but a quick and dirty work around is to import no more files than the sum of which is less than your available RAM (note that there is an overhead RAM when you open the project and it will vary according to how many files you have already imported into your project). Try to gauge it so there is still a bit of RAM left after you import the files. Then exit the project and re-open the project. This takes a few moments for sure because the computer is trying to work through the accumulated goop of memory I assume. Once it is done and re-opened, the RAM is back down to the overhead and you can start importing more files again.

A fourth problem I have found (and I haven't mentioned this one to them yet) is that if you are finally working on your project and decide to remove some files from the project (and therefore also from the timeline), the cursor freezes and takes sometime to be returned to you. It will come back with crashing the computer though.

I will report on any further progress!

Alan