View Full Version : Why is my i7 system so slow in SD MPEG encodes in CS5?
Randall Leong May 26th, 2010, 10:59 PM Below are the quotes from posts that I previously made in other threads about my slower-than-expected performance in the PPBM4 benchmark tests:
Gosh, I need to get one of the higher-end NVIDIA cards. My system's current HD 4850 has been falling a little behind now...
(To be specific, my system got only slightly better overall performance with CS5 than it did with CS4...)
Ack, I discovered that my HD 4850 has only 512MB of total graphics RAM. No wonder why I did not see as much of an improvement in performance as others did. It seems as though I would need a graphics card with at least 1GB of RAM in order to even make anywhere near the full use of the software mode in CS5.
And despite the lackluster performance of my system in the PPBM4 test under CS5, the software-assisted playback turned out to be much faster and smoother than it ever was on CS4. In order to get those nice benchmark results, I needed either a higher-end NVIDIA card with 896MB or more RAM or a faster drive subsystem than my RAID array's current Intel software RAID 0 setup.
With my 4850, I got only a score of about 47 with CS5 versus a score of about 51 with CS4.
And since the test isn't using the drives very much, I might conclude that it could have been my slower drive config than the higher-ranked scorers. And then, maybe it's the fact that I still have only 6GB of RAM in my machine although standard-definition projects should not have been that memory-intensive. And yes, I did try both my old HD 4850 512MB and a newer HD 5770 1GB with the same results (and that my scores varied very widely from one run to another even at the exact same settings). (I put in a 5770 on my main editing machine only because I moved my 4850 to another rig whose older graphics card died out.) With that, I opted not to submit the scores since they were inconclusive.
Even with such lackluster scores, importing/editing/rendering/encoding the videos whose projects originate in CS5 is faster in CS5 than CS4 ever performed in my machine. And that's more important than a benchmark test that isn't quite optimized for CS5. I can't wait for the release of PPBM5!
I found out why I've been getting such lackluster scores in CS5 relative to the other CS5 systems in the PPBM4 list:
It's my RAID setup. It is running off of the exact same SATA controller as my non-RAID system drive - and it is using the same Intel RAID driver for both RAID and non-RAID drives connected to the same controller. Most of the systems that achieve higher scores are using a separate controller for their RAID arrays from the one used for their system drives. Unfortunately, my motherboard does not have a secondary RAID controller for any internal SATA hard drives - and the only secondary RAID-capable controller on my mobo is a Marvell eSATA controller for external SATA drives.
Yes, I am editing off of a RAID 0. And my current RAID 0 array was created via Intel's Rapid Storage utility.
Even when I got the process count down to 34 processes and compression and indexing turned off and the configuration set to Black Viper's "Safe" configuration (which I used for now), I still get the same PPBM4 score I had been getting with all of the default processes running.
Perhaps this may be because I was/am using an ATi card (an HD 5770, at that)? (In general, the consumer ATi cards do not perform as well in OpenGL mode as NVIDIA's consumer cards do.) I am suspecting this because the HD 5xxx series - at least with the drivers that are currently available for them - perform rather poorly on some of the critical 2D tasks compared to the older cards or the NVIDIA cards.
Or maybe it's the fact that I am also using the same editing system for other uses, such as gaming or as a media center? The software used in such systems also adds resource-hogging processes (much of which can't be disabled or uninstalled without screwing up those programs).
Even after this lackluster MPEG encoding performance with standard-definition material, I would have to say that transcoding 1920x1080/59.94i Cineform AVI files to Blu-Ray-compatible H.264 AVC is about 20 percent faster in CS5 than it was in CS4 or Vegas.
I decided to quote them all (since they threw the thread I originally posted this on off topic) and compile them together into the first post in a new thread.
I tried slimming down the number of processes, and I still get slow MPEG2 encoding times.
Is there any other way of improving performance without disabling the processes that the other apps (Media Center, etc.) require?
I would appreciate any alternative answers.
Craig Coston May 26th, 2010, 11:29 PM 1. Run HDTach on your Raid array and other drives and post the results for us.
2. What video card is CURRENTLY in your system? How much RAM?
3. Are you overclocked right now? If so, what are you running at?
4. Open processes: after booting completely and with the system idle (nothing open but what loads on boot), tell us how much CPU is being used by open processes and how much RAM is being used (found in Task Manager).
5. Are your video files on the same drive you are trying to output to?
6. What settings are you choosing to encode to?
7. Make a short project file to test with including a couple short clips (keep everything under 100MB). I can take a look at it the end of next week for you once I get done with a big edit I'm working on. Zip it all up and put it up on a web server and email me the link or email me and I'll give you FTP access.
Randall Leong May 27th, 2010, 12:25 AM 1. The transfer rate on my RAID array is about 250 MB/s maximum and about 130 MB/s minimum. My boot drive, however, maxes out at just under 110 MB/s (with a minimum of about .
2. I tried both a 512MB ATi HD 4850 and a 1GB ATi HD 5770 card with very similar results. My system currently has 6GB of RAM.
3. My processor is overclocked to 3.8 GHz with the memory running at 200 MHz (I used the 19x non-turbo multiplier with the BCLK at 200 MHz.)
4. With the default Aero turned on, even with the slimmed down configuration, the memory usage exceeds 1GB. I am going to re-run PPBM4 with Aero turned off, and see what happens.
5. I tried different combinations of source and output drives, and got the fastest results in PPBM4 with both the source and output files on the RAID array.
6. I followed the instructions on the PPBM4 site.
After I re-run the benchmark, I will report my findings. UPDATE: I think it could have been my system's motherboard. Overclocking the processor to 3.8 GHz did not appreciably improve my MPEG encoding times compared to the same CPU at its stock speed (or put it this way, the Intel motherboard is not easily configurable for optimum performance, with a few crucial settings that are missing). I might replace the motherboard at this point.
Craig Coston May 27th, 2010, 10:06 AM One word for you, even though I know you think it's a dirty word: ASUS.
Harm Millaard May 27th, 2010, 10:12 AM Randall,
Please send me your new Output,txt file by PM and to Bill as described.
Meanwhile, have a look at the top results, which may be posted later on the PPBM4 site:
Randall Leong May 27th, 2010, 01:21 PM Randall,
Please send me your new Output,txt file by PM and to Bill as described.
Meanwhile, have a look at the top results, which may be posted later on the PPBM4 site:
Will do as soon as I replace the mobo and reinstall Windows 7. (I got myself a Gigabyte GA-X58A-UD3R board to replace the Intel DX58SO board.)
And yes, my MPEG times with the Intel motherboard are much, much longer than the other top CS5 scores (which is why I decided not to submit the results from that system).
Randall Leong May 27th, 2010, 05:58 PM An update:
I am going to borrow a spare system drive and run PPBM4 and PP CS5 with a clean Windows 7 install. This is because the PPBM4 benchmark does not perform anywhere near as well on a system that's configured to run multiple different types of applications as it does on a system that's stripped down of everything except for the required device drivers and dedicated to video editing only and permanently disconnected from the Internet. This means that I would need at least two complete working systems - one for video editing and one for everything else.
Randall Leong June 1st, 2010, 07:07 PM Another update:
As it turned out, it was my multimedia configuration that's to blame for the slowness. Also, a lot of people who run the PPBM4 benchmark in CS5 actually cheated to attain such low MPEG encoding times: They left the "Use Previews" turned on for the MPEG encodes. Turn that feature off (the instructions for running PPBM4 actually call for this), and the MPEG encoding times will increase dramatically.
With this cheat, I got a total encoding time of 30.4 seconds (my score has just been submitted), with an MPEG encoding time of 7.6 seconds (and this is with the Gigabyte motherboard). I will re-run the test on my earlier Intel mobo, and report the results.
Craig Coston June 1st, 2010, 10:45 PM How do you know they "cheated"?
Randall Leong June 1st, 2010, 10:55 PM How do you know they "cheated"?
I could never get anywhere close to those short times in MPEG2 no matter what I did when I followed the instructions exactly. And since standard-definition MPEG2 encodes are hardly memory-intensive, adding an additional 6GB would not have made much of a difference in my system. Nor would switching to a supported NVIDIA card help my performance scores much since it affects only the timeline render times.
And "cheating" is the wrong term I used in the previous post. I should have said that many of those people simply forgot to check the settings in AME before running the PPBM4 benchmark procedure.
Randall Leong June 2nd, 2010, 06:33 PM I retested my system again (using the original configuration of multiple components and programs installed on my main system drive), and discovered that the AME CS5 settings needed to be "tricked" into giving great MPEG-2 scores. If the benchmark is run with the settings as instructed, the MPEG-2 scores would be much closer to two low-rated CS5 rigs (those two rigs had MPEG-2 times of more than 50 seconds).
By the way, I got a total score of a very respectable 30.6 seconds at 3.73 GHz (with my original config), and a score of about 37 seconds with the CPU at stock. As such, more RAM would have helped the timeline rendering performance a bit. So would switching from an ATi GPU-equipped card to a supported NVIDIA GPU-equipped card - but I would have to choose a CUDA card very carefully: Some of those cards (in particular, the lower-end 1GB cards) have GPUs that are so weak that their performance in timeline rendering in the GPU-accelerated mode would have been no better than using the software-only mode. And of course, CUDA cards with only 512MB of RAM cannot use the MPE's GPU acceleration mode at all since that mode requires 765MB of free (not total) graphics RAM just to run at all.
Harm Millaard June 3rd, 2010, 03:28 AM Randall,
I haven't seen your results, but with a total time of 30.7, I would expect under CS5 with MPE off, your scores to be in the region of:
AVI: 5 - 6 s
MPEG: 9 - 11 s
Render: 15 s
What do you mean with "tricked"?
The architecture of CS5 has changed dramatically with the move to 64 bit.
In the benchmark test without MPE, the AVI scores have approximately doubled in comparison to CS4. At the same time the MPEG scores have dropped to around 25 - 40 % of the CS4 scores and render times went up by a couple of seconds. All with the same test settings.
Notice that enabling MPE results in a further drop in the AVI test, again doubling the time required.
Can you send me the Output.txt?
Randall Leong June 3rd, 2010, 09:47 AM I have submitted three results to the PPBM database - but those will not appear on the chart for at least another few days.
And, if anything, the HD 5xxx series cards are a tad slower than the HD 4xxx cards in the render portion of the test. This is largely due to the HD 5xxx cards eating up a bit more system resources than the HD 4xxx cards do.
And by "tricked," it seems as if the "Use Previews" setting in AME is left checked.
Randall Leong June 16th, 2010, 12:47 AM Now take the following steps:
1. Open AME and make the complete queue, 10 instances to MPEG2-DVD and 10 instances to Microsoft AVI with all the correct settings as described in the instructions.
2. Go to File / Save Queue. Exit AME.
3. In Explorer go to:
C:\Users\<user name>\AppData\Roaming\Adobe\Adobe Media Encoder\5.0 and copy batch.xml to batch - Copy.xml or another name to your liking.
4. Now reopen AME and the whole batch file is recreated for immediate testing.
5. Run the queue.
6. To rerun the test, copy batch - Copy.xml to batch.xml
7. Start AME and run the queue.
If you want to rerun again, delete the files as described above or the incremental file name issue can cause problems.
That quote is from another thread about running PPBM4 with CS5 and Windows 7.
Using this procedure I have recently uncovered a bug - not with PPBM4 per se, but with Adobe Media Encoder CS5. I saved what appears to be the "correct" settings ("Use Previews" unchecked for MPEG-2 and checked for AVI) - but then, when I relaunched Adobe Media Encoder, all of the MPEG encodes have "Use Previews" checked! (I confirmed my findings when I clicked "Settings" for each of the MPEG-2 encodes after I relaunched AME CS5.) It appears that once AME detects any preview files in the project folder(s), it enables the "Use Previews" setting for all encodes regardless of whether it was enabled or disabled. I am suspecting that this is the cause for the artifically fast times for MPEG-2 in the top systems on the top PPBM4 scores list. (It is highly likely that none of the owners of the top systems on that list even bothered to re-check the settings in AME.)
And because of this AME CS5 bug (the failure to save the chosen "Use Previews" settings reliably), a fair number of the systems landed in the top 20 when they should not have been. This makes my initial 48-second total time (with the 24-second MPEG-2 encode time) correct, and most of the other systems' total times with CS5 substantially "faster" than they should have been. Of all the CS5 systems on that list only the two that took 50 seconds or longer in MPEG-2 did the PPBM4 tests correctly (given the CPUs that those two systems were running).
With that said, I had submitted my artificially fast times from my current rig; however, they have not yet appeared on that list.
Harm Millaard June 16th, 2010, 05:28 AM Randall,
Thanks for bringing this to my attention. I had not seen that before, so that means quite simply that these instructions do not work and will no longer be suggested as an alternative.
But rest assured, most of the submitted results were done by people not even aware of these instructions. Most only run the test once. I think that most people who have runs the test a couple of times find it even easier to create the queue manually, because the included instructions with PPBM4 are so easy, just set one file manually, press the duplicate button 11 times, change the last entry manually and press the duplicate button 10 more times and run the queue.
Another thing to remove your doubts, look at the consistency of results. The AMD score is purely caused by the fact that AMD misses sorely needed instructions for MPEG encoding. The other low score with CS5 is caused by a slow CPU, very limited memory and an inadequate disk setup.
All the scores make perfect sense, otherwise they are not published. Bill and myself look very closely at submitted results and if we have any doubts, we do not publish but ask for retesting or explanations.
Randall Leong June 16th, 2010, 11:46 AM Another thing to remove your doubts, look at the consistency of results. The AMD score is purely caused by the fact that AMD misses sorely needed instructions for MPEG encoding. The other low score with CS5 is caused by a slow CPU, very limited memory and an inadequate disk setup.
Well, the slowpoke Intel CS5 system not only has a slow CPU (albeit one that's overclocked), it has much less L2 cache than a Q9650 (which also ranked lower than all of the other MPE systems though it had better MPEG scores than the Q8300 system). Plus, no 150GB 7200 RPM hard drive has as fast of a raw transfer speed as most of the newer 500GB hard drives; in fact, two 150GB hard drives even in RAID 0 might actually still be slower than a single 500GB hard drive.
In addition, the GTX 470, which did so well with MPE enabled, proved to be a slowpoke in software-only mode (as far as the timeline render test results are concerned) even compared to the ATi-equipped systems on the list. The relatively immature drivers for the GTX 4xx series may be partly to blame.
Randall Leong July 10th, 2010, 01:22 PM Well, the slowpoke Intel CS5 system not only has a slow CPU (albeit one that's overclocked), it has much less L2 cache than a Q9650 (which also ranked lower than all of the other MPE systems though it had better MPEG scores than the Q8300 system). Plus, no 150GB 7200 RPM hard drive has as fast of a raw transfer speed as most of the newer 500GB hard drives; in fact, two 150GB hard drives even in RAID 0 might actually still be slower than a single 500GB hard drive.
In addition, the GTX 470, which did so well with MPE enabled, proved to be a slowpoke in software-only mode (as far as the timeline render test results are concerned) even compared to the ATi-equipped systems on the list. The relatively immature drivers for the GTX 4xx series may be partly to blame.
I was wrong on the last paragraph there. It turned out that the slowpoke in question was running with a less-than-optimal memory configuration - 16GB of RAM via four 4GB DIMMs running in a "Flex" memory controller mode. In that mode, 12GB had been running in triple-channel mode while the remaining 4GB had been running in single-channel mode. This mixture of memory controller modes significantly increases the overall latency of the i7's memory controller, resulting in these slowdowns.
And now I think I know why my results that I had submitted still have not shown up on the PPBM4 list on the site: I failed to specify that the MPE was turned on (GPU accelerated mode) or off (software-only mode). So I had to rerun my tests (this time, the two 1TB Seagate drives which used to be in a RAID 0 array were then configured as separate drives for this test), and I now got an overall score of 33.6 sec., with the AVI performance at 6.7 sec, the MPEG time of 7.9 sec. and the rendering time of 19 sec. (and this is with no RAID). I am currently rerunning the same system with a two-disk RAID 0 array, and report back to you.
An update with the RAID: As it turned out, putting the two drives in the RAID 0 shaved off only 1.8 sec. off of the AVI encode times. The MPEG encode and the render times remained about the same. Hence, I can concur with Harm that a two-drive RAID 0 array is not worth the trouble unless one or two additional drives (configured as separate volumes) are added to the system. However, this is applicable only for SD video editing. With HD video editing, I will have to wait for the release of PPBM5 before I can jump to any conclusions. (I resubmitted only the results with three separate drives and no RAID.)
Randall Leong July 24th, 2010, 05:24 PM ...I discovered that I have too little RAM in my machine, so my MPEG-2 DVD performance is still below par for an i7-920 overclocked to 3.7 GHz. With a score of 185 seconds on that test, it is slower than even an AMD system in that test. Otherwise, the 83-second score for the disk I/O is as expected for only a two-disk RAID 0, while the scores for H.264 Blu-ray and CPU/GPU MPE Off are also below par. And even if I upgraded the RAM to 12GB, the GPU and disk scores would have still limited my system's performance.
In other words, an astronomically expensive system (priced at well over $5,000 total with more than four HDDs and a dedicated hardware RAID controller) is required in order to achieve anywhere near top scores in the PPBM5 list.
Hence, I will be submitting several sets of scores for PPBM5 as soon as I re-run my tests with more RAM and/or an NVIDIA GPU.
Randall Leong July 30th, 2010, 07:13 PM It is too little RAM in my system. Today I upgraded from the 6GB that my system had been running for several months to 12GB. Although my system did not overclock as well with six sticks of RAM as it did with only three sticks of RAM, my MPEG-2 encodes took about half the time that it did with only 6GB. (And this is with the CPU and memory at the default stock speeds.)
I will gradually overclock the CPU with this new configuration, and submit to Bill all of the sets of results that I kept.
Another update:
I finally got the 12GB system stable at an overclock to 3.5GHz. My test scores in PPBM CS5 is even better than at stock although its 427-second total time is primarily due to the lack of MPE GPU acceleration. I currently have an HD 5770, but would love to get a good NVIDIA card.
In short, although PPro CS5 can run with as little as 4GB of RAM, I strongly feel that it needs at least 12GB of RAM to run at its best. (I confirmed this after running the PPBM4 test after I upgraded the system to 12GB of RAM. No wonder why I had to cheat in order for my system to achieve a good score with only 6GB of RAM.)
Randall Leong October 14th, 2010, 08:16 PM I have recently "upgraded" the CPU in my main rig to an i7-950. This meant that I decided to rebuild the original i7-920 rig with the Intel-brand DX58SO motherboard and 6GB of RAM. And since my current GTX 470 was my only CUDA card with sufficient RAM to run MPE's GPU mode, I went out and picked up a 1GB GT 240 with GDDR5 memory on clearance.
I ran the PPBM5 test with the CPU locked at its stock 2.67GHz (Premiere Pro CS5 5.0.2), and to my surprise I got an MPEG-2 DVD score of around 145 seconds. Not as fast as I would have gotten with 12GB, but quite respectable for a stock-speed i7 with only 6GB. The MPE timeline rendering score was also very respectable (at 14 seconds), particularly for a stock-speed i7 with such a cheap graphics card. If there is a weak point to that system, it was the AVI (disk) performance: This auxiliary system does not currently have a RAID array for the work drive, resulting in slower-than-expected disk performance.
Overall, I am quite happy with this auxiliary rebuild. An overclock to what I had the CPU at when the 920 was in my main rig, a faster disk setup and double the RAM would have put this system too close to the CS5 performance of my main rig for comfort, so I decided to leave it at stock speed with only 6GB. The only upgrade that I have planned for that system for the foreseeable future is a faster disk setup (two or three identical fast 7200 rpm disks in RAID 0).
Randall Leong October 16th, 2010, 08:18 PM I have recently "upgraded" the CPU in my main rig to an i7-950. This meant that I decided to rebuild the original i7-920 rig with the Intel-brand DX58SO motherboard and 6GB of RAM. And since my current GTX 470 was my only CUDA card with sufficient RAM to run MPE's GPU mode, I went out and picked up a 1GB GT 240 with GDDR5 memory on clearance.
I ran the PPBM5 test with the CPU locked at its stock 2.67GHz (Premiere Pro CS5 5.0.2), and to my surprise I got an MPEG-2 DVD score of around 145 seconds. Not as fast as I would have gotten with 12GB, but quite respectable for a stock-speed i7 with only 6GB. The MPE timeline rendering score was also very respectable (at 14 seconds), particularly for a stock-speed i7 with such a cheap graphics card. If there is a weak point to that system, it was the AVI (disk) performance: This auxiliary system does not currently have a RAID array for the work drive, resulting in slower-than-expected disk performance.
Overall, I am quite happy with this auxiliary rebuild. An overclock to what I had the CPU at when the 920 was in my main rig, a faster disk setup and double the RAM would have put this system too close to the CS5 performance of my main rig for comfort, so I decided to leave it at stock speed with only 6GB. The only upgrade that I have planned for that system for the foreseeable future is a faster disk setup (two or three identical fast 7200 rpm disks in RAID 0).
By the way, 5.0.2 appears to work much better than 5.0.0 or 5.0.1 with less than 12GB of RAM. In my testing, I got an MPEG-2 DVD encoding time of about 120 seconds at 3.4GHz with 6GB of RAM running 5.0.2 compared to the over 180-second result at 3.7GHz with the same 6GB of RAM running 5.0.1.
|
|