Apologies for the dramatic title, but I have always found this to be an interesting topic. A week does not go by without a topic created by a concerned owner seeing his Macbook Pro hitting around 100 degrees Celsius under load, which is pretty much the max operating temperature, as set by Intel.
There are two camps that always reply in these threads. One says that it is ok, since the CPU is designed to handle these temperatures and as long as it does not shutdown, the Mac is not overheating. The other camp says that running so close to maximum operating temperature could impact reliability and also performance.
I have been fascinated by the discussion, but wanted to bring something tangible and empirical to the table. I have in the past tried to find ways to be able to see the current CPU clock rate in OS X, with various forms of success. By installing kexts and using FreeSMC with plugins, I managed to do this on some older Macs, like my 2011 MBA, but trying the same technique would cause the rMBP to crash. I then recently discovered a very handy little tool - Intel Power Gadget. Do note if you run it yourself, then watching it does not give the most accurate results. It is advisable to use the output to a file functionality of the tool instead.
In addition, I have been aware of the pmset terminal command, however I never really spent much time looking at the output properly until now.
The output when the CPU is idle"
Code:
Note: No thermal warning level has been recorded
24/12/2013 17:41:54 GMT CPU Power notify
CPU_Scheduler_Limit = 100
CPU_Available_CPUs = 8
CPU_Speed_Limit = 100
Keep the window open and run a CPU intensive application, like Handbrake. You will see notifications popping up like
Code:
24/12/2013 13:52:53 GMT CPU_Scheduler_Limit = 100
CPU_Available_CPUs = 8
CPU_Speed_Limit = 85
I found this interesting and wanted to see if there is a simple formula to work out the clock rate using CPU_Speed_Limit. I found that it was as simple as it could be. If we assume that CPU_Speed_Limit is just the percentage, we can work out the current clock rate
I ran a Handbrake encode and piped pmset -g thermlog output to a file. I also enabled logging from Intel Power Gadget. I then analysed both logs and correlated the events.
In the case of a workload taxing all 4 physical cores 100% CPU should be 3.4 GHz (Turbo boost on this CPU is 0.8 GHz with 4 cores active)
I confirmed that the formula works by checking a couple of data points against the output from Intel Power Gadget
Code:
24/12/2013 13:52:55 GMT CPU_Scheduler_Limit = 100
CPU_Available_CPUs = 8
CPU_Speed_Limit = 82
3.4 x 0.82 = 2.788 (rounded up = 2.8 GHz) which corresponds to the log from Intel Power Gadget.
Then we see this
Code:
24/12/2013 13:52:56 GMT CPU_Scheduler_Limit = 100
CPU_Available_CPUs = 8
CPU_Speed_Limit = 85
3.4 x 0.85 = 2.89 (rounded up to 2.9 GHz)
So at 13:52:56 we expect to see a change from 2.8 to 2.9, which we do
Code:
13:52:56:110 2800
13:52:56:160 2800
13:52:56:209 2800
13:52:56:259 2800
13:52:56:310 2900
13:52:56:360 2900
13:52:56:410 2900
13:52:56:460 2900
13:52:56:510 2900
13:52:56:560 2900
13:52:56:610 2900
13:52:56:659 2900
Then from this point until 13:52:59 it ran at 2.9 GHz according to Intel Power Gadget. Correspondingly there were no events in pmset until this
Code:
24/12/2013 13:52:59 GMT CPU_Scheduler_Limit = 100
CPU_Available_CPUs = 8
CPU_Speed_Limit = 88
So calculating what to expect in Intel Power Gadget
3.4 x 0.88 = 2.992 (rounded up 3 GHz)
Here is the corresponding Intel Power Gadget log
Code:
13:52:59:760 2900
13:52:59:810 2900
13:52:59:859 2900
13:52:59:909 3000
13:52:59:959 3000
13:53:00:010 3000
So what happened during the test?
Image
The Handbrake encode had 3 different clips in the queue. For the purposes of average/min/max I removed the statistics when one encode finished and the next started to not skew the data (you can see those stop/start events in the chart above clearly)
Encode 1
Code:
Average Frequency (MHz) 2859
Max Frequency (MHz) 3300
Min Frequency (MHz) 2600
Average Temperature (Celsius) 101
Max Temperature (Celsius) 105
Min Temperature (Celsius) 89
Encode 2
Code:
Average Frequency (MHz) 2727
Max Frequency (MHz) 2800
Min Frequency (MHz) 2500
Average Temperature (Celsius) 101
Max Temperature (Celsius) 104
Min Temperature (Celsius) 96
Encode 3
Code:
Average Frequency (MHz) 2678
Max Frequency (MHz) 2800
Min Frequency (MHz) 2500
Average Temperature (Celsius) 101
Max Temperature (Celsius) 105
Min Temperature (Celsius) 96
We see the average frequency going down over time. Max clock rate (3.4) was only hit right at the beginning of an encode and those data points were deleted, as I mentioned already
Conclusions
In the past Apple has sometimes run CPUs at lower than base clock to reduce internal temperatures (all the time). Intel makes no guarantees about turbo boost - in other words, you should expect at least a minimum of the base clock rate under load, which is what we mostly see in this experiment. Thermal throttling
does happen, but even on a thermally constrained laptop, we only see this happening very seldom and only up to a small number below the base clock rate.
The operating system believes that everything was running fine with no abnormal temperatures recored, even though we were hitting 100-105 degrees Celsius. Pmset confirms this:
Code:
Note: No thermal warning level has been recorded
It is possible that with better cooling Turbo Boost could be sustained for longer periods.
A side note about Geekbench
Armed with all of these tools and knowledge we can look at benchmark applications, like Geekbench. It has become the most popular and often quoted benchmark on these forums. People use it for various arguments. Intel has been concentrating a lot on the performance of the mobile CPUs and has, arguably, been ignoring the desktop performance. We see this trend in Geekbench, with Mobile CPUs in the Macbook Pros snapping at the heals of the top of the range iMac and the iMac snapping at the heal of the Mac Pros. However, as I have always said Geekbench is a sprint and shows mainly how fast the CPU is with maximum Intel Turbo Boost. It does not show how well the system will perform in real use.
The problem is that pmset -g thermlog clearly shows that when we run Geekbench, we receive no events, therefore the CPU is running at 100% during this time with no speed limit. Geekbenchs workload is simply not strenuous enough to see the impact of thermal throttling and makes comparisons skewed towards CPUs with the maximum Turbo Boost clock rate. Basing purchasing decisions on this is not a good idea in my opinion.
