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. Code: pmset -g thermlog 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? 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. Geekbench’s 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.