5.0.4 Performance Issue (Similar to D3 Beta)

Mac Technical Support
Post Limit:
Prev 1 36 37 38 44 Next
Also reporting this issue. The thread kill workaround is effective on my system. Temp of all processor cores without killing the thread, 97C with fans going at 6k RPM. After killing thread running at 82C with fans at 3k RPM.

MacBook Pro Early 2011 15"
Quad Core i7 2.0ghz 8GB RAM
Radeon HD 6490M
Mac OS 10.8.1 64-bit WoW client.
he seems to think that running Photoshop and similar - programs that don't touch the GPU

You think Photoshop doesn't touch the GPU?


Okay, yes, it uses the GPU - to a relatively limited degree (http://helpx.adobe.com/photoshop/kb/gpu-opengl-features-preferences-photoshop.html). Compared to a 3D OpenGL game? No. Sure some aspects are GPU accelerated - that's worlds away from the bag of hurt that WoW places on the GPU. Trying to compare WoW running amok with the CPU and GPU is not even vaguely comparable to the stress that professional users place on the machine.
Trying to compare WoW running amok with the CPU and GPU is not even vaguely comparable to the stress that professional users place on the machine.

If your computer is hurting itself due to CPU thermal stress, that is, sadly, not WoW's fault.

It might be a problem with WoW that some threads or processes that are busy-waiting and what not are being spawned, but when 100% CPU fries your computer, that's your computer's problem.


So if someone makes a rootkit that fries computers, that's cool?

I don't think you understand the problem here. The program is designed to work for most modern macs, but the client itself at this point is potentially destructive for a great deal of users. It's not like we're trying to run WoW on some device it wasn't designed for; it is the mac client we are using.

This thread is now too long to read. Do mac users using Boot Camp have the same issues, or is it just the mac client doing this?
You know what really rustles my jimmes about all this?

I had to find out about this problem on Reddit.

I understand that yes, it's a complicated issue, it could be either Apple's fault one way or Blizzard's fault the other yada effin' yada. Would it have been that hard to throw in the news column at login that Mac users should avoid booting up WoW for the time being until the problem is fixed?

Way to not only drop the ball, but then subsequently toe-kick it into a steaming blob of crap.
09/05/2012 11:18 PMPosted by Normie
Trying to compare WoW running amok with the CPU and GPU is not even vaguely comparable to the stress that professional users place on the machine.

If your computer is hurting itself due to CPU thermal stress, that is, sadly, not WoW's fault.

It might be a problem with WoW that some threads or processes that are busy-waiting and what not are being spawned, but when 100% CPU fries your computer, that's your computer's problem.


Are we really going to open this silly angle again?

I'm out. The thread has served its usefulness - most unexpectedly in Growltiger's extremely effective solution, in Tia's additional GPU performance discovery, and finally in Blizzard's promise to patch it.

Anything further here - short of an announcement of a patch - is worthless.
09/05/2012 11:31 PMPosted by Loredor
I had to find out about this problem on Reddit.


On Reddit ?

Where ?
OK, I think it's time to set something straight here regarding apps and max CPU usage.

Omegal and I have had our disagreements with each other before (and sometimes heated ones at that), but in this case, he is correct in that software normally won't ruin your machine when running at max CPU load.

You see, when a program is well designed, or as bug free as possible, it can have several threads maxing your processor's cores to no ill effect (this assumes the machine is getting the proper signals sent from kernel_task during this time). It is when a thread becomes locked in a runtime loop or stalled that things get problematic.

On a quad core or better system, WoW won't bring the computer down even with three stalled threads (one on each of the three cores it is capable of using), because kernel_task will still have its own core to work from. Where it gets dicey is on single CPU, dual core systems. In a dual-core-only setup, because WoW can easily max two cores with the current problem thread, kernel_task can be effectively smothered to where it isn't getting any CPU time. Remember, this WoW issue is effectively a stalled thread that is artificially causing the CPU to never go idle, thus never have room for any other tasks outside of WoW. Because both of the two cores are now saturated, the computer is effectively "locked" to its current state because the OS is unable to effect fallback procedures such as ramping up fans, kicking in SpeedStep (downclocking the CPU to reduce heat), and downclocking the GPU (also to reduce heat). So we end up with a potentially fried system.

Now, let's say we had a different piece of software that much like WoW couldn't use all of the cores in a quad core system, but somehow got its panty-threads tied in a knot, forcing kernel_task to stall itself. If you don't think this can happen, install linux and you'll eventually run into software that does just this, usually from lack of good coding. So that software is using three cores and kernel_task is using the last core. But wait, because the software bug caused kernel_task to itself become stalled, and thus artificially raising that core's usage to 100% also, the system's effectively locked into its current state and cannot initiate fallbacks. Again, we'd end up with enormouse amounts of heat because the system controlling aspects of the OS became unresponsive. Oops.

Now let's take a look at software designed to max your CPUs. All of them. It's well written, uses all of the special features of the CPU, and because it didn't have any lingering bugs, even at max load allowed the OS to still allocate its resources and control them. One such app is PowerFractal, found here:

http://daugerresearch.com/fractals/powerfractal.zip

Download and open Temperature Monitor before running PowerFractal.

Temperature Monitor can be found here:

http://www.bresink.com/osx/0TemperatureMonitor/download.php5

Now launch PowerFractal and from the Maximum Count menu, select the bottom-most (largest) number. Make sure your Temperature Monitor window is open (the System Overview window) and that your CPU cores in the list are visible onscreen. Notice how the cores, all of them reach beyond WoW's temperature range in a mere thirty seconds, yet your system isn't blowing itself up. That's because the OS still has a small bit of processor power available to it since none of the threads in PowerFractal have stalled or are locked in a run loop. PowerFractal may take up to 30 seconds to respond to the CMD-Q (quit) command, but that's because it's utilizing all of the CPU it can physically get its grubby lines of code on. But it will relinquish control to the OS.

The stalled thread in WoW will not, and there is the problem. The bug is real, and is causing unnatural effects on the hardware. Had WoW been utilizing full CPU load in a normal manner, the system wouldn't overheat, but instead ramp itself down to a manageable level until the heat dissipated enough to resume normal operations. So Omegal is correct in that under normal circumstances, software won't cause the hardware to become unresponsive and put into a locked state. Bugs like this can do so, but are far from the norm. And this bug is only able to cause the system this kind of problem because the thread being locked caused the kernel to act in a manner it wasn't designed for (hence, bug).

OS X's kernel is well designed, and can withstand most forms of attack or user abuse. It's scenarios that nobody conceived of that cause issues like this to crop up.

So in this particular case, we're right about the bug, but Omegal's right about the software normally being unable to cause this type of anomaly. Unfortunately, as we've seen with this errant thread (the WoW thread, not the forum thread, though one could argue that one as well haha), the unexpected can occasionally throw things so out of whack that damage can be done, and in a surprisingly short period of time.

As for my "GPU bug", it isn't so much a bug as that the client now does what it wasn't doing before: utilizing all of the GPU regardless of data input/throughput, if the FPS limiter is disabled. Previous clients, I'm guessing, were actually bugged in that even with the FPS limiter off (as was the case for me), they still weren't using all of a GPU. That previous bug apparently got fixed and now we're seeing GPU temperatures skyrocket unless framerates are limited to the refresh rate of the display (and they should be in most cases so the GPU has headroom for other tasks). The timing of the GPU utilization bugfix coupled with the CPU bug showing up was simply a massive double whammy to the users' hardware, many models which were designed with form over function in mind.

So while Omegal may have come off a bit abrasive, he is essentially correct, and so are we. Welcome to the paradox of programming. :)
I had to find out about this problem on Reddit.


On Reddit ?

Where ?


A search for "wow mac 5.0.4" brought up some threads that linked back to here, as well as the joystiq article.

The internet knows. I imagine we will see a patch pre-MoP launch, to avoid a PR nightmare. A lot of the folks that are going to be playing for the first time aren't going to be as patient and tech savvy as some of the users in this thread. It will be a different story when little Timmy's brand new laptop gets fried.
Did all the steps Upgrade suggested and everything was working okay. FPS capped at 35 but fluctuating greatly at all times. Most likely due to a faulty addon not yet identified. What I can say though is that, like another poster, Battleship in Dragon Soul was a mess. FPS lapses every few seconds, could barely move to get into the shadow spots, dps was horrendous. Whatever fix that the Command Line help achieve was lost on certain parts of Dragon Soul, especially those with mist/fog/cloud effects. Or, in the case of Madness, the moving water
Tia:

What you've said and what Omegal has said are, from what I can determine, similar yet very different. You admit that the canoe can be tipped over, he seems bent on the fact that any canoe tipping is inherent in the hardware. I understand and accept (more or less) most of your post as being valid, but Omegal, I'm still convinced, is just being a snooty (unfounded) hardware elitist and probably bent on actively trolling the forum. (I suppose I'm also rather angry because he came into my thread when I reported this very issue waaaayyy back in the beta, and pretty much filled the whole thread with 'lol ur computr suxx0rz get a real machine u nub', and I'm wondering if that didn't have something to do with the fact it got ignored.)

Anyway. I'm not sure what the discussion about the FPS limiter is. Even in 4.* I had my framerate capped at 40, and saw no issues with either heat or CPU usage. In 5.*, it doesn't matter what point I have my framerate capped at (I've tried my original 40 by default, 30, and then finally the arguable minimum of 24), with absolutely zero effect on the temperature or core usage involved with the bug, which implies to me, at least, limiting one's FPS has nothing to do with the issue at hand. The only time I see an actual decrease in temperature/usage is when I tab out, which drops my temps by about 15 degrees (to the still not very safe range of 150º) and my core usage to a mere %120. Of course, my FPS is also -3- when I'm tabbed out, so that isn't exactly what I'd call playable.
09/06/2012 02:30 AMPosted by Arenvald
Anyway. I'm not sure what the discussion about the FPS limiter is. Even in 4.* I had my framerate capped at 40, and saw no issues with either heat or CPU usage. In 5.*, it doesn't matter what point I have my framerate capped at (I've tried my original 40 by default, 30, and then finally the arguable minimum of 24), with absolutely zero effect on the temperature or core usage involved with the bug, which implies to me, at least, limiting one's FPS has nothing to do with the issue at hand. The only time I see an actual decrease in temperature/usage is when I tab out, which drops my temps by about 15 degrees (to the still not very safe range of 150º) and my core usage to a mere %120. Of course, my FPS is also -3- when I'm tabbed out, so that isn't exactly what I'd call playable.


You went about that backwards. You kept going down in framerate. Beyond a certain value (descending) you won't see much if any improvement with heat. Uncap your framerate and watch your GPU fry itself. That's the key. Capping the framerate lets the GPU do other things, most notably idle, which helps it to remain relatively cool. My GPU usage was 100% with no FPS cap in place (FPS limiter off). Since my display refresh rate is 60 Hz, I capped my FPS at 60 and saw my GPU go from 100% use to 15-30% use, 45-50% in high population/raid areas. That brought the PCI-E expansion bay temperature down by nearly 20°C, which is a significant decrease in heat. However, if I were to go about it the way you just described, lowering beyond 60 FPS down to say, 30 FPS, I'd see almost no improvement in heat dissipation because I've already hit the diminishing returns wall. Lower powered (as in low end) GPUs won't hit the diminishing returns wall vs. framerate nearly as quickly as a high end card will, but they will hit it, just as you did.
Unless a process has root privileges, it won't be able to set a thread's priority higher than a system-specified maximum. Any hardware monitoring processes are going to be running at a higher priority than that. It shouldn't be possible to "stall out the kernel" threads which are responsible for scheduling/monitoring.

I don't think we have enough information to determine why some people are having severe (as in damaging) heat problems, or whether most people are seeing what I see on my iMac, higher than normal heat, but the fans ramp up and take care of the problem without causing any damage.

I never really looked at the thread usage in the client before now, so I don't know how multi-threaded it used to be. Perhaps all the heavy lifting was done in one thread, they've now split it out to two threads, and that's why it can put a heavier load on the GPU (while also putting a heavier load on the CPU, even without the errant thread). The only way to tell would be to know what the CPU usage and uncapped FPS were in the previous version at various graphics settings in a standardized location, and compare it with what happens with the new client (taking into account that graphics settings between the two aren't even directly comparable).

If it was all being done in one thread, and that thread was maxed out even for Ultra settings, then it wasn't going to be able to fully utilize the GPU. If it really is using more of the GPU than it was able to before, it's a combination of improved CPU code, better pipelining, multi-processing (splitting into more than one thread to take advantage of multiple cores), and possibly moving some processing onto the GPU that had been done on the CPU before.

This is good, even if it makes it easier to run your system hot. The answer is always going to be first, lower your frame rate, and second, lower your graphics settings (in that order).

Edit: Tia, what kind of frame rates were you seeing when you had it uncapped and hitting 100% GPU? What graphics setting was that at?
Tia, what kind of frame rates were you seeing when you had it uncapped and hitting 100% GPU? What graphics setting was that at?


My framerates uncapped ranged from 20-35 (Stormwind) to >100 (unpopulated areas of Azeroth with not too many trees). Typically they'd end up in the 30-45 range. Perfectly playable, but due to vSync, they'd typically cap automatically at 20 or 30 FPS.

I'll do you one better on what my graphics settings are: I'll give you the contents of my config.wtf which can explain them in exact detail at a glance.

SET locale "enUS"
SET hwDetect "0"
SET fullAlpha "1"
SET SmallCull "0.010000"
SET DistCull "500.000000"
SET frillDensity "48"
SET farclip "1250"
SET specular "1"
SET pixelShaders "1"
SET unitDrawDist "300.000000"
SET movie "0"
SET expansionMovie "0"
SET readTOS "1"
SET readEULA "-1"
SET showToolsUI "1"
SET lod "1"
SET shadowLevel "0"
SET M2UsePixelShaders "1"
SET Gamma "0.700000"
SET MusicVolume "0.40000000596046"
SET SoundVolume "1"
SET MasterVolume "0"
SET weatherDensity "0"
SET ffxGlow "0"
SET ffxDeath "0"
SET realmName "Ner'zhul"
SET gameTip "2"
SET AmbienceVolume "0.60000002384186"
SET uiScale "0.89999997615814"
SET CombatLogRangeCreature "2000"
SET GLFaster "2"
SET MasterSoundEffects "0"
SET EnableMusic "0"
SET EmoteSounds "0"
SET EnableSoundWhenGameIsInBG "0"
SET showGameTips "0"
SET UnitNamePlayer "0"
SET preferredFullscreenMode "1"
SET readScanning "-1"
SET readContest "-1"
SET coresDetected "4"
SET Sound_VoiceChatInputDriverName "AK5370 "
SET Sound_VoiceChatOutputDriverName "Built-in Digital Output"
SET Sound_OutputDriverName "Built-in Digital Output"
SET ChatMusicVolume "0"
SET ChatSoundVolume "0"
SET ChatAmbienceVolume "0"
SET Sound_EnableMusic "0"
SET Sound_EnableAllSound "0"
SET Sound_MasterVolume "1"
SET Sound_SFXVolume "1"
SET Sound_MusicVolume "0.40000000596046"
SET Sound_AmbienceVolume "0.60000002384186"
SET OutboundChatVolume "2.5"
SET InboundChatVolume "1"
SET VoiceActivationSensitivity "0.39999997615814"
SET iTunesTrackDisplay "1"
SET readTerminationWithoutNotice "-1"
SET Sound_EnableErrorSpeech "0"
SET Sound_VoiceChatInputDriverIndex "3"
SET Sound_VoiceChatOutputDriverIndex "1"
SET PreferedLocale "enUS"
SET CombatLogRangeParty "2000"
SET CombatLogRangePartyPet "2000"
SET CombatLogRangeFriendlyPlayers "2000"
SET CombatLogRangeFriendlyPlayersPets "2000"
SET CombatLogRangeHostilePlayers "2000"
SET CombatLogRangeHostilePlayersPets "2000"
SET MovieRecordingWidth "1280"
SET MovieRecordingSound "0"
SET autoLootCorpse "1"
SET showPartyDebuffs "0"
SET SlideBarConfig "anchor=right;position=188.80009268301"
SET MovieRecordingAutoCompress "0"
SET Sound_OutputQuality "2"
SET Sound_NumChannels "64"
SET Sound_ZoneMusicNoDelay "1"
SET installType "Retail"
SET Sound_EnableHardware "1"
SET environmentDetail "150"
SET accountType "CT"
SET MovieRecordingRecover "0"
SET UnitNameEnemyCreationName "0"
SET UnitNameFriendlyCreationName "0"
SET UnitNameCompanionName "0"
SET DesktopGamma "1"
SET mouseSpeed "1.2000000476837"
SET maxFPSBk "60"
SET shadowMode "1"
SET showClock "off"
SET hidePartyInRaid "1"
SET ShowAllSpellRanks "0"
SET questLogCollapseFilter "-1"
SET previewTalents "1"
SET Sound_OutputDriverIndex "1"
SET Sound_EnableEmoteSounds "0"
SET projectedTextures "1"
SET videoOptionsVersion "5"
SET waterDetail "3"
SET taintLog "2"
SET enterWorld "1"
SET useUiScale "1"
SET maxFPS "60"
SET Intensity "0"
SET ffxSpecial "0"
SET SkyCloudLOD "1"
SET ProcessAffinityMask "14"
SET Sound_EnableAmbience "0"
SET Sound_EnableDSPEffects "0"
SET Sound_EnableSoundWhenGameIsInBG "0"
SET guildRecruitmentChannel "0"
SET minimapTrackedInfo "2048"
SET gxFixLag "1"
SET disableServerNagle "0"
SET checkAddonVersion "0"
SET MovieRecordingQuality "3"
SET lastCharacterIndex "2"
SET g_accountUsesToken "1"
SET installLocale "enUS"
SET gxApi "GLL"
SET gxWindow "0"
SET gxMaximize "0"
SET expandUpgradePanel "0"
SET showLootSpam "0"
SET showNewbieTips "0"


A note on the SET uiScale CVAR: That particular value is required to maintain the UI positioning and allow space between the bar areas. It was a bug that was never fixed even from the late alpha/early beta in 2003. Any other value causes the action bars to become too big and scrunch up against my minimap.

As you can see, I have fairly customized graphics settings tailored to being as fast as possible for a Mac setup while still giving me good viewing distance.

Any hardware monitoring processes are going to be running at a higher priority than that. It shouldn't be possible to "stall out the kernel" threads which are responsible for scheduling/monitoring.


PowerFractal actually did just that. Until it finally relinquished control (after I had it set to its maximum accuracy and it was maxing all four of my cores), none of the OS scheduling events took place. Unfortunately PF does have one minor bug - a lot of the time, if you try to quit it while it's rendering at maximum accuracy (and thus max core use), upon successfully relinquishing control back to the OS, one of the cores will remain at 100% (the thread is stalled or cannot be accessed). That core will remain so until the suspect thread is physically terminated or PF is killed using the killall -9 PF-PID command in terminal.

When PF is using all of the cores in this manner, the OS gets in a shot about once every 30 seconds. That means any click, visual graphic updates (like the clock time changing or window closing), and any other input will not be processed until that window of opportunity opens up. During that time kernel_task appears to be stalled completely and then shunts everything through that it can in the span of about half a second before PF gets all of the cores back. The good news is that during that small window of opportunity the SMC controller does get to do a rapid check and adjusts the fans accordingly.

PF uses 100% CPU available to it (all cores), and is not GPU intensive, so it made a perfect app to test with relative to this thread's issue.
Tia:

What you've said and what Omegal has said are, from what I can determine, similar yet very different. You admit that the canoe can be tipped over, he seems bent on the fact that any canoe tipping is inherent in the hardware. I understand and accept (more or less) most of your post as being valid, but Omegal, I'm still convinced, is just being a snooty (unfounded) hardware elitist and probably bent on actively trolling the forum.

Sorry, no. You and Omegal are just two people that have a disagreement. You know what, though? You don't have to be right. I've had disagreements with both Tia and Omegal in the past -- they've made their case, I've made my case, we've both counterpointed maybe several times. If we still disagree, perhaps even think the other is a complete lunatic and being absolutely unreasonable -- I'm ok with leaving it at that.

Maybe I'm wrong, maybe they are wrong, maybe we are both partly right or wrong. I'm fine letting them "be right" or "win".

Omegal is not being a troll. However, I do feel this discussion of "I'm right, he's wrong" shouldn't continue.
There are like 4 people who play WoW on macs, so, I don't really see this nightmare.


There is actually a fairly considerable amount of Mac users playing. Hence why there's such a stink about it. The unfortunate reality is that it's not a large enough user base that Blizzard will jump on it like white on rice as they would for a PC client issue.

Just because you don't think it's a big deal doesn't invalidate the fact that there's thousands of users out there unable to play without risking the integrity of their machines or having to implement work-arounds that shouldn't be necessary in the first place and hopefully won't be necessary for much longer.

If you don't care, then do this thread a favor, and leave.
09/06/2012 07:57 AMPosted by Liraelclayr
There is actually a fairly considerable amount of Mac users playing. Hence why there's such a stink about it. The unfortunate reality is that it's not a large enough user base that Blizzard will jump on it like white on rice as they would for a PC client issue.

Uhm... it's barely been over a week. Before you put on your best Kanye West voice and boldly claim "Blizzard doesn't care about Mac people," at least give them a chance. The last thing you want is them to haphazardly push out a patch to fix "this", but find out it broke something else.
@Normie

This is kind of a serious issue for a lot of people. So no trolling!!

Join the Conversation