PowerMac G5 quad-core, CPU A1 DIODE TEMP: 90.8 C (for example): How to handle? [Mac OS X behavior]

Mark Millard markmi at dsl-only.net
Sat Jan 17 22:04:26 UTC 2015


Mac OS X 10.5 does force idle time of some form to keep core temperatures down! My evidence is as follows.

The application Temperature monitor does show me temperature records (including graphs over time) under Mac OS X 10.5 for the G5. (No rpms.) It displays the information as for cpu A 1&2 and cpu B 1&2 (instead of 0 and 1). A2 is what it shows as a the hot one, matching FreeBSD's a1. I watched with the current short-term temperature display updating once a second (set via preferences).

Once it reached around the low 90C range on A2 the temperature on A2 started oscillating, going from the mid/low 90C's down to the 60C's/70C's and back up again, over and over, fairly rapidly. But the graph of the temperatures for all the cores shows all the CPU/core temperatures as oscillating in matching timing.

So I conclude that Mac OS X is doing something to give all the CPUs/cores time to cool down as soon as any one of them gets too hot.

So I do not expect Mac OS X to automatically power down, it has already been far longer than it takes for FreeBSD to shutdown with the patched RPM/cooling code. Menu meters shows the cores as fully used (mostly 100%, occasional 99%). They are mostly running 6 of my double/long-long HINT benchmark variants built various ways with parameter values input that are designed for long runs. (HINT is memory/CPU limited until it causes noticeable paging. But I've configured to not page with the 16GB of RAM avilable.)

So far the maximum temperature is 95.8C, and that is on A2. The next highest core is A1 at 81.2C so far. During this oscillation A2's minumum is 60.7C so far.

There is a pattern to the drops: there is a sequence of 5 to 7 in a row where the drop starts back up almost immediately but then there is a longer duration with the temperatures staying down before it starts back up again. After the longer duration drop the temperature rise is not as rapid so it is longer until the next forced-drop.

For the 5-7 in a row they tend to get somewhat closer together the further into the sequence. It may be that the time between triggers the longer cooling duration.

The G5 has been kept busy for well over an hour, far longer than FreeBSD did for "make -j 8 buildworld buildkernel"

===
Mark Millard
markmi at dsl-only.net

On 2015-Jan-17, at 11:45 AM, Mark Millard <markmi at dsl-only.net> wrote:

While I mentioned forced idle time as a technical possibility I'm not so sure that FreeBSD would want to automatically drop performance in order to keep a machine running. In my case such would not be enough for me to decide to continue to use the problematical quad-core G5. (I doubt that it would be a minor amount of idle time that was required to get “make -j 8 buildworld buildkernel" or other such to work reliably on this G5.)

I will try something to put the problematical G5 under load under Mac OS X 10.5, say 4+ copies of the HINT benchmark running concurrently if I still have that around. But I'm not aware of a pre-existing way to see the fans speeds, pump speeds, and other such in that context. I may only learn if it automatically shuts down or not. For FreeBSD I was fairly sure I'd be able to readily find such extra information (and I did).

I'd say that what I reported for "01:45:51 to 02:13:50" was near full-throttle over that time and it started at 70.3C. Looks like Justin got it programmed with the properties he wanted.


===
Mark Millard
markmi at dsl-only.net

On 2015-Jan-17, at 08:35 AM, Adrian Chadd <adrian at freebsd.org> wrote:

On 17 January 2015 at 08:09, Justin Hibbits <chmeeedalf at gmail.com> wrote:
> The new algorithm in this patch is supposed to put the fans at full
> throttle around the midpoint, so around 70C they should be at full
> blast.
> 
> Have you tried the same machine under heavy load with OS X or Linux?
> We can keep adjusting the algorithm, as long as your machine is known
> to be good enough under one of those OSs.  If they also overheat,
> there's nothing we can do, since OS X at least should run fine with
> heavy load, as long as the hardware can handle it.

Can you force introduce halt cycles to compensate for the increasing
rise in temperature?




-adrian




More information about the freebsd-ppc mailing list