Performance difference between Native and HDX

[Shan]

Originally Posted by nerd513

the only thing the dsp doesnt do is rtas plug ins... it handles all of the playback, record, track builds, aux sends, ect...

Playback, Record, Elastic Audio and other processes are handled by the CPU and disk usage, not the DSP engine at all. It's a lot more than just the exclusion of RTAS.

Originally Posted by nerd513

that can be alot for ur computer to handle and the DSP handles it all beautifully... leaving ur computer for just rtas some screen movements i think and things like reason for example

Again, the CPU in HDX handles more than just RTAS and screen movements. He can take a real world mix, disable all his RTAS and see exactly how much CPU everything else in native uses. On most modern computers, the CPU meter will be at 1% in that scenario, if at all. Not even a dent. Even with all audio playing, the CPU meter will be extremely small as the audio is streamed from the drive, which is disk usage.

MADIrouting is making a decision requiring quite the investment. Your generalized statements aren't all correct and also relate to HD on Mac, not HDX on PC. We have a responsibility to post accurate information, especially when such a large investment is being considered by a fellow user.

Shane

[jjnssn]

Originally Posted by Shan

Not all the threads get used. They've been problematic. ECC memory will also give you a hit in performance.

Shane

Hi Shane,
Thank You again. I see that the thread issue has been resolved with PT10 for this individual. I am going to turn off ECC to see what performance improvement I see.

I had an i7 930 with 12GB of RAM on a GIGABYTE board. For me, I couldn't perceive a significant difference in performance or reduction in error rates when switching to the Xeon system. Yet I also wasn't running a standard test. From the thread you'd sent there appears to be a Dverb test that people use to gauge their system performance. I will see what I can achieve with my setup.

Thanks again for the helpful responses. I am grateful!
Jay

[Shan]

Originally Posted by MADIrouting

Hi Shane,
Thank You again. I see that the thread issue has been resolved with PT10 for this individual. I am going to turn off ECC to see what performance improvement I see.

I had an i7 930 with 12GB of RAM on a GIGABYTE board. For me, I couldn't perceive a significant difference in performance or reduction in error rates when switching to the Xeon system. Yet I also wasn't running a standard test. From the thread you'd sent there appears to be a Dverb test that people use to gauge their system performance. I will see what I can achieve with my setup.

Thanks again for the helpful responses. I am grateful!
Jay

The speed of your RAM is everything when it comes to native. You cant turn off registered RAM, as it's a "type" of RAM. As far as the Dverb test, it is more of a measurement tool to make sure similar systems are in the same ballpark and set up properly. You should also run some real world mixes. It's good to know the Xeon thread issues are resolved in PT 10.x. Keep us posted with your decision.

Shane

[jjnssn]

Originally Posted by Shan

The speed of your RAM is everything when it comes to native. You cant turn off registered RAM, as it's a "type" of RAM. As far as the Dverb test, it is more of a measurement tool to make sure similar systems are in the same ballpark and set up properly. You should also run some real world mixes. It's good to know the Xeon thread issues are resolved in PT 10.x. Keep us posted with your decision.

Shane

So I ran a test Dverb. I have 10.2 HD on my system. With a 44.1khz, 24bit session, a single mono track with a send to a single buss. That buss as the input to 99 stereo aux tracks, I can get 336 Dverb instances. It seems 11 cores at 99% and 1024 buffer size was the most stable where I was able to achieve this # of Dverbs. Based on some other posts that seems quite low.





SYSTEM PC: Windows 7 Professional 64-bit / ASUS P6X58-E WS / Intel Xeon W3680 @ 3.33 GHz /
24GB RAM MEM [4GBx3 CRUCIAL_CT3KIT51272BA1339 ECC Non-Buffered; 2 kits] / Gigabyte nVidia GTX 470 1280MB

[Shan]

Originally Posted by MADIrouting

So I ran a test Dverb. I have 10.2 HD on my system. With a 44.1khz, 24bit session, a single mono track with a send to a single buss. That buss as the input to 99 stereo aux tracks, I can get 336 Dverb instances. It seems 11 cores at 99% and 1024 buffer size was the most stable where I was able to achieve this # of Dverbs. Based on some other posts that seems quite low.

Your Dverb benchmark should be done again. It's in the first post here about half way down. HDX and HD results are here. Keep in mind that the buffer doesn't affect the DSP results, so the throughput latency will always stay the same. The buffer can be at any setting when using strictly DSP plug-ins and it wont affect round-trip throughput latency, unlike native. I noticed your RAM is non-buffered, so you should be fine here.

**Edit - Here's some more Xeon info from our local resident Xeon user. I gave mykhal_c a shout and he fired off that link to me. Hope that helps.

[nerd513]

Originally Posted by Shan

Playback, Record, Elastic Audio and other processes are handled by the CPU and disk usage, not the DSP engine at all. It's a lot more than just the exclusion of RTAS.



Again, the CPU in HDX handles more than just RTAS and screen movements. He can take a real world mix, disable all his RTAS and see exactly how much CPU everything else in native uses. On most modern computers, the CPU meter will be at 1% in that scenario, if at all. Not even a dent. Even with all audio playing, the CPU meter will be extremely small as the audio is streamed from the drive, which is disk usage.

MADIrouting is making a decision requiring quite the investment. Your generalized statements aren't all correct and also relate to HD on Mac, not HDX on PC. We have a responsibility to post accurate information, especially when such a large investment is being considered by a fellow user.

Shane

ok just because u say its true it must be... not... u do indeed need a hard drive to record too but the HD cards do handle playback and record functions thats why they GUARNTEE track count in HD but whatevs its not even my problem

[Shan]

Originally Posted by nerd513

ok just because u say its true it must be... not... u do indeed need a hard drive to record too but the HD cards do handle playback and record functions thats why they GUARNTEE track count in HD but whatevs its not even my problem

Playback comes from the hard drive and not done by DSP or CPU entirely. You even have a separate Disk meter for that purpose, which displays the amount of disk activity. Track count, in the way that it's defined by most people, has never been guaranteed. There's a voicable track limit assigned to tracks for the ability to do simultaneous playback. Even this will change depending on session sample rate and number of DSP chips assigned to the playback engine. This limit does not guarantee audio playback from a drive at all, which many refer to inccorectly as "guaranteed track count".

Here's 256 tracks in HDX with barely a dent in DSP resources:



Here's 256 tracks in HDN with barely a dent in CPU resources:



There is no guarantee, and never has been, that a hard drive can stream back 256 tracks of audio in a 48k session all at the same time, just because a DSP and Native system can easily create those amount of tracks in a session. In fact it cant, as no drive can handle all that audio bandwidth simultaniously without disk based DAE errors long before you even get close. That's why Pro Tools has Disk Allocation, which was created for exactly this reason. The new Disk Cache will also alleviate the disk streaming stress entirely. Avid's supported track count per one 7200rpm firewire drive is 24 tracks at 24-bit/48 KHz. Obviously this will vary greatly on drive type and now Disk Cache. Guaranteed audio playback is determined more so from the Hard Drives bandwidth, not DSP or CPU as many seem to promote incorrectly and call it "guaranteed track count".

I'm not trying to dig into you here so please dont take offence. This has nothing to do with what "I say", as it's simply how Pro Tools functions and I posted Avid references to support this. People seek precise information when making this type of very costly investment, and they deserve to have it. MADIrouting moved his inquiries to email as he needs very accurate info before laying down the cash. He even wants to make sure his type of sessions and workflow will perform and do what he needs. I know it will, but I'll still demonstrate this to him unbiased, so he can make a better informed purchasing decision. I see no problem with this. We're all on the same team here.

Shane

[The golfer]

Here's 256 tracks in HDN with barely a dent in CPU resources

Great infos!

I don't have an HD native system but I believe that for very large 5.1 sessions, the HDX system takes a good load off the CPU. In your example, the difference is only 7% (HDX mix engine using less than 2 dsp chips) but it seems, and I might be wrong, that all 256 tracks are bussed to the same output. My 5.1 sessions use about 4.5 dsp chips for the complete mixer routing. It's not that much but the mix engine is something less the CPU have to deal with...

[Shan]

Originally Posted by The golfer

Great infos!

I don't have an HD native system but I believe that for very large 5.1 sessions, the HDX system takes a good load off the CPU.

For very large surround mixes at low latencies and high sample rates, HDX would definitely be the better way to go. You might be able to do it natively on the fastest multi CPU system out there, but you'll probably run out of voices very quick when it comes to surround. I dont think we're quite there yet to do a big Hollywood production in 5.1 or 7.1 at 96k with a buffer of 32 in Native. That would have to be HDX territory.

Shane

[TOM@METRO]

And even with sessions that may not be too much for Native, but do come close to that threshold, HDX can make things a little simpler and faster. So, if you have the bucks to spare, why not go with the Ferrari?