Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

8Core Nehalem / Red Rushes madness - absolute madness!!! HELP

just gave Redcine a try with a 4K 2:1 clip rendered to ProRes HQ 1920x1080 full debayer, View settings to full res high. Rendertime for 100 frames took 1min12sec.

Manuel
 
Manuel Wenger said:
just gave Redcine a try with a 4K 2:1 clip rendered to ProRes HQ 1920x1080 full debayer, View settings to full res high. Rendertime for 100 frames took 1min12sec.

Manuel
Click to expand...

So, the 3K render took over 5min with Red rushes, but the 4K took just over 1 minute with Red Cine...?

Seems that the problem lies somewhere in Red Russhes/Red Line ?

Red...?

J.
 
Christian Berg-Nielsen said:
We have a 8-core nahelem, with 8 GBs RAM and we are experiencing the same thing here (monkey uses redline). On full debayer it takes over twice the amount of time to render out dpx´s as our old 4-core 2.66.

It did one test that were quite interesting. I made 4 copies of the monkey extract application, and divided my timeline in four parts, rendering it simultaneously on the 4 copies of the program. Each program rendered as fast as 1 program alone, thus making it actually 4 times faster.

This should indicate that redline (and maybe redrushes etc.) are not optimised for the new nahelem processors.

Hope this can be of help to someone...
Click to expand...

That seems to me the same problem, that only a portion of the process power is used. Do you have a volume license with QMASTER Support ?
If you dont, you are in Monkey also restricted to render only one clip at once. Only with the QMASTER support you can render more render actions at once.... call Nigel Stanford for this.....

It depends on your render settings (debayer, olpf compensation - post sharpening, etc.) how high the cpu is loaded with one render action, and throughput. Seeing that in the activity monitor you can load in RR or in Monkey via QMASTER multiple render actions (clips rendered at once) to get a full CPU load. The level of debayer and specially the post sharpening process are significant to your render speed. When you use Monkey on QMASTER then be sure to go to your QMASTER settings panel in the system preferences and check that "render" is controlled and give as much render slots that you fit your cpu load. If it is not controlled it can happen that your machine stalls. So start with two or three slots and look if you get 100% cpu load. if not you can add one more....

best, rainer
 
For me:

New 8core
---------
OSX version: 10.5.6
QT version: 7.6
RAM: 6GB
Processors: 2x2.26 Ghz Quad core

Render 17 seconds 2K R3D file into Full Apple Prores 422 HQ, need 45 minutes !!!!!!!!!!!!!! And I use a RAID 5, around 650 MB/s in read/write.

And many R3D files, in REDAlert, Render, crash !!!!!!

Crazing for this right now.
 
Please someone from RED look into this or just let us know that you know there's an issue and that you're trying to resolve this. It's KILLING us!
 
Tony Lorentzen said:
Please someone from RED look into this or just let us know that you know there's an issue and that you're trying to resolve this. It's KILLING us!
Click to expand...

We already have. On our nahalems here everything is faster.
There are of course lot of variables that you can add to the equation that we can't replicate (unless you want to send us your tower) like memory setup, OS revs, QT revs, etc. The productions and customer feedback has been very positive about nahalem macs so until we can recreate the problem there's not much we can do.

My guess is 3rd party memory that's not running at the right speed or the memory is not installed in the right pattern. If it's not installed properly, bandwidth can easily be 1/3rd to 1/6th or more of what the nahalem can do.
 
How about the crashing issues. REDRUSHES used to be so stable on my quad core and now it crashes randomly. This is really screwy when you set up a render over night for dailies the next day and see that only a a few clips or so render and the app crashed leaving the dailies to still be rendered! What is the incompatibility?

My specs are
New 8 core 2.26ghz, 12GB RAM, 10.5.6, QT 7.6, Current REDRUSHES version, 3 internal 1.5TB Seagate drives (Rendering from Drive 1 to Drive 3), 720p QT ProRes Half RES Debayer telling REDRUSHES to use clip RSX. Am trying a variety of setups rendering 1,2,4 clips at once, and a variety of processor configs ie Auto, 2,4 cores per clip. All crash at different points in the render. What's the deal? This is really annoying@@!
 
mikeburton said:
My specs are
New 8 core 2.26ghz, 12GB RAM, 10.5.6, QT 7.6, Current REDRUSHES version, 3 internal 1.5TB Seagate drives (Rendering from Drive 1 to Drive 3), 720p QT ProRes Half RES Debayer telling REDRUSHES to use cli
p RSX. Am trying a variety of setups rendering 1,2,4 clips at once, and a variety of processor configs ie Auto, 2,4 cores per clip. All crash at different points in the render. What's the deal? This is really annoying@@!
Click to expand...

Have you sent a crash report log into tech support?

There have only been crash reports from 4 people in the last six months.
All the crash reports have been in an Apple UI component not under our control.
 
do you have noticed the same trouble with other jobs like rendering in FCP or Compressor. it seems to me the RAM is the troubleshooter. And i have to remind you: you have to have some free space at your startdrive too ;-)
 
Deanan said:
We already have. On our nahalems here everything is faster.
There are of course lot of variables that you can add to the equation that we can't replicate (unless you want to send us your tower) like memory setup, OS revs, QT revs, etc. The productions and customer feedback has been very positive about nahalem macs so until we can recreate the problem there's not much we can do.

My guess is 3rd party memory that's not running at the right speed or the memory is not installed in the right pattern. If it's not installed properly, bandwidth can easily be 1/3rd to 1/6th or more of what the nahalem can do.
Click to expand...

Deanan, at the end of the day it seems that me and other people are in fact having problems with the 8core Nehalem being DOG SLOW on FULL DEBAYER, WITH RSX. It's about as fast as can be expected when running at any other debayer setting other than FULL, and when I go through the "Nehalem is great" -threads in this forum, I see all of them being based on Half debayer benchmarks... I'll repeat, the problem lies in FULL DEBAYER output.

I'll also second the opinion the Red Rushes crashes ALL THE TIME on the Nehalem, and it's rock solid on our 2-year old 4core.

Can you please:

A) Verify that you haver indeed tried the following on your Nehalem 8core:
- Full debayer
- Clip RSX with small adjustment to brightness and exposure
- Scale fit height 1080
- Output to ProRes HQ
- Cores per clip: Auto
- Clips at a time: 1
These settings give me a render time of over 5 minutes/100frames for 3K footage, and over 9 minutes/100 frames for 4K footage out of Red Rushes (same results out of Red Alert). This is 3 times longer render times then on our old 4core. I know you want us to optimize cores per clip and clips at a time, but if you indeed want to try to replicate the problem, try this.

B) Publish a full spec on your Nehalems - HW and SW - if indeed you are getting different results.

C) Post the process for submitting a chrash log And I'll send it right away - Red rushes rarely make it through more than 10 clips without crashing.

As far as RAM I bought what one of Swedens top Mac Retailers (they are a pro shop with full consulting and repairs etc) recommended, and I did reinstall the additional RAM that I added after the Mac gave me a warning of improperly configured memory slots.

This IS a problem.

Kind regards

Jack.
 
jacknusa said:
D
A) Verify that you haver indeed tried the following on your Nehalem 8core:
- Full debayer
- Clip RSX with small adjustment to brightness and exposure
- Scale fit height 1080
- Output to ProRes HQ
- Cores per clip: Auto
- Clips at a time: 1
These settings give me a render time of over 5 minutes/100frames for 3K footage, and over 9 minutes/100 frames for 4K footage out of Red Rushes (same results out of Red Alert). This is 3 times longer render times then on our old 4core. I know you want us to optimize cores per clip and clips at a time, but if you indeed want to try to replicate the problem, try this.

B) Publish a full spec on your Nehalems - HW and SW - if indeed you are getting different results.

C) Post the process for submitting a chrash log And I'll send it right away - Red rushes rarely make it through more than 10 clips without crashing.

As far as RAM I bought what one of Swedens top Mac Retailers (they are a pro shop with full consulting and repairs etc) recommended, and I did reinstall the additional RAM that I added after the Mac gave me a warning of improperly configured memory slots.
Click to expand...

Yes, we have already full debayer. As I said before you do need to optimize for multiple clips and threads.

Why? Nahalem's architecture is deffierent than the old architecture in that it's a slower processor but it has 8 real (but slower) cores and 8 hyperthreaded cores. This means that given different compute problems it will perform differently than the old cores on a per thread basis. That's why you have test for overall speeds by maximizing more clips in parallel with an appropriate amount of threads per clip. There are other factors like more memory bandwidth and turbo modes that affect speeds.

B) A stock nahalem from apple with the fastest processor and memory. Nothing else is modified.

C) Submit a tech support trouble ticket on the support page same as you would a camera issue.

If the top swedish mac retailer couldn't get the RAM setup right, did they use the right type/speed memory and what else did they get wrong?
 
Trying to clarify here... So Deanan, you're saying that, for example, running 4 clips of 100 frames in parallel would also take about 9 minutes on the Nehalem, thus actually providing a speed increase after all?

How exactly does one optimize for multiple clips and threads?
 
Charles Angus said:
Trying to clarify here... So Deanan, you're saying that, for example, running 4 clips of 100 frames in parallel would also take about 9 minutes on the Nehalem, thus actually providing a speed increase after all?

How exactly does one optimize for multiple clips and threads?
Click to expand...


How much Ram and the speed of the disk you're writing to along with what size files you're writing are all factors. Additionally, turning on things like scaling, denoise, and olpf compensation also stress the cores differently.

Try different settings and adjust the clips in parallel until you're using as much cpu as possible. If you can't get the cpus all the way up then the disk bandwidth could be blocking the cpus while it's trying to write the files.
 
Charles Angus said:
Here's another question:
Does rendering rely on scratching files to the startup disk or another process that relies on startup disk speed? Is that a possible issue?
Click to expand...

Source drive and destination drive are factors but startup is not (unless it's the source or destination drive). Rendering back to the source drive can also slow things down depending on the drive and the filesystem.
 
Doesn't the virtual memory swapping take place only on the system drive? If so, theoretically it could slow things down if your system drive is slow or fragmented, right Deanan?
 
I'd love an equivalent piece of software for my new, 8 thread i7 Windows system to chew through R3Ds with....

Paul
 
David Didato said:
Doesn't the virtual memory swapping take place only on the system drive? If so, theoretically it could slow things down if your system drive is slow or fragmented, right Deanan?
Click to expand...

Redrushes should not be paging to disk if you have more than 3GB of RAM.

And Paul, the new MetaFuze should be right up your alley...
 
Sadly Premiere Pro CS4 doesn't import MXF files it appears.

So back to my original question to Red - when will we see RedRushes for PCs?

Cheers,

Paul
 
You must log in or register to reply here.
Back
Top