Export vs. Queue. Great difference in performance??

[Tom Lee]

http://www.youtube.com/watch?v=YlsKUIjgcSA

Ever since I began using CS5, I thought it's a common sense that using export is faster than queue. Export is much faster but it locks up Premiere. Queue is slower but it let's you keep using Premiere. That's how I understood it but I guess it may not be the same way for others.

In this thread http://www.dvinfo.net/forum/adobe-cr...g-times-3.html , you see Harm and I argue about difference in performance. He argues export provides superior performance only when dealing with AVI files. I had never used AVI files or any other formats except 5d mk2's H.264 .MOV files and my experience has been telling me export is much faster.

The arguement goes on and I ran various tests and here's what I found out:
"The difference is caused by this setting: "Use Maximum Render Quality."
With that off, there's no major difference between export and queue. With that on, the difference in speed is as great as 5x and I suspect others' with a faster GPU than mine (I use DDR3 version of GT 240 so it's around 50% slower than DDR5 one) may see around 10x of difference."

However, Harm argues...
"With MRQ on, the export is even slower than the queue. No difference with H.264, but MPEG2-DVD is around 30 seconds slower than without MRQ and nearly twice as slow as the Queue.
The only difference between your opinion and mine is that export is always equal or slower than the queue and you persist in claiming 2 - 5 times faster performance without giving proof.
Example with MRQ on, MPEG2-DVD export is 147 s, queue is 80s."

I then run a test using PPBM's project file. Keep it mind PPBM's benchmarking methodology does NOT test differences in between export and queue. It also does NOT acknowledge the difference that can be caused by MRQ. It only relies on queue (with MRQ off) for evaluating system performance. Realizing this, I just used PPBM's project file and encodes it using export and queue.
The same result was achieved. Export is much faster (2.8x in this case) than queue.

I further investgate this issue(using PPBM's h.264 project) and below i what I gathered addtionally.

With MRQ OFF: About the same performance between export and queue.
Export - GPU load: 80-90%. Stable.
Queue - GPU load: 1-90%. Heavy fluctuation but it does not affect the encoding performance.

With MRQ ON: Export is 2.8x faster than Queue
Export - GPU load: 80-90%. Stable.
Queue - GPU load: 1-15%. Mid-heavy fluctuation.


Now, instead of denying, ignoring what is happening on others' system, instead of calling it a "mysterious magic," and instead of saying this "claim is utterly untrue, unbelievable, unsubstantiated and lacks all kinds of proof, for others to test," (all Harm's quote) I think we could gather a useful, valuale information regarding this matter and make use of such differences accordingly.

You don't have to perform a test using PPBM. Just any h.264 project would work.
Just state your setup and let us know if you find differences in speed. Your input will be very much appreciated!

[Harm Millaard]

Tom,

In the other thread I replied:

Originally Posted by Tom Lee

720p. 29.97fps. Squre Pixels. Main Profile 4.2lv. VBR 1 pass, 11-17mbps.
Both of Render at Max. Depth and Use Max. Render Quality ON.

Here's the result:
Export: 2:14 (I used a stopwatch function on my phone for this setting does not inform the time spent.)
Queue: 6:18

As you can see, export was 3 TIMES FASTER than queue.

Same test, same settings:

Export: 1:33
Queue: 1:29

Conclusion: about equal.

The fact that you are getting these wide differences, that I can not replicate, are indicative of 'something' in your setup. I'm pretty confident I have a decently balanced system, even though not very fast anymore, so all I can guess is that 'something' in your system is not as balanced as in my system.

My system is a mediocre i7-920 (3.7 GHz), 12 GB memory, GTX-480, decent I/O system.

[Randall Leong]

After reading many posts by both Tom and Harm, I suspect that the reason for the substantial slowdown of queued performance (especially in MPEG-2 DVD encodes) in Tom's system might have been caused by a relatively imbalanced I/O system - the lack of a discrete hardware RAID controller. The onboard Intel RAID software-based solution "needlessly" eats up CPU power, resulting in such low performance in queued mode. And the i7-860 in Tom's system does not run as well as the i7-9xx systems in CS5 because of issues with memory controller performance (and that's not to mention the lack of sufficient PCI-e lanes in the LGA 1156/P55 platform to add additional PCI-e cards, especially RAID controller cards - the RAID cards would have had to either run in PCI-e 1.0 x4 mode or force the graphics card to run in PCI-e 2.0 x8 mode).

Relatively speaking, my i7-950 @ 3.83GHz runs faster in both tests than Tom's system, but exporting AVCHD to AVC Blu-ray is about the same in both export and queued modes.

On the other hand, Harm's system includes a hardware RAID controller with 12 hard drives in a RAID 30 configuration. (In that system, RAID is disabled on the Intel ICH10R controller used by the system drive.) That could have resulted in relatively low performance in Export mode because the second controller adds additional latency (but Queued mode performs faster in this instance due to the greatly reduced CPU loading).

[Tom Lee]

Interesting theory but that does not explain GPU load differences, in other words, CUDA utilization. Also I doubt encoding a simple and short h.264 project would eat up much of HDD bandwidth to the point of being a bottleneck. It certainly wouldn't be the case.
(BTW, I'm not on a RAID setup and I have 3 HDDs running in ACHI modes. )

Harm, could you measure your GPU load and run each test with MRQ on and off?

[Tom Lee]

Additional testing result.

1080p to 1080p. No effect applied then a few CUDA accelerated effect applied. MRQ ON.
Same performance; both are equally fast.

Single 5d mk2 h.264 file. 1080p to 720p. No effect applied then a few CUDA accelerated effect applied. MRQ ON
Queue is 3x slower than export. CUDA isn't being utilized.


What I'm certain is that it's not a hardware or windows setup issue. The hardware is decent enough. Windows setup is as clean as it can get. There're no background processes eating up CPU/GPU power. All the drivers are up to date.

[Steve Kalle]

I saw that thread a few days ago and tested on my HP Z800 and found queue to be faster.

Harm, You are so funny. You describe your I/O as mediocre. A 12 drive Raid 30 and Areca 1680ix is far from mediocre ;)

[Harm Millaard]

Steve,

I meant the CPU to be very mediocre, even below average today, my memory (as far as it still functions, I always forget whether it is Parkinson or Alzheimer) is no more than average and my disk setup is above average. That is why I called my Disk I/O decent.

[Randall Leong]

Originally Posted by Tom Lee

There're no background processes eating up CPU/GPU power.

I wasn't talking about background processes. I was talking about the RAID software used by onboard SATA controllers such as the Intel ICH or PCH: Since they are not true hardware RAID controllers, they actually eat up some CPU power even though they aren't considered "background" processes. It is those software-RAID-only systems that suffer in queue mode performance.

Harm's and Steve Kalle's systems have discrete hardware RAID controllers with their own cache memory. This improves queue performance but increases latency in direct-export transfers.

[Tom Lee]

In that post, I WAS talking about background processes, not RAID setups - I had already talked about RAID setups right before that post ("Interesting theory but that does not explain GPU load differences, in other words, CUDA utilization. Also I doubt encoding a simple and short h.264 project would eat up much of HDD bandwidth to the point of being a bottleneck. It certainly wouldn't be the case.")

Those who are getting same performance between export and queue, could you run four different benchmarks like the one I did?
(Something like this one...
With MRQ OFF:
Export - GPU load:
Queue - GPU load:
With MRQ ON:
Export - GPU load:
Queue - GPU load:)

As of now, it is only MRQ that's making a difference on my machine. I wonder if it's the same case for others as well. That's something I need to find out in order to solve this puzzle.

[Harm Millaard]

Tom,

I will be doing your requested tests in the next couple of days, but logic dictates that GPU load is very much dependent on CPU speed and memory speed. The GPU will be waiting for the next bunch of instructions from the CPU, while the CPU may be waiting for the memory to finish reading or writing the required data, and they in turn may be waiting for the disk(s) to finish their allotted tasks.

It is always the weakest link in the chain that determines performance.

[Steve Kalle]

Harm and Randall,

Any possibility that the PCIe controller being on the CPU makes a difference with GPU usage?

Maybe one of the Adobe guys can write up a piece about the different algorithms beings used in Export vs Queue like they did with MRQ.

Tom, I was using XDCAM EX or nanoFlash - I can't remember which project I was working on. I can test with R3D files, DPX or XDCAM but no H264.

[Harm Millaard]

One of the explanations I heard is that direct export uses CUDA for all scaling and other processing that max render quality could affect. There are some cases where queuing to AME does not, and there is an unaccelerated software scale in AME after the GPU accelerated render in PProHeadless. This software scale will be affected by max render quality. Adobe is aware of this limitation and working on a solution.

The following graphs show the GPU load with different export settings, direct export without MRQ, direct export with MRQ and both situations using AME.

[Tom Lee]

Wait, I'm not getting this. So, are you saying AME(queue) can, indeed, can perform slower than direct export? and that "Adobe is aware of this limitation and working on a solution."

[Randall Leong]

Here are my results of my testing (in transcoding a 1920x1080/59.94i AVCHD clip to a 720x480/59.94i widescreen MPEG-2 DVD-compatible file (the first graph is queued without MRQ, the second graph is queued with MRQ, the third graph is exported without MRQ (I did not bother to graph "exported with MRQ" because the GPU utilization results are the same as exported without MRQ)):

[Randall Leong]

The graphs in my post above clearly showed that in a simple AVCHD-to-MPEG-2 SD transcode, the direct export used nearly 90% of the GPU's power whereas AME queuing barely used the GPU at all. And for some strange reason GPU utilization is even lower with MRQ on than with MRQ off. No wonder why my HD-to-SD transcodes are slower in queued mode with MRQ turned on than in direct export mode. It might be an issue with the graphics driver or the driver's settings.

I retested with both MRQ and maximum bit depth turned on. No change in my results from the graphs above.

By the way, my results are with only one layer and one video source. Throw in multiple effects, multiple layers and multiple video sources at varying resolutions, and the results will begin to favor queued performance (or put it this way, the direct export performance will begin to approach that of the queued performance with both MRQ on and at maximum bit depth.