This is reproducable on an LGA1366 based Hackintosh as well. The differences that exist doesn't matter, such as ECC memory, as that's not affected by the issues seen.
What exactly are you using for a Hackintosh (not sure I'm recalling correctly
)?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Audio Decoding KILLS MacPro (2009) green factor
- Thread starter handheldgames
- Start date
- Sort by reaction score
)?
What exactly are you using for a Hackintosh (not sure I'm recalling correctly
check his sig! i7 920 + EX58-UD5 + 4890.
Great work Cindori!
Cindori, Thanks for the great work!
Please do release that patch here on the forum even if you can't solve the performance issues. Even with the effect of the patch limited to solving the overheating, sleep and power usage issues, as shown in the post above on the prior page, that would be great. My work partner has an affected 2009 quad core model and I am sure he, and many others as well, would be delighted to have even a partial fix as it seems to address the most serious issue, overheating.
In any case, thanks again for the time and effort involved!
Cindori, Thanks for the great work!
Please do release that patch here on the forum even if you can't solve the performance issues. Even with the effect of the patch limited to solving the overheating, sleep and power usage issues, as shown in the post above on the prior page, that would be great. My work partner has an affected 2009 quad core model and I am sure he, and many others as well, would be delighted to have even a partial fix as it seems to address the most serious issue, overheating.
In any case, thanks again for the time and effort involved!
You should be able to test your code mods on the hackintosh then, as well as obtain results from others.
Obviously there will be differences in your hack vs. a '09 MP, but they shouldn't affect the results drastically (if at all actually), as the CPU, chipset, and ICH are identical (CPU differences don't matter - ECC isn't part of the issue).
I forwarded this to my contact at Apple, just corrected some typos.
I also requested a case / bug ID.
Got an automated answer, will let you know how things progress.
Attachments
yes I am going to charge $ 40 for the fix
lmao, no way
Aha, I knew it!
Look guys, my last post here. This audio issue has trampled me. It's like an open wound I need to let heal and I always end up causing trouble anyway. Like now for instance...
Cindori, at such a young age I can only imagine how successful you'll be. There's an unmistakeable sense of talent you give off.
But, the patch has me worried. I wrote someone today who smacman knows well of, and while I don't know if what he says is true or not, what he wrote to me might still be relevant, or at least something to keep in mind while creating a patch.
Referring to you, Cindori, I said this and his answer and another Q&A follows:
"he thinks that by doing something to the "AppleCPUpowermanagemtn kext" that the situation will change for the better."
"By destroying this part of the operating system, the processor will no
longer enter the power saving states that are necessary to detect and enable
Intel Turbo Boost mode. It is correct that this will avoid the effect some
people mistakenly see as being "bad".
"but what do you think about messing with this file, or any file to make a difference here. Could he be stifling what the system as you say is designed to do?"
"Yes. But depending on what you do, the system could consume much more energy after the manipulation."
That's it. That's all I wanted to pass along. Keep in mind that he thinks manipulation of the file is essentially "destroying" it's purpose.
OK, with that out of the way, I wish you Cindori, and the rest of you here the best of luck and success. Just don't lose your mind over this like I have many times already, to my regret. Apple may just have to learn the hard way that "Time wounds all Heels"
There is a reason I have not released it. Yet.
I am very well aware of the issues with Speedstep and Turbo. I am pretty sure you can enable these natively by using tricks from the Hackintosh scene.
That's what I'm working on.
Also, "destroying a part of an Operative System" sounds very harsh. Every step is backed up. You can restore everything by the push of the "Remove" button. I'm not trying to remove something, I'm trying to replace this broken power driver with other ones. Smacman has given me good ideas of where the problem might be, but right now I am going to research my idea.
What the patch does in it's current state:
Fixes Audio CPU problems
Keeps Sleep function
Disables Speedstep
Disables Turbo
What is speedstep?
Speedstep is a function that downclocks the CPU when idling.
With this disabled, idle temps can now be higher.
This is still viable I guess versus 60-70 when just playing audio.
What is Turbo?
Turbo enables another multiplier on the CPU.
On a 2.66GHz Single CPU computer, that would be around 125 extra MHz.
Maybe still viable for some to lose those and fix the audio issue.
Some results from my testers:
as you can see here, after the patch, CPU consumes more power in Idle.
This is cause speedstep is disabled.
However, the overall power usage increase (bottom) is not really big.
Here you can see temperatures during audio playback after applying patch:
Notice almost every component runs cooler.
And here is power before and after applying patch.
Thanks to Jérôme Bouvard for testing and pictures.
I am very well aware of the issues with Speedstep and Turbo. I am pretty sure you can enable these natively by using tricks from the Hackintosh scene.
That's what I'm working on.
Also, "destroying a part of an Operative System" sounds very harsh. Every step is backed up. You can restore everything by the push of the "Remove" button. I'm not trying to remove something, I'm trying to replace this broken power driver with other ones. Smacman has given me good ideas of where the problem might be, but right now I am going to research my idea.
What the patch does in it's current state:
Fixes Audio CPU problems
Keeps Sleep function
Disables Speedstep
Disables Turbo
What is speedstep?
Speedstep is a function that downclocks the CPU when idling.
With this disabled, idle temps can now be higher.
This is still viable I guess versus 60-70 when just playing audio.
What is Turbo?
Turbo enables another multiplier on the CPU.
On a 2.66GHz Single CPU computer, that would be around 125 extra MHz.
Maybe still viable for some to lose those and fix the audio issue.
Some results from my testers:
as you can see here, after the patch, CPU consumes more power in Idle.
This is cause speedstep is disabled.
However, the overall power usage increase (bottom) is not really big.
Here you can see temperatures during audio playback after applying patch:
Notice almost every component runs cooler.
And here is power before and after applying patch.
Thanks to Jérôme Bouvard for testing and pictures.
I feel like I'm losing my mind here. I've tried every test listed here to reproduce this and I can't get my temps to go any higher then 49c. I idle at 47c. My Northbridge stays consistent at 62c no matter what.
Patch
Thanks Cindori,
Thanks for taking my post in the spirit I intended.
When you're through with the patch, if you would be so kind, start planning for a career as an Apple CEO.
Adios, one and all.
Thanks Cindori,
Thanks for taking my post in the spirit I intended.
When you're through with the patch, if you would be so kind, start planning for a career as an Apple CEO.
Adios, one and all.
Try booting. Then leave for a bit so temperatures stabilize. Then measure CPU A Temperature Diode (on Temperature Monitor). Now play something in iTunes continuously for say 10 minutes. Note temperature increase.
Forget other sensors. Just report back (and note ambient temp).
If you use (and configure appropriately) the history window, you can watch the temperatures change as you go along.
Your idle temp of 47C seems very high. Mine is 32C.
NB. some audio apps keep the roasting bug in play even when paused or finished playing.
And there you were thinking that your storming Nehalem was good to run audio (even if 10x more inefficiently than an iPod) in less than 1/1600th of its power (ie.<1% of one its 16 virtual cores)!
The big plug for this 09MP included its efficiency and green credentials, whilst here it is burning away like there's no tomorrow - and doing nothing.
But that's not what will ignite your ire in the long term, it's Apple systematic intransigence.
But perhaps I shouldn't say that lest pride is added to their reasons for snubbing us in our appeal for a speedy remedy.
PS. Thanks for getting back bugout, the ever optimistic might still dream that some system didn't exhibit the bug, hence give some clue as to cause hence remedy.
The sort of thing that happens is that we play some Youtube video over morning coffee. The track ends. We move on to other things ... hide the browser. Many hours later, we discover that the machine has been roasting away all day or for days.
Several audio sources do not stop this bug when they pause or end playing. They have to be quit completely for things to return to sanity.
Several audio sources do not stop this bug when they pause or end playing. They have to be quit completely for things to return to sanity.
Yes.but forget that one if you have an audio interface running along the hole time...Mine 12h/day. My temps are always high. If I playback audio content or not.
I'm fairly certain there is an issue with the 09's because:
1) This thread wouldn't have 900+ posts
2) My CPU A temps wouldn't hover around 60C all the time according to iStatPro, when on a fresh boot they're around 40C.
However, I'm trying to replicate the cause of this and I really can't.
There's supposed to be a performance hit when playing audio, right? I'm not really seeing that. I'm on an octo-2.26.
That's only a 3% difference and can possibly be attributed to other background processes.
1) This thread wouldn't have 900+ posts
2) My CPU A temps wouldn't hover around 60C all the time according to iStatPro, when on a fresh boot they're around 40C.
However, I'm trying to replicate the cause of this and I really can't.
There's supposed to be a performance hit when playing audio, right? I'm not really seeing that. I'm on an octo-2.26.
That's only a 3% difference and can possibly be attributed to other background processes.
well I'd say every Firewire-/USB Interface /Soundcard will do that. I am using the Apogee Ensemble. Apogee is an apple partner and the their interfaces are the most integrated in OSX on the market.
1. Oct-cores only see a 15% drop. (due to share load)
2. do you have any External Audio Devices/External HDDs? As these will give you a performance drop even if you not listening to audio (in which case your test was pointless
) (they just just need to be plugged in to see a drop in performance.)when i ran Cinebench on my Mac pro 09 Octcore i saw a 11% drop in performance when playing Apple lossless via Itunes.
1. Oct-cores only see a 15% drop. (due to share load)
2. do you have any External Audio Devices/External HDDs? As these will give you a performance drop even if you not listening to audio (in which case your test was pointless
when i ran Cinebench on my Mac pro 09 Octcore i saw a 11% drop in performance when playing Apple lossless via Itunes.
1) I'm seeing a 3% drop in Handbrake, nowhere near 15%.
2) I have a Drobo and DroboPro via FW800 and a WD via USB2. I also have a PCIe BlackMagic Intensity Pro card.
Exactly you have Firewire HDD plugged in & a USB HDD plugged in
if you unplug your firewire HD & USB HDD run handbrake, (note time) Then plug them back in you will a difference in time.
like i said in my previous post if you have a Firewire HDD/External Audio device plugged in you will see a performance drop anyway. even with without audio playing.
i predict
Fresh boot, iTunes not open, no audio playing no HDD
Start encode: 12:34:00PM
End encode: 12:49:25
Time: 15m25s
iTunes open, audio playing ALAC files & Firewire
Start encode: 1:02:00PM
End encode: 1:17:52PM
Time: 17m52s
Hi All
Just been reading on another forum of a person who has 30 Mac Pros running everyday ( I assume in some business )
He says that when he does updates etc he always does clean installs and has never seen nor had this this temp problem on any machine
and says that they are loaded quite heavely whilst working.
He claims because he always does clean installs he does not get left with old mangled files etc which can screw the way the machine works.
Hence maybe why Apple always say there is nothing wrong with the machines etc....
Anybody out there done a clean install and still get the problem ?
I must admit I am guilty of just updating one on top of the other, then on buying a new machine just moving everything over, so god knows
what rubbish I have drifting around in my machine
In the meantime I have turned off Hyperthreading and shut down two cores and my temps have dropped way way down
Just been reading on another forum of a person who has 30 Mac Pros running everyday ( I assume in some business )
He says that when he does updates etc he always does clean installs and has never seen nor had this this temp problem on any machine
and says that they are loaded quite heavely whilst working.
He claims because he always does clean installs he does not get left with old mangled files etc which can screw the way the machine works.
Hence maybe why Apple always say there is nothing wrong with the machines etc....
Anybody out there done a clean install and still get the problem ?
I must admit I am guilty of just updating one on top of the other, then on buying a new machine just moving everything over, so god knows
what rubbish I have drifting around in my machine
In the meantime I have turned off Hyperthreading and shut down two cores and my temps have dropped way way down
There is a reason I have not released it. Yet.
I am very well aware of the issues with Speedstep and Turbo. I am pretty sure you can enable these natively by using tricks from the Hackintosh scene.
That's what I'm working on.
Also, "destroying a part of an Operative System" sounds very harsh. Every step is backed up. You can restore everything by the push of the "Remove" button. I'm not trying to remove something, I'm trying to replace this broken power driver with other ones. Smacman has given me good ideas of where the problem might be, but right now I am going to research my idea.
What the patch does in it's current state:
Fixes Audio CPU problems
Keeps Sleep function
Disables Speedstep
Disables Turbo
What is speedstep?
Speedstep is a function that downclocks the CPU when idling.
With this disabled, idle temps can now be higher.
This is still viable I guess versus 60-70 when just playing audio.
As far as you don't find a way to solve the SpeedStep problem, your is a nice attempt, but a patch to avoid.
During the normal usage of a work machine (like a Mac Pro should be), SpeedStep is definitely a factor