Redcine-X Slow on PC?

[Peter Simpson]

Hi,

I have a brand new HP Z820 loaded with 64GB ram, 2x8 core at 3.1GHZ processors a Quadro 4000 and a Telsa C2075. Next to it sits a 2.5ghz single processor imac (4 cores) with 4GB of ram. I have the same R3D loaded into each and the imac scrubs through the shot in the viewer much faster than the HP and just feels zippier. Any clues as to why? Haven't really changed any configuration in the HP since I got it. The R3D's are on a pretty fast thunderbolt external in the imac the HP just has a couple internal drives software raided while I wait for the proper raid I have ordered to turn up. Even if I copy the R3D onto the system SSD which is very fast it still clunks along. Even after the shot is completely cached into Ram the playhead lags severely behind the mouse pointer when I drag it along the play bar.
I am very confused and somewhat disappointed. Obviously the machine is extremely powerful and I am sure there must be something I am doing wrong but can't figure out what I need to get it to work properly with Redcine-X Pro as I haven't had to do anything to the mac version and it works fine on the imac.
Thanks for any advice.
Peter.

[Matthew Yaeger]

Have you tried installing a new Video driver from Nvidia?

The fact that the play head shows the images are cached and you are still getting slow performance means you are having trouble with the images being uploaded to the graphics card fast enough. We haven't had any issues with the Quadro 4000 here performance wise, so I recommend making sure you have the latest video drivers for the card.

[Peter Simpson]

Hi Matthew thanks for that.I updated the drivers and still no joy.it caches maybe slightly faster than the iMac but still scrubs very slowly even though it will play back 1/8 and even 1/4 in real time once it is cached. With the iMac I can scrub through relatively quickly even if it isn't cached at 1/8 but on the HP no dice.
Also when rendering on the HP I get 7% CPU use. Is redcine multi processor aware. I can do the multi instance option to 6 which gets it to about 50% but would be great to render using more than half my computer:-)
Thanks

[Matthew Yaeger]

RCX is very multiprocessor aware, and we are not seeing this playback slowdown locally on PCs with Quadro 4000s.

A couple things to try:
1. Make sure Verbose logging is disabled in your preferences.
2. Try disabling "Update scopes on playback" in the preferences.

Beyond that I'll need you to re-enable verbose logging and perform some less than realtime playback with the cache bar full and then send me a saved report from the help menu.
I will also need you to send me a system information file from your hp.
You can send the 2 items above to redcinex at red dot com.

[alex trettenero]

Same here.
Bought a super PC, very similar to the one described by Peter ( 16 cores, quadro 4000, 48GB RAM..), and pretty much same results.
Slow on playback, slow on render.
it takes 24 minutes to render 750 frames @5k to fullHD dpx....
cpu usage ony goes to 10%.
tried with verbose of and disabled scopes' updates, but didn't change much.
will send report and system info to redcinex@red.com.
thanks.

[Cory Petkovsek]

RCX runs fine on my system. Core i7-960, GTX480, 12GB, Windows 7/64, RAID.

Alex, RCX usually won't render with mutliple cores unless you configure it to export with redline. Then you can run up to 16 export processes. However the time frame sounds about right. A rocket may improve it, but you still need fast disks. "Slow on playback" is not objective enough of a description to help. It entirely depends on how fast your disks are. I can play a complete full frame 5k clip in real time at 1/8th without stopping. The read ahead stays about 15 seconds ahead. At 1/4th, play speed is faster than the read ahead so I can play sections that have been cached. My raid can read at 250MBps.

Peter, what is the sustained read rate of your drive? "SSD which is very fast" is completely subjective. SSDs have very fast access time, but their throughput can be across the board. At this point in RCXs development, it is extremely unlikely the software is the problem. As I said, my raid can read at 200MBps sustained. Download HD Tune and check. Windows also has plenty of built in monitoring capabilities that can pinpoint exact performance issues. Load up Resource Monitor for instance and watch as you load and play an R3D. The one I played, RCX took up 25-35% CPU, 67-88MB read from disk, and under a GB of memory.

One final note, the speed of a drive interface, and the speed of a drive are two different things. Just because you have a harddrive connected via usb3 (640MBps), Sata III (768MBps), or thunderbolt (2.5GBps) doesn't mean much if the drive is only a 7200rpm disk that can only pump out data at 80MBps. The fastest cpu, greatest ram, most expensive video card, and fastest nic, will all be brought to their needs by a slow harddrive. You both need reliable performance specs from the different subsystems, especially your disks to make an accurate determination on where the problem lay. I bet you both have slow disks.

Cory

[BRANDON JAMESON]

RED ROCKET.

You can try and work around it , but it IS the post component of all RED cameras.

[Peter Simpson]

Just wanted to say that the scrubbing problem I was having has been fixed in build 15. saw something mentioned in the release notes so was very keen to try it out and it works very well. Thanks.

EDIT:
Actually scratch that it hasn't although I have inadvertently found the problem. Any clips with audio on them will not scrub properly in the viewer. Clips without audio scrub very, very smoothly so must be some issue with the audio. I have the audio routed through a blackmagic decklink card but if I switch back to the basic audio out of the HP doesn't make a difference. Must be something with my setup?

Also hadn't seen the last few comments above. The read write speeds are System SSD: W=228MBps R= 445MBps Raid: W=531MBps R=621MBps.
Looked at the performance monitor as it played back at 1/4 res about 4% CPU usage. Playback was never an issue really though it was scrubbing in the viewer and transcoding using multiple processors.

[Cory Petkovsek]

It is rare for a system to write faster than it reads. Very rare. And for you to have two disk subsystems that can do it is odd. In any case, both disks read and write are quite fast.

Regarding scrubbing on clips with or without audio, I can confirm that. It happens on mine. You can speed it up on the Etc tab by changing the audio channel from enabled to disabled channels. For instance for one of my slow clips L Channel is on a gold Camera Audio 1 (enabled), R Channel is black; if I switch L Channel to a black Camera Audio 2, scrubbing speeds up.

This looks like a bug, or at least undesirable behavior. I will file a report with Red (by emailing redcinex at red). Thanks for identifying it and bringing it up.

Cory

Edit: report has been filed.

[Peter Simpson]

Hi Cory,

Thanks for the help. That was of course a typo, my bad sorry. The read and writes are the other way round (have now edited the post).
As for the audio I did as you suggested (looked everywhere for something like it but apparently not closely enough) and indeed changing the audio playback channels in the etc tab does fix the scrubbing problem.
Thanks for filing the report as well, good to have some closure.

Cheers,
Peter.