A download just started earlier while not playing but with the BNet App open (I suppose 8.2?), and the CPU usage of the BNet Agent immediately spiked to well over 700% (usual download/patch with the same speed uses around 60-70%) and the temperatures reached values of over 100 degrees celcius. Obviously, there was some lag involved in doing anything at this point - almost unresponsive at times.
I have literally never experienced a download or patch resulting in this behaviour. Not with WoW patches, nor with other downloads … not even while actively playing a game while and doing three more things at the same time. This issue only occurs with the 8.2 WoW Update, restarting my Macbook and trying again resulted in the same problem; abnormal cpu usage and instant temp spikes.
Manually restricting the Maximum Download speed to like 2 MB/s // 2048 KB/s (top was around 10 MB/s) did sort of prevent this issue from escalating but I’d say that a patch-download like this should never use so much resources that a system basically overheats and becomes almost unresponsive (regardless of the speed-limit).
To me, it seems like some optimising or checks are missing or there’s simply a bug present.
Now my download is finished by now, but I still count this as undesired (and unexpected) behaviour which is I think worth sharing with you (Blizzard) to look into. Since it’s not really an in-game issue I thought this was the best place to share it.
My system:
MacBook Pro late 2013
macOS Mojave 10.14.5
Connection: Wireless
As comparison:
Reinstalled a steam game (roughly same size as this patch), 10 MB/s, barely 70% load and temperatures of not even 70 degrees tops.
Random Linux download: 10 MB/s, barely 60% load, 65 degrees.
This is not a bug, it is merely due to the way the streamed installation of all our games works. Downloaded files are simultaneously compressed into local archives (this is what keeps the CPU busy), and is limited by the speed of incoming data and the speed of your hard drive.
Regulating the download speed will slow down the process of building up the local file structure of the game (and will cause the CPU to take more breaks to cool down).
I am aware of why it uses the CPU quite a bit, obviously this leads to some heat generation…what this does not answer is why Blizzard finds it normal to use so much resources that if you don’t manually take an action to slow it down - your system will become laggy and possibly even crash.
Again, I get that the files are compressed or decompressed on the fly, but why can other games do exactly the same without burning out the system while doing it roughly as quickly?
Compression rate being off? Too brutal hashing algorithm? Too small or big chunks to (de)compress? Lack of using multiple cores properly?
It may not be a bug, but from a design-perspective it is quite poorly thought thru…
If they need 700% CPU usage to download and install an update with a quite normal 10MB/s, yes I actually can blame them. That’s just absurd.
Now ofc it’s reasonable to point to the system, if it always has issues like this. But it does not, and yes the fans are clean and working as intended.
I am quite a heavy user, running multiple vms regularly and running quite complex compile actions, never does my system reach the values their silly updater manages to make it reach. So it is however you look at it something in their software.
They apparently see it as “working as intended”, so I will rest my case either way. But it still is odd to me.
Ahhh just hopping in to add to this.
I have a powerful machine but whenever a big patch starts to download/install I notice my PC stuttering and not letting me do a single thing, heck even opening Google Chrome makes it stutter and ‘whine’ so to speak.
It does not overheat, but it definitely keeps CPU veeery busy and it lags my PC big time, even typing stutters, so I have to wait until the patch downloads.
It’s not a huge issue for me, but it’s definitely annoying, especially if PC starts to overheat, as Trivale said.
If you have full drive encryption enabled on an older Macbook (IE, previous to 2018 model year with T2 security controller), MacOS will be doing all the encryption work on the main CPU, as it has no hardware encryption capability.
This will cause your CPU to ramp up more than you might expect…
But yes, Blizzard Launcher seems to be fairly poorly designed, I get large CPU spikes on my 10-core windows PC when the launcher patches (no drive encryption enabled, btw.)
depends on how weak your cpu is, if you have anti virus running in the background and the client most likely also is unpacking compressed files while downloading aswell. its from 2013 so wont have that powerfull of a cpu.
also it cant run above 100% so if your software says 700% then its a fault in the software.
since its overheating try dusting it out or get thermal paste replaced.
no matter how much something is stressing your system as soon as something overheats then its a problem inside your pc, the client wont magically overclock your system.
Mwa, 2.3 GHz Intel “Core i7” processor (4850HQ) I believe, it’s not that weak ^^
Uh yes it is possible. MacOS pretty much sums up the cores and threads in that %. 100% per core or thread, means that this simple download + update uses pretty much all cores + all possible threads…
Shrugs, still there is absolutely no need to utilise 4 cores + 4 threads for a simple update. Ofc, if you fully load the CPU a macbook becomes hot (they’re kinda known for that) - and since they support macOS they should know this
It has happened to me few times in Windows, too. Usually setting priority of the process to lower in the Task Manager solves that issues. Ideally Blizzard should set the priority to lower level automatically so the update process does not hog all the resources. But computer should not overheat from just using all available resources.
In MacOSX command “renice” should do trick the same from console. “top” can be used to find the required PID of the process.
![:slight_smile:](https://d1bg94bbsh66ji.cloudfront.net/en/wow/images/emoji/twitter/slight_smile.png?v=6" ":slight_smile:")