Could this be why the Nehalem Mac's aren't faster?

[hogo]

Nehalem Mac Pros take 20% performance hit when playing audio? | 9 to 5 Mac

Note the part about audio interfaces, which most of us use.

[Timur Born]

OS X' Speedstep kernel driver (kext) was already bugged in Leopard. I used to disable it completely and control CPU frequencies via Coolbook. It leads to better audio performance especially with *low* CPU load and small audio buffers, but also a bit with high load (can squeeze a bit more out of the machine without dropouts).

One problem of that kernel driver is that even under full load it keeps switching back the CPU to its lowest clock multiplier for very brief moments.

[Timur Born]

** Critical ** Windows 7 DAW Tweak .... Disable CPU Core Parking

[Alndln]

Originally Posted by Timur

** Critical ** Windows 7 DAW Tweak .... Disable CPU Core Parking

Thanks for that.

[valis]

There were some rumors back in Oct/Nov 2009 that MS was originally going to put a negative recommendation against the nehelem Xeons for use with Server2k8, but backed down 'under pressure from Intel' (paraphrasing what I had read, which is just hearsay.) The reason given then was that activating not just full core sleep (parking) but also any of the turbo modes was causing "spurious interrupt" calls so frequently that it was swamping the ability of Server2k8 based servers to handle i/o calls efficiently...

Seems similar enough to the discussion here to warrant a mention (think I posted this in the hyperthreading thread here and one other one at the time, hoping to prompt someone with an i7/nehelem era machine could monitor interrupt usage with C1E, Core parking and Turbo both active and disabled.)

[caesura]

Does anyone know when the next MacBook Pros are scheduled for release, and if they will fix this or not?

[Firechild]

Originally Posted by caesura

Does anyone know when the next MacBook Pros are scheduled for release, and if they will fix this or not?

This is about the "Mac Pro".

[caesura]

Originally Posted by Firechild

This is about the "Mac Pro".

Aaaah, oops, um, so now I have to ask. Are the MB pros free of this problem?

[Phigwalla]

Originally Posted by caesura

Are the MB pros free of this problem?

Yes. The laptops use core 2 duo cpus, this only affects the Nehalem cpus used in the Mac Pro desktops. (based on what I've read about the issue)

[a.beck]

Has this been addressed in SnowLeopard? Considering an upgrade, and this would make my decision for me.

[Phigwalla]

The following site is collecting info on the issue.

2009 Mac Pro audio/firewire/power bug (09MP bug)

[Squawk]

related thread:

"Nehalem Mac Pros Have Serious Problems With Audio Processing" - Gizmodo Article

[TAFKAT]

Originally Posted by Timur

** Critical ** Windows 7 DAW Tweak .... Disable CPU Core Parking

There is a lot simpler way instead of modifying registry entries.

Simply using the High Performance power management scheme, disables core parking.

[norbury brook]

Vin,

I'll post a quote from that thread;

''Hi all

FWIW I can clarify the following.

I have a Core i7 Xeon 4.2 gig quad-core [ 8 cores in total ] DAW.

I have a simple Sonar 8.X test project.

- 72 Tracks each running 1 x Sonitus Verb 1 x Sonitus Comp and 1 x Vocal Strip - all input monitoring on, all at 32 Samples / 0.7ms latency @ 24/44.1 - Layla 3G ASIO driver - in total, 216 EFX input monitored.

On my DAW the above project has my CPU sitting around %83 but even at these high loads, the CPU spiking - especially with the Sonar 8.5 meters is massive - constant and erratic "amber-ing" and " red-ing " on the cores bouncing all over the place - Windows Task manager reports a similar story.

Turning the Power Mgt to " always on " or " full " or whatever does not change or fix this.

The only thing that does is the reg edit in my first post.

I dont know how hard / high Noel and the team were testing this issue, but the above is my reality and the fix " fixed " it to being perfectly even and flat subject to the * in my first post.

To me, this is a no-brainer tweak with zero downside [ other than it effectively stifles power mngt - but who cares in a dedicated DAW ] and a massive upside ie: all cores all on deck all at the same time all sharing the load evenly regardless of overall CPU load regardless of a small-cpu-load-project or a massive-cpu-load-project.

If you dont want to do the tweak please dont - but other than the power saving caveat above - I cant think of any reason not to do it - there is only upsiade.

Tom''



intersetingly it didn't work work this guy.

MC

[valis]

Windows users wanting to try that tweak might want to grab a copy of Coretemp and keep an eye on things, stock Intel cooling (and many OEM systems) use cooling that assumes you'll be running within the original TDP and while disabling core parking and setting to the highest performance profiles shouldn't allow the cpu to exceed that, machines that were already warm will likely see an increase in cpu temps.

I would wonder if disabling Speedstepping & core parking on Mac Pros has even more of an effect especially on the faster cpu machines, given that some of these already seem to run rather warm. On the upside their cooling is certainly better than Intel's stock aluminum fins.

[TAFKAT]

Originally Posted by norbury brook

Vin,

intersetingly it didn't work work this guy.

MC

Hmmm,

I'll have to have another dig at it when I get a few minutes.

I have never needed to do the reg edits to disable core parking , and the High Performance Power profile also has some extra settings that need to be disabled from the default. I am wondering if its also linked to C Halt states , EIST as I always disable those setting by default.

SONAR at 032 samples has always fallen on its arse compared to the other native DAW's , so I'll be interested if in fact this reg tweak helps matters. It would in theory also help the other DAW's as well.

I did witness a bizarre sawtooth ramping of CPU loads in TM under extreme sessions at 96K in Cubendo , which was not effecting the performance, more a visual/monitoring anomaly I first believed , but maybe this has something to do with it.

I'll drop back after I have done a few more tests..

[valis]

EIST *is* speedstepping, so disabling that disables all C-states afaik including core parking (and I would guess P-states as well.) C1E halt is the EIST version of C1 halt (C1 halt was improved for multicore cpu's with C1E.) Technically Nehelem uses "Enhanced EIST"... again though if you disable speedstepping entirely just make sure you have adequate cooling & airflow (especially on a Mac Pro!)

[TAFKAT]

Originally Posted by valis

EIST *is* speedstepping, so disabling that disables all C-states afaik including core parking (and I would guess P-states as well.) C1E halt is the EIST version of C1 halt (C1 halt was improved for multicore cpu's with C1E.) Technically Nehelem uses "Enhanced EIST"... again though if you disable speedstepping entirely just make sure you have adequate cooling & airflow (especially on a Mac Pro!)

That is not correct.

EIST operates independently of the C Halt States, you can have the EIST disabled and the C Halt states are still in play. I think some of the higher C Halt states arbitrate the Core Parking, and as I have always disabled them by default, that could explain why I have never experienced it.

Re Cooling, the only time EIST is of any benefit is at idle or at very low CPU usage, which is of little to no use on a DAW, so the cooling of system from the outset should be designed to be able to handle higher CPU usage. The standard CPU coolers packaged with the chips are near useless for anything past minimal use IMO. Any good 3rd party heatpipe cooler will be fine.

[valis]

Ok well thanks for the correction.

Since the EIST moniker is indeed speedstepping (Enhanced Intel SpeedStep® Technology) and since disabling EIST in the bios always disables speedstepping in my experience as well I had figured the two were connected always. I do have C1-4 and C1E exposed in the bios settings on my system, and disabling EIST disabled Speedstepping altogether (regardless of what C-states I allowed.) If that's not the case on Nehelem Xeons then I appreciate the correction (I'm on harpertowns still.)

At a few forums for webhosts / enterprise IT chat stuff they had reported that disabling speedstepping on nehelems required at least the passive copper coolers with a fan added (or better aftermarket coolers) to keep system temps in their preferred target range. I know that my older Harpertowns run considerably cooler and so disabling C1E/EIST in bios and setting the OS to run in high performance mode does increase my temps in the system (which are already warm due to the fb-dimms) so I have to run the fans at a higher profile to keep things under my preferred target temp for the system.

My Core2 era laptop is even worse when running full throttle via bios & windows settings, and I've heard that when people use Macbook Pros with the speedstep disabler (which is the only way of doing this on the Mac Pro that I know of offhand) they get extremely warm (although technically within tolerances still.) Given that the 45nm nehelem derivatives are known for running warmer than normal and that some people already report uncomfortably warm temps in their 2009 Mac Pro's I figured it might be a good thing to look out for. But if I'm mistaken in my understanding it's certainly good to know where...

[TAFKAT]

Originally Posted by valis

Ok well thanks for the correction.

Since the EIST moniker is indeed speedstepping (Enhanced Intel SpeedStep® Technology) and since disabling EIST in the bios always disables speedstepping in my experience as well I had figured the two were connected always. I do have C1-4 and C1E exposed in the bios settings on my system, and disabling EIST disabled Speedstepping altogether (regardless of what C-states I allowed.) If that's not the case on Nehelem Xeons then I appreciate the correction (I'm on harpertowns still.)

EIST /Speed stepping is dynamically controlled via software i.e the O.S , power consumption /heat is reduced by clocking the CPU down at lower usage , C Halt states are processor level modes thats are designed to reduce power consumption by halting specific sections of the CPU when not in use , which may or may not reduce clock frequency. They are directly related to the ACPI.

Although EIST and C Halt seem to do similar things, they are totally different processes.

At a few forums for webhosts / enterprise IT chat stuff they had reported that disabling speedstepping on nehelems required at least the passive copper coolers with a fan added (or better aftermarket coolers) to keep system temps in their preferred target range. I know that my older Harpertowns run considerably cooler and so disabling C1E/EIST in bios and setting the OS to run in high performance mode does increase my temps in the system (which are already warm due to the fb-dimms) so I have to run the fans at a higher profile to keep things under my preferred target temp for the system.

But the higher temps would only be at idle to moderate , when running flat out there should not be any more heat generated as EIST/C Halt would/should not be in play. This is on Windows, all bets are off with OSX, as OSX cannot arbitrate EIST, and who knows whats actually happening with the C States with the MACPro EFI.

Re Harpertown v Nehalem Dual Socket Systems , the prior generated enormous heat via the FB DIMMs / Northbridge as you noted, while the Nehalems run a little hotter but the memory runs way, way cooler . I have always used 3rd party heatpipe coolers on my Dual Xeons Systems , I wouldn't trust the Intel units as far as I could throw them.. :-)

My Core2 era laptop is even worse when running full throttle via bios & windows settings, and I've heard that when people use Macbook Pros with the speedstep disabler (which is the only way of doing this on the Mac Pro that I know of offhand) they get extremely warm (although technically within tolerances still.) Given that the 45nm nehelem derivatives are known for running warmer than normal and that some people already report uncomfortably warm temps in their 2009 Mac Pro's I figured it might be a good thing to look out for. But if I'm mistaken in my understanding it's certainly good to know where...

Yes the laptops will run considerably hotter at idle to moderate as well, but under load there shouldn't be any more heat stress placed on them.

I think the problem with the MacBooks running way too hot was that the fans never ran fast enough to efficiently cool the chips sufficiently , add to that a design that was focused more on form over function. Not sure about the Nehalem MACPro's, haven't really been following the chatter about temps there, more so just the lack luster performance.

[The Beatsmith]

oh how i love my early 2008 octo 2.8ghz

[ekwipt]

I've got one too, looks like i'll be holding on to it for a while, especially since logic studio is now 64 bit, i think I'll be waiting at least until 2011, unless something drastically changes.

Will this most likely effect the new Macbook Pros if/when apple release them, could be the reason why they're taking so long for a refresh?

10.6.3 supposedly fixes issue pertaining to Logic 64bit, so maybe they're waiting for this release to unleash the new Macbook Pros???

[valis]

Originally Posted by TAFKAT

EIST /Speed stepping is dynamically controlled via software i.e the O.S , power consumption /heat is reduced by clocking the CPU down at lower usage , C Halt states are processor level modes thats are designed to reduce power consumption by halting specific sections of the CPU when not in use , which may or may not reduce clock frequency. They are directly related to the ACPI.

Although EIST and C Halt seem to do similar things, they are totally different processes.

Ok I see where we're confused I think.

Ok so I do understand the difference between hardware controlled C1/C1E and OS controlled EIST via ACPI. And my understanding is that "technically" EIST is for managing processor P-states (voltage) in the C0 state only (correct? voltage control for power consumption reduction in lower processor states than fully active?) And so C1 (halt) is independant of power, at least until C1E also brought the ability to execute HLT and put the core into it's lowest halt state along with a transition of that core into lowest P-state (voltage & multiplier/frequency drop.)

And I understand what you're saying about Speedstepping (and Enhanced EIST) being a mechanism invoked from the OS via ACPI versus the C1 states (which are not as finely grained either I think?)

BUT, my understanding was also that in the cpu C1E and EIST are using the same EIST circuit (for P-states) via IA32_PERF_CTL. So when I disable EIST in my Bios I see all C-states unselectable as well, and so assumed that this register was disabled removing support for both. I do understand though that some cpu's (or chipsets?) can support EIST but not C1E, or C1E but not EIST (though I think with C1E only, just a portion of EIST logic is enabled - it will only do the maximum and minimum P-state.).

I think the confusion is just that I haven't seen a bios support both where turning EIST off didn't disable both (perhaps because I run Supermicro/Intel hardware and not consumer/overclocker?) so I assumed the mechanism was the same for both in the hardware implementation. I've not been intimate with the x86 architecture on that low of a level in a few decades tough so I am not surprised if my understanding is flawed.

Originally Posted by TAFKAT

But the higher temps would only be at idle to moderate , when running flat out there should not be any more heat generated as EIST/C Halt would/should not be in play. This is on Windows, all bets are off with OSX, as OSX cannot arbitrate EIST, and who knows whats actually happening with the C States with the MACPro EFI.

Re Harpertown v Nehalem Dual Socket Systems , the prior generated enormous heat via the FB DIMMs / Northbridge as you noted, while the Nehalems run a little hotter but the memory runs way, way cooler . I have always used 3rd party heatpipe coolers on my Dual Xeons Systems , I wouldn't trust the Intel units as far as I could throw them.. :-)

This I agree with as well, higher temps would only be in situations where you're not under full load all the time. Another way of saying it though is that by disabling all power management of the cpu you're running everything full throttle all the time. Not a bad thing for audio for sure but for those who don't actively manage their own machines and/or build them I worry about cooling issues, especially with lower tier vendors. Ie, home & project studio users who might attempt to tweak things thinking they'll buy more performance.

Also it makes the assumption that all audio users are running 100% usage anyway. While that's certainly probably true for very productive studios and people who are capable of managing their own hardware, again I am not sure about the home/project users (I know that I for instance rarely see more than 50-60% usage of either of my 2008 Xeons unless I'm doing visualation work, 3d rendering or gaming.)

As for the 2009 Mac Pro, I can only draw from what I've read from people online seeing warmer temps. Though I haven't heard of that causing failures I just worry about 50-60C temps inside my machine, let alone the issues where the new Nehelems are showing 80-90C errata.

And yes, I fully agree that my MCH & fb-dimms are the hottest parts in these machines, but the nehelem thermal issues were reported across the line (ie, not restricted to Xeons and even including in laptop usage.)

Originally Posted by TAFKAT

Yes the laptops will run considerably hotter at idle to moderate as well, but under load there shouldn't be any more heat stress placed on them.

I think the problem with the MacBooks running way too hot was that the fans never ran fast enough to efficiently cool the chips sufficiently , add to that a design that was focused more on form over function. Not sure about the Nehalem MACPro's, haven't really been following the chatter about temps there, more so just the lack luster performance.

I think the fans were one issue, though that was supposedly addressed with a later patch (which people then complained about because it was making their fans louder.) There are also gpu issues mixed in there as well, but the heat dissipation issues of Apple's laptops is a notorious issue (and a soft spot from the G5 days for Apple fans.) It's been my guess that this is why we haven't yet seen anything beyond Core2 for Apple even though it's been on the market now for almost half a year.

[acoustic12]

Originally Posted by TAFKAT

SONAR at 032 samples has always fallen on its arse compared to the other native DAW's , so I'll be interested if in fact this reg tweak helps matters. It would in theory also help the other DAW's as well.

I did witness a bizarre sawtooth ramping of CPU loads in TM under extreme sessions at 96K in Cubendo , which was not effecting the performance, more a visual/monitoring anomaly I first believed , but maybe this has something to do with it.

I'm currently testing dual Xeon workstation with 16 cores. I was able to crash (blue screen) the computer under Sonar demo 18 tracks, at 32 samples. Four times in a row.

Win7 64bit
Sonar 8.5 PE 64bit
Dell Precision dual Xeon 2.26G (16 cores)
6 Gig RAM
10k Raptors
Lynx L22 Win7 driver
HT disabled
Intel Turbo enabled


I've tried everything, including disabling/enabling Intel turbo, hyper-threading, speedstepping, C states.. you name it.

RE: core parking, changing registry key does nothing. Sonar parks 8 cores no matter what.

[valis]

Shouldn't have any relation to bsod's though, normally that's a resource conflict causing a driver to write into the wrong address space. Make a different thread for this issue and we can probably help troubleshoot...

[25ghosts]

Originally Posted by hogo

Nehalem Mac Pros take 20% performance hit when playing audio? | 9 to 5 Mac

Note the part about audio interfaces, which most of us use.

Definitely something weird going on in this regard.

If I have itunes open and my iPhone connected I cannot use any of my iLoks which are sitting in the USB ports - they wont be recognized by the apps and thus I cannot run my plugs. Closing iTunes and removing the iPhone is my only remedy.

[TAFKAT]

Originally Posted by valis

BUT, my understanding was also that in the cpu C1E and EIST are using the same EIST circuit (for P-states) via IA32_PERF_CTL. So when I disable EIST in my Bios I see all C-states unselectable as well, and so assumed that this register was disabled removing support for both. I do understand though that some cpu's (or chipsets?) can support EIST but not C1E, or C1E but not EIST (though I think with C1E only, just a portion of EIST logic is enabled - it will only do the maximum and minimum P-state.).

I think the confusion is just that I haven't seen a bios support both where turning EIST off didn't disable both (perhaps because I run Supermicro/Intel hardware and not consumer/overclocker?) so I assumed the mechanism was the same for both in the hardware implementation. I've not been intimate with the x86 architecture on that low of a level in a few decades tough so I am not surprised if my understanding is flawed.

Hey Valis,

When disabling EIST in the BIOS on your SM board, is it actually disabling the C-states or simply not giving you the option to adjust the states. It will be interesting to see whether the C-States are still active- C1E would be the main focus.

Easy enough to check , set C1E on in BIOS, then disable the EIST and then check the clocking with CPU-Z , which communicates directly to the chip via CPUID. If the C1E states is still active it will report the CPU clocking down , even with EIST disabled

Windows simply reports the CPU's at full clock , when in fact they are being ramped down.

On the current single socket boards, C States and EIST are total separate in the BIOS, you can disable them individually without effecting the others.

If you disable EIST without disabling C1E and the other C States the hardware clocking control is still active. Turbo Boost is another variable as well, but that only clocks the CPU up, not down.

FWIW: The Tyan 5400 boards that were the same series as your system had access to C states, but didn't have an option to disable EIST , so every BIOS will be different. Same on single socket boards, except it was the opposite ,some have access only to EIST, not to C-States.

From what I have experienced its imperative to disable the C states on a workstation where possible. Some anomalies unrelated to clocking that I experience on my current X58 development system with the C states active range from high pitched whining from the VRM's to earthing artefacts in professional PCI/PCIe audio cards , to even stranger occurrences in OSX with mouse / GUI causing the VRM/earthing issues.

Disabling the C Halt and EIST and it all goes away.

The power management states and their associated anomalies are a constant enigma to me at times.

This I agree with as well, higher temps would only be in situations where you're not under full load all the time. Another way of saying it though is that by disabling all power management of the cpu you're running everything full throttle all the time. Not a bad thing for audio for sure but for those who don't actively manage their own machines and/or build them I worry about cooling issues, especially with lower tier vendors. Ie, home & project studio users who might attempt to tweak things thinking they'll buy more performance.

Also it makes the assumption that all audio users are running 100% usage anyway. While that's certainly probably true for very productive studios and people who are capable of managing their own hardware, again I am not sure about the home/project users (I know that I for instance rarely see more than 50-60% usage of either of my 2008 Xeons unless I'm doing visualation work, 3d rendering or gaming.)

Sorry I didn't explain that too well, what I meant by flat out was only in reference to the clock speed being flat out , so at low to moderate load there would be a temp advantage , but not once the CPU clocks to full speed.

With the Cooling, system burn ins at build/development should be at 100% load for long periods to ensure the system will be capable of handling extreme work loads, so on 50-60% working environments, there is still plenty in the tank.

Of course that would be valid for professional workstations, but I doubt that would be a priority for more domestic usage, and thats were some users could get themselves into a trouble with cheaper alternatives.

[TAFKAT]

Originally Posted by acoustic12

I

I've tried everything, including disabling/enabling Intel turbo, hyper-threading, speedstepping, C states.. you name it.

RE: core parking, changing registry key does nothing. Sonar parks 8 cores no matter what.

Hmmm,

Interesting , and you have changed the power profile to performance and adjusted all of the extra optional settings to be always on ?

BTW: Why would you turn off HT ?

Re The BSOD's , thats pointing at something deeper, and Valis is right maybe the wrong thread..

[valis]

Originally Posted by TAFKAT

Hey Valis,

When disabling EIST in the BIOS on your SM board, is it actually disabling the C-states or simply not giving you the option to adjust the states. It will be interesting to see whether the C-States are still active- C1E would be the main focus.

Easy enough to check , set C1E on in BIOS, then disable the EIST and then check the clocking with CPU-Z , which communicates directly to the chip via CPUID. If the C1E states is still active it will report the CPU clocking down , even with EIST disabled

Windows simply reports the CPU's at full clock , when in fact they are being ramped down.

On the current single socket boards, C States and EIST are total separate in the BIOS, you can disable them individually without effecting the others.

If you disable EIST without disabling C1E and the other C States the hardware clocking control is still active. Turbo Boost is another variable as well, but that only clocks the CPU up, not down.

FWIW: The Tyan 5400 boards that were the same series as your system had access to C states, but didn't have an option to disable EIST , so every BIOS will be different. Same on single socket boards, except it was the opposite ,some have access only to EIST, not to C-States.

From what I have experienced its imperative to disable the C states on a workstation where possible. Some anomalies unrelated to clocking that I experience on my current X58 development system with the C states active range from high pitched whining from the VRM's to earthing artefacts in professional PCI/PCIe audio cards , to even stranger occurrences in OSX with mouse / GUI causing the VRM/earthing issues.

Disabling the C Halt and EIST and it all goes away.

The power management states and their associated anomalies are a constant enigma to me at times.

TAFKAT, my bios settings expose the following under the 'advanced processor features' section:

• Thermal Management 2 (TM1/TM2/ETTM) as cpu throttling methods in overheat conditions
• C1/C2 Enhanced mode (enabled/disabled)
• Intel EIST Support (Disabled/GV1&GV3 Only/C States Only/Enabled)
• C States Supported (C1/C1C2/C1C2C3/C1C2C3C4)

My understanding is that Thermal Management 2 (TM1/TM2/ETTM) sets the cpu throttling methods used in overheat conditions (ETTM applies TM1 methods even when TM2 has been active if TM2 alone doesn't reduce thermal conditions enough.)

When I read up on "C1/C2 Enhanced mode" it seemed to mean that EIST can use these states to reduce voltage as well as clock with the cpu in active mode (not just under halt/idle cpu conditions) and when "C States Only" was selected for EIST support voltage changes stopped. Intel's documenation seemed to say that when EIST is disabled but C1E is enabled, the processor will not change its clock speed and voltage when it is executing instructions no matter what the load (10% or a 100%.) It will change its frequency and voltage only when it starts sleeping (C1, C2 and etc.). Setting C-states only did indeed show this in cpu-z.

Now I realize that this is just what the BIOS exposed, so in reading Intel's documentation and various articles about EIST online it seemed to me that the register I referred to above is the mechanism used by both. However when the hardware performs control it isn't able to set as many values for the register, hence why non-EIST mode has fewer states overall and doesn't support some of the P-states. Again this was just my understanding, but my Core1 & Core2 era machines all reflect this in bios including single socket Supermicro & Intel boards. It's quite possible that this is again just a peculiarity of using workstation/server hardware only though (I know that a lot of overclocking boards are even more confusing as taking the board out of 'auto' modes can make the P-states very confusing since there is so much control over the voltages.)

And again, I don't have a nehelem-generation machine at the moment to investiagate the C1 Halt full core parking (core powered down) issues, but it does seem as if there's something afoot there. I've seen the C1E/Halt 'vrm noise' issue reported on quite a few different models of motherboards for x58 & 5500 series boards, so it was good that you mentioed that . I also keep mentioning that I've now seen several reports of high-usage RAID & bonded 10-gig ethernet i/o issues reported that seemed related to the amount of hardware interrupt calls generated by Nehelem cpu's under EIST & C1E alike. As a user of DSP cards and Asio/Core audio cards, seeing other high i/o situations that are being throttled by high interrupt calls from power saving features bothers me...I've dealt with PCI bandwidth & i/o issues too much over the years.

Originally Posted by TAFKAT

Sorry I didn't explain that too well, what I meant by flat out was only in reference to the clock speed being flat out , so at low to moderate load there would be a temp advantage , but not once the CPU clocks to full speed.

With the Cooling, system burn ins at build/development should be at 100% load for long periods to ensure the system will be capable of handling extreme work loads, so on 50-60% working environments, there is still plenty in the tank.

Of course that would be valid for professional workstations, but I doubt that would be a priority for more domestic usage, and thats were some users could get themselves into a trouble with cheaper alternatives.

I understood you and agree, I was just stating that many home users (who may read here) might fit the last category as well as those who have done burn-in on their systems (I always do before even bothering with OS isntall & system configuration.) Overall though I think that the core-clocking itself isn't probably a problem (it's been present in desktop PC's since the P3 and more active in even the netburst/P4 era than I think people realized.) The issue here is that Nehelem systems are showing a wide variety of issues (as mentioned above) and most seem related to core parking and/or the fine-grained nature of the multicore C1E/EIST in these latest generations of cpu's.

[Big Boss Man]

This subject has been under discussion for many months at Mac Rumors:

Audio Decoding KILLS MacPro (2009) green factor - Mac Forums

I believe people over there were the first ones to uncover it. The performance and heat problems when running audio apps with Nehalem Mac Pros only happens in OSX. The same machines running iTunes under Windows in bootcamp do not have this problem. It is believed to be a problem with an OSX kernal extension. The good news is this is finally getting a lot of press and now Apple has to do something about it.