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

tried the same with my 2,26 8 core (16GB Ram) getting the same results as you with the 3K full debayer of about 5min/100 frames. Didn´t try 4K yet.

Manuel
 
Manuel Wenger said:
tried the same with my 2,26 8 core (16GB Ram) getting the same results as you with the 3K full debayer of about 5min/100 frames. Didn´t try 4K yet.

Manuel
Click to expand...

Very interesting - so, I'm not "seeing" things...

So, there is then a full debayer with RSX nehalem bug/incompability...!?

Red...

j.
 
This is very interesting as I'm starting a project next week we have 2 X 8 core N chip Mac pros. I will run these tests on them tomorrow and Thursday will report back my results.

In the mean time would really appreciate a response from Red about an official 'bug' or not to that matter. When running RR with the new 8 core for better results than the old Macpro and a way to improve performance.

Thanks guys.
 
jacknusa said:
ok, I'll try some more RAM - how much RAM do you other 8core Nahelem users have installed?
Click to expand...

I like to have 1 GB per core, or increments there of. 8 cores would take 8 GB RAM, or 16. I only use Apple RAM. I didn't like the stock configurations on the new machines, 6 GB! If you go that route, you can't load up the machine to 16 using 2 GB DIMMS with out throwing away your stock RAM.

Also, I ALWAYS full debayer my transcodes.
 
Deanan said:
No. That's why REDrushes can run multiple clips in parallel to take advantage of all the cores. Load up multiple clips and adjust "Clips at once" and "Core's per Clip". Testing only one clip with RR is misleading because it's meant to be used for rendering multiple clips in parallel.
Click to expand...

I would think that Redcine would be a better tool for benchmarking.
 
I don´t rely on Redcine, it crashes a lot more than Redalert / REdLine via redrushes in m Opinion.

Just another benchmark, debayering 3K with half res (high) via Clipfinder to Pro Res HQ 1920x1080 runs at 12 fps on my 2x2,26
3K via Full Res debayering to the same settings runs at arround 1 fps on the Nehalem and at 0,6 fps on 2 x 3,2 Quad Core.
via Clipfinder

Manuel
 
Brandon Kraemer said:
I like to have 1 GB per core, or increments there of. 8 cores would take 8 GB RAM, or 16. I only use Apple RAM. I didn't like the stock configurations on the new machines, 6 GB! If you go that route, you can't load up the machine to 16 using 2 GB DIMMS with out throwing away your stock RAM.

Also, I ALWAYS full debayer my transcodes.
Click to expand...

Wegner, a few posts up have 16GB RAM and he's getting the same results as me.

J.
 
I also have a one 4 core MacPro, but I noticed another thing. Just changed from 10.4.11 to 10.5.6, and had about 20% loss in speed. New stuff is not always better.
 
jacknusa said:
Wegner, a few posts up have 16GB RAM and he's getting the same results as me.

J.
Click to expand...

Yea, I saw that. I wasn't suggesting this would fix the issue your having with the transcode times, it's just a rule of thumb I like to follow when I configure machines, it seems to keep AfterEffects multi-processor rendering more stable for starters.
 
can you post a screenshot of your settings in redalert of the specific clip/rsx file?
 
Manuel Wenger said:
I don´t rely on Redcine, it crashes a lot more than Redalert / REdLine via redrushes in m Opinion.

Just another benchmark, debayering 3K with half res (high) via Clipfinder to Pro Res HQ 1920x1080 runs at 12 fps on my 2x2,26
3K via Full Res debayering to the same settings runs at arround 1 fps on the Nehalem and at 0,6 fps on 2 x 3,2 Quad Core.
via Clipfinder

Manuel
Click to expand...

These days that is definitely not true. If you you dont touch Redcine while its rendering (keep it as the foreground app) it is significantly more stable than RR. RC was a bit of a nightmare when it first came out but its gotten substantially more stable in recent time. RR is fairly stable without any burnin options but if you start customizing your burnins its crash city.
 
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...
 
Not sure if this will help but I did a test today on an 8 core N Macpro. I added more than 6 clips to run in RR all clips were 4K 2:9 RC36 25FPS. I set RR to export QT Prores422 at half debayer, no burn in and scaled them down to 1080. The rushes were on one raid and the output was on a separate raid tower (SCSI channels).

I processed the clips twice, once with 6 clips at once and 'auto' clips per core selected in the settings. In 30sec RR output a combined 148 frames from all 6 clips.
The second time was with 4 clips at once and 2 cores per clip selected in the settings i.e. 8 cores working. In 30 sec RR output a combined 133 frames from all 4 clips.

A side note RR completed exactly 33 frames on each of the clips when selecting 4/2 and various different numbers of frames when 6/auto in 30 sec.

I'm assuming that RR would have used all 8 cores in the 6 clips at once option. Then allocated different numbers of cores according to the number of frames each clip had. More frames more cores less frames...

My question is if in both cases all cores where used on similar material why was there a difference in the number of frames processed at the end of the same period of time?

P.S
I didn't have a 4 core to bench mark it against but found these results interesting.
I did a few other tests with 6 clips at once. I found RR about 5 min into a batch of clips started to process additional clips on top of the first 6. It was processing 8 clips at once. Does RR allocate 2 clips per core if the clips are small enough?
 
Emery Wells said:
RR is fairly stable without any burnin options but if you start customizing your burnins its crash city.
Click to expand...
I´ve found RR to be perfectly stable with burn-ins on the pre-Nahelem procs. Haven´t upgraded to Ns (maybe not such a bad thing at the moment!), so no info on that.

One thing to make very sure of, if you don´t know already, is when customising burn-ins you NEVER use the colour picker - instead always use the sliders of you want to alter the colours (I hate the standard yellow personally, although it´s of infinitessimal importance of course!). Using the colour picker for burn-in text will crash RR more often than not...

FWIW, well treated and left in FG, RC is pretty bloody solid as well - I use RR for proxy generation and RC for finalising, on most projects. I wish a fix for the clip limit crash in RC would come out, but other than that I´m pretty much as happy as Larry!

Cheers,
Dom.
 
Using Clipfinder i get 0,6 fps speed for a single clip full debayer 3K to Prores HQ and on the Nehalem i get 0,32 fps.....

I might give Redcine another chance...

Manuel
 
How much faster?
 
The sweet spot for the Nehalem 8 core seem if it can process 8 or more tasks in parallel. From my earlier post my 8 Core rendered 3K in full debayer to ProRes HQ 1080 with arround 0, 3 fps in Clipfinder, if i crank up the number of clips for rendering, i can speed that up to 3,2 fps if Clipfinder is processing 8 or more clips simultaneosly.

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